Following a trajectory
-
not that i am aware of
-
And maybe there is a possibility to modify current move parameters without a stop? Or instantly execute a new move command?
-
@dascvcsadc said in Following a trajectory:
Alright, but can I interrupt any current move in real time (or within a second)? Sending move commands every second does not seem as a practical way.
sending lots of fairly short moves to the duet is fine (from the duet's perspective) so if the software you are using to predict, tract and correct the path can generate those moves then that would be the way to go. That way you don't need to have the interrupt, modify, restart move logic
-
@dascvcsadc I presume you are using some form of image analysis (either computer or human based) to confirm the object is still within the FOV. and if its drifting out of frame centre then you want to change the move so it returns it to frame centre? one concept we have in 3d printing that sort of applies is "baby stepping" this allows for additional "jogs" of an axis. normally used to ensure the nozzle is the correct height from the bed (so the "Z" axis is babystepped) however you can use it for other axis as well in more recent firmware. That might work - you send the overall trajectory predicted and then babystep the axis to modify that.
but I still think sending lots of shorter moves (multiple imtes/second) would be better, especially if your software that generates the moves can ensure there are minimal velocity changes between the moves so movement was smooth.
-
Why would you want to use something like a Duet to do this?
Two simple stepper-motor controllers getting step and direction signals from a PC should be able to track something a slow as a satellite with zero problems.
-
Because duet has working wifi,telnet, easily configurable, has 5 stepper drivers (i may need more than 2 steppers), inexpensive, does not require soldering it yourself, allows rather fast step rates?
On second thought, sending multiple move commands is not acceptable at all, because axes must move as smooth as possible (stops between commands will cause too much vibration). So i must generate the full trajectory file. I've forgot about the baby stepping. This might be the best solution for me. -
@dascvcsadc said in Following a trajectory:
On second thought, sending multiple move commands is not acceptable at all, because axes must move as smooth as possible (stops between commands will cause too much vibration)
if the movement is in the same direction there is no stop between the moves.
-
@dascvcsadc thinking about it more babystepping may work for "left/right" and the use M220 to increase/decrease speed along the path to match the speed of the satellite.
That said I am still not sure this approach is better than streaming lots of shorter moves. As @Veti says there will be no stop/start if there are always more moves to do in the queue, and the change of velocity between each move is small enough not to require an acceleration move (i.e. is below the jerk limit).
For an example on a 3d printer if I send a move G1 X100 F6000 there will be an movement involving acceleration to 100mm/s then a coast at 100mm/s then deceleration to 0.
If instead i have a file with 20 lines in it like:
G1 X5 F6000
G1 X10 F6000
... etc
G1 X95 F6000
G1 X100 F6000i.e. 20 individual 5mm moves. The same set of step pulses will be generated by the Duet, accelerate up to 100mm/s coast at 100mm/s, decelerate back to 0.
This is true as long as the length of the movements being set to the duet and the required speed is such that the Duet is not starved of moves because either 1) the source of moves is too slow, or 2) the moves are so short that the calculations take too long to do compared ot how long the moves take to execute. So in my example above if I sent 100K 1um moves that would be a problem, but 20, 5mm moves is fine
-
Thanks, i guess sending a short queue of moves should work. Maybe I don't even need real time, just keep the time one move would take below 1 second.
-
@dascvcsadc the length of moves will obviously impact on the responsiveness of control. this is something you can experiment with to get a reasonable responsiveness while not exceeding the moves/s that the duet can handle (and that your software can reliably produce).
