Timed command
A timed command is an order (one float number) sent to a subDevice actuator with a time when to apply the order. You can send one ore more timed command for one or more actuator in the same request.
The time is an absolute value, based on the system time in ms and in a 4 bytes integer. You can send a request to the DCM to get the current time (it's also in ALMemory), or read it directly if you have a module on the robot motherboard.
The DCM stores all timed command of each actuator, and then at each DCM cycle it will analyze the previous and next order based on the current time (if there are some) and compute the appropriate command to send using a linear interpolation.
Previous commands are deleted after their use.
| Note: |
Currently, there is a limit of 4096 timed commands stored in the DCM for each actuator. |
|---|
For suitable actuator and values (joints position, LEDs...), the DCM automatically generates a linear approximation between the previous command and the next one (if there is one).
This approximation is computed every DCM cycle and sent to the appropriate device (mainly USB transmission to the chestboard that follows up to other devices).
As the command time does not fit the update time of the DCM, values asked could not be reached precisely (see example below).
If there is no other order, the last one is kept and sent again all next DCM cycle.
It there is no interpolation possible (like for Ultra Sound actuator), the previous command is sent and then deleted. A future command has no effect.
A command sent to the present/former time means an instant update.
The main interests of timed command are:
- There is no need for the upper level to know precisely the DCM update time, because precise command times are automatically used by the DCM to send a good evolution of the command to actuators. The only thing is that you need to send command a bit in the future (more than one DCM cycle time).
- As the DCM knows the future of actuators commands, it can send them previously (using its own thread and the chestboard) so that there is no delay between two commands (from the actuator point of view), even if the module itself has a delay (due to CPU high usage or something else).
- By default, commands are smooth due to interpolation (smooth commands are always better for the robot). But you can still send very fast commands if you want (it could be dangerous for the robot as far as joints are concerned, beware!).
- The linear interpolation is simple but always suitable. For more complex interpolations, you can approximate them to a few linear ones. Using this, you reduce the number of commands to send to the low level.
- You can send a whole choreography to many actuators at the same time, and then whatever the communication delay or lags are (even using wifi), actuators commands will be sent correctly. But sending command using wifi or Internet means that you can not react very fast. You need to anticipate commands.
- You can synchronize many actuators from different modules, just sharing the date.
| Note: |
Sending a huge number of time commands on one request may delay the DCM cycle. |
|---|
| Warning: |
The better way to use timed command is to send them with at least a 10ms delay in the future. With this delay, the DCM can compute an interpolation in its next cycle, whatever the next cycle time is. |
|---|