Overview
| Note: |
To be more precise, the Preferences files are read by the DCM module, but they are visible throughout ALMemory. See below for more details. |
|---|
When other modules want to access actuators and sensors of the robot, they have two solutions:
- For sensors, they need to look into ALMemory with the name of
the subDevice sensor (or use a callback).
For most sensors, the DCM updates automatically sensors' values in ALMemory, and the module just needs to look at the new value. Some sensors (UltraSound...) need a request to an actuator to have a value updated.
- For actuators, modules need to send an update request to the
DCM, with a timed command (see the Timed command
section).
It is not allowed for other modules to change any DCM value in ALMemory directly. They need to ask the DCM first. Then the DCM itself changes the actuator value in ALMemory, but only when it has an acknowledgement from the device that the command is well sent, and with the precise value actually sent to the actuator.
Note: This last feature is still in development. Right now the value is updated directly, even if there is no acknowledgement. But you can check the ACK/NACK value to see if the device is responding.
Note: The value sent by the DCM to the actuator may not be the precise value asked: the value is rounded to the actuator precision, there is also a linear interpolation, and there could be a limitation of the value (min/max due to mechanical stop, or other limitations...).
The main module that sends actuators' order to the DCM is "motion" (at least for joints).
| Warning: |
The DCM itself does not have any resource management or priority system for modules. That means that every orders will be taken into account, even if they are contradictory. |
|---|
The DCM has a separate real time threads that run every 10ms (known as the DCM "Cycle") and manages every communication / actuator computation / sensor return, and goes back to sleep until the next cycle.