I’m building a 4 omni-wheel robot using 4 stepper motors (2 per axis, axes are orthogonal) that aims to traverse a (curved) path given as a sequence of (x,y) coordinates. The sequence of coordinates can be interpreted as a sequence of stepper motor positions. Thus, I send a sequence:
ticcmd -d tic1_id --max-speed vx0 --position x0; ticcmd -d tic1_id --max-speed vx1 --position x1; …
ticcmd -d tic2_id --max-speed vy0 --position y0; ticcmd -d tic2_id --max-speed vy1 --position y1; …
…
over USB to the Tic T834, where commands for the x respectively y coordinates are sent over different command lines simultaneously so that they approximately run simultaneously. Moreover, the pairs of speeds vx0-vy0, vx1-vy1 etc. are set such that the path from (x0,y0)->(x1,y1) etc. are in principle straight.
However, between each pair of subsequent command there seems to be a certain delay which makes the robot’s movement erratic, especially when the sequence of points is dense.
Is there anything to know about these delays between a linux command line and the command actually being executed at the Tic? Or the Tic signalling that it is ready to take the next positional command?
The Tic stepper motor controllers are not designed for applications that require the close coordination of the movement of different stepper motors, but I will see if I can help.
When you run the commands you posted above, ticcmd needs to send two USB commands to each Tic: one to set the speed and one to set the target position. From the computer’s perspective, those commands are normally executed in a matter of microseconds, but could take as long as about 1 millisecond if the Tic is busy doing calculations when the command is started. There will also be timing variation caused by Linux itself. If you are not already doing something to ensure that the commands for x1 and y1 are initiated at the same time, even if the commands for x0 and y0 took different amounts of time, I would recommend doing that.
Once the Tic has received your command, there is a variable delay of roughly 5 to 20 milliseconds before the command actually has an effect. The commands will come into effect in the order that you sent them, but it is possible that the new maximum speed will be in effect for some time before the new target position.
Also, one subtle detail is that in position control mode (which you are using), the Tic only decides to decelerate if it is getting close to its target position. If you change the maximum speed in the middle of a movement, and the maximum speed is lower than the current speed, that does not cause the Tic to decelerate immediately.
You might consider sending your commands slowly enough so that the Tic is able to reach its target position and decelerate down to a velocity of 0 before receiving the next command. That would probably make the movements more reliable, at the cost of speed.
thank you very much for the detailed explanation.
What I’m aiming at is that as soon as the robot reached target position i, it “immediately” continues its way towards target position i+1.
I have solved some of the timing problems by estimating the time needed for one straigth path and sending a linux sleep command parallel to/after the tic max-speed and position commands. Now at least the x and y movements are always synchronized, and the max-speeds do not overlap between straight paths.
However, because the sleep time estimate is never perfectly accurate, at every target position there is a noticable standstill of say 0.1s, which makes the robot very slow (on average) and literally shaky.
I’m curious: is there a way the ticcmd produces an output to the command line when the target position is reached? Say, a verbose mode? Alternatively, I will try to request the current position in a loop and compare continuously with the target position.
What I’m aiming at is that as soon as the robot reached target position i, it “immediately” continues its way towards target position i+1.
The Tic does not have that feature.
Another feature you would probably want is the ability to control what velocity the Tic has when it reaches its target position. Instead, what the Tic actually does is that it will start decelerating so that its velocity reaches 0 at the target position. If your acceleration or deceleration limits are low enough, that aspect of the Tic would cause shakiness.
I’m curious: is there a way the ticcmd produces an output to the command line when the target position is reached? Say, a verbose mode?
The Tic command-line utility does not have that feature.
You might consider looking into 3D printer firmware, since there are many options available and they have already solved the problem of keeping multiple stepper motors in sync. There is a big list of open source 3D printer firmware here:
You should be able to run firmware like that on one of our programmable controllers and use it to control your Tics in STEP/DIR mode, or use it to control our simpler DRV8834 carriers.
