Absolute vs Relative move

Troubleshooting
1

This is very strange…
@fuzzynickel said once that the likelihood of bot to choke highly dependent of the number of moves. I thought that every move is independent and chances for the next move to be successful have nothing to do with the number of moves the bot made before. What did I know!

Here is the setup:

  1. goto 0,0,0
  2. move relative 100mm by Y
  3. repeat #2 10 times

This ALWAYS chokes at position 0,734,0. I tried 15 times and it always stops at this position.

Now the weird thing:
Replace “relative move” with correspondent “Absolute move”

  • goto 0,0,0
  • move absolute 0,100,0
  • move absolute 0,200,0
  • move absolute 0,300,0
    …
  • move absolute 0,700,0
  • move absolute 0,800,0
  • move absolute 0,900,0

This never brakes! I am totally puzzled. Do you have any ideas?

Here is the video that illustrates this phenomena

Thank you,
Eugene

2

Eugene,

This is the exact behavior I was seeing, including the motor stuttering! Although, I don’t have the data for the coordinates (e.g. 734 along the y). I’ll try and reproduce it on my rig tomorrow and provide any data I can. In the end, I just used absolute positioning whenever possible, and relative when I needed to (e.g. the insert-seed sequence comes to mind…it assumes a certain z-axis ‘fly height’ and moves relative to that…that child insert-seed sequence gets called after each absolute move in a parent planting sequence)

fuzzy

3

That’s interesting … I’ve got 31 move relatives in my garden scan sequence without movement errors at all :thinking:

4

@Ascend Mine is v1.3 software 6.4.0. What is yours?

5

I was not able to reproduce the behavior on a v1.2 hardware running 6.4.0 software. The test was a master sequence executing a pair of relative sequences 5 times. The pair of relative sequences were comprised of one sequence that would increment the x and y axes 100mm with relative movement 10 times (a total of 1m of movement) and one sequence that would decrement the x and y axes 100mm with relative movement 10 times (a total of 1m of movement). That amounts to 100 relative movements totalling 10m of travel (5m for each axis).

When I was having my issues last year, I believe we were on version 3.x of the software, so perhaps that is a factor? Likely not since you’re experiencing the same issue on 6.4.0 Eugene.

6

Software 6.4.0, Hardware is a modified v1.0 with stronger motors and different boards.

This issue still looks weird.

Just thinking what could be different in the moving command between MOVE RELATIVE and MOVE ABSOLUTE software wise.

7

The command sent to the firmware should be the same for a Move Absolute to (0, 500, 0) as it is for a Move Relative (0, 100, 0) from (0, 400, 0). You can confirm that they are the same by enabling Firmware SENT logs in the Logs page settings menu and watching for Debug 3 logs.

If you have encoders enabled, they will update FarmBot’s current position with the actual position achived instead of assuming the position based on the coordinate sent. So if the motors only made it to (0, 397, 0) and you send a Move Relative (0, 100, 0), the target coordinate will be (0, 497, 0) instead of (0, 500, 0) as it would be with a Move Absolute command. You would be able to determine if that is the case by watching the Firmware SENT logs. Some refinements to the motor settings may fix the issue if it is.