I am wondering what are the available options for sending a start/stop command to multiple servos at the same time?
So far, in what i have seen, you can send a command to only a specific ID at one time, giving the value that a particular address should have.
What if there is a critical application that you want all the servos to perform an action at the same time?
Is there a function that can broadcast the command to many servos at the same time?
Is the option to use threads a good idea? I am guessing not, because even if you use threads, the commands will reach the servos sequentially, either way…
I am looking forward to hearing your opinions. Thank you very much!
@dood
In general, you will need to investigate the use of Group Sync Write/Read or Group Bulk Write/Read functions which are supported in the Dynamixel SDK for a variety of computing languages
If you are using the TASK V.3 tool, at present, only the CM-550 is capable of doing SyncWrite in TASK and MicroPython codes.
If your post meant that you just want to turn all DXLs on/off, you can also use the special Dynamixel ID of 254 (which stands for ALL Dynamixels used in your robot, i.e. the Broadcast ID) and use Torque On/Off functions.
Thanks. Yeah, i meant what is the correct way to turn all Dynamixels on/off? Should i just broadcast on ID 254, turning off the motor with a speed of 0?
But then you mentioned the torque. How the torque comes into play?
What is the correct way to turn them on/off?
The Torque Enable setting is the closest analog to powering the servos on and off without actually disconnecting them from power. When torque is disabled, the servo will not send any power to the motor, functonally disabling it. So to “Turn off” all connected DYANMIXELs, my reccomendation would be to use the broadcast ID to send Torque Off to all servos.
@dood@Jonathon
I just realized one side-effect of the Torque_Off(ID=254) command is that if your robot is a humanoid or manipulator arm, your robot would “spectacularly” collapse on itself when it receives the Torque_Off(ID=254) command!
@dood - you had the right hunch, a better procedure would be:
Set all DXL goal velocities to ZERO, via ID=254. Your robot would “freeze” at this point in time.
Now, your program would have the “time” to perform a regular FOR LOOP, based on an index i that varies through your particular group of DXL IDs used on your robot and the body of this FOR LOOP should contain at least this statement:
Goal_Position(i) = Present_Position(i)
This statement is critical because the Previous Goal Position commands were still in-play for all DXLs, you only just set their velocities to 0 due to the emergency so they could not go there (but they still wanted to ). So if later in your program, you reset your DXL Goal Velocities to a non-zero value, your robot would then “suddenly” want to move to its Old Goal Positions - you may not want this behavior from your robot. But with the suggested statement, the DXLs would already be at their “prescribed” Goal Positions when non-zero Velocities are used again. Essentially, your robot would restart from its frozen position (unfortunately, if your robot is a humanoid, most likely it may not be able to hold this frozen position for the FOR LOOP to finish).
Or, if you have a set of SAFE Goal Positions that the robot should be in after an emergency, you can use those values instead of Present Positions in the FOR Loop.
Finally, if you happen to be using ROBOTIS Motion Programming, I am assuming that you are familiar with the Special Motion Index values of 0, -1, -2 and -3?
@dood
From your other post about the XH-430 Position Control options, and if this robot is using XH-430s, then you have another even simpler solution for the newer DXLs like XL-430 and XH-430. For this newer series of DXLs, they have more sophisticated firmware so that you can change Goal Positions on the fly. Let’s say that you are sending your robot to a set of Target Goal Positions (TGP), but there is an emergency situation, so your DXLs have not reached these TGPs yet. But with the XL/XH-430s, at this point in time you can just send them to a new set of SAFE TGPs (using Group Sync Write or Motion Programming), and you don’t have to worry about those safety procedures that I described to you before which are required for older series like the AX or XL-320s. And the XH-430 can do these transitions much more smoothly than my previous solution of “freezing” the robot then move it to a safe configuration.
In my Youtube Video, I called them “Override Positions” - it is towards the end of this video
). So if later in your program, you reset your DXL Goal Velocities to a non-zero value, your robot would then “suddenly” want to move to its Old Goal Positions - you may not want this behavior from your robot. But with the suggested statement, the DXLs would already be at their “prescribed” Goal Positions when non-zero Velocities are used again. Essentially, your robot would restart from its frozen position (unfortunately, if your robot is a humanoid, most likely it may not be able to hold this frozen position for the FOR LOOP to finish).
