Closed valegagge closed 1 year ago
Regarding the message containing the temperature value, I suggest using the ADDTITIONAL_STATUS
.
Currently, ADDTITIONAL_STATUS
message contains only the interaction_mode
in the first byte.
In the canBusMotionControl devices
I noticed that the parser gets the interaction_mode
without any check on the message length. see here
In the firmware:
interaction_mode
. We need to update this function in order to verify that if size ==3, than we read the temperature valueUpdate regarding the parsing of the CAN frames:
Here the section of the code that does the parsing of the message sent by the 2FOC code:
As you can see, we are parsing the CAN frames using the for loop
over the only 2 joints that the FOC can control.
Therefore, we are taking the third and fourth bytes of the frame and saving to the temperature of the first motor entity. Then the fifth and sixth bytes (being the temperature a typedef int16_t) are saved to the temperature of the second motor entity.
Done. Remains only to define the conversion factor from V diff to Celsius
The activity has been completed and tested.
The temperature values are stored in the embObjMotionControl
class in this array: double *_temperatureValues
and a yarp module for retrieving the motor temperature and sending it to a user-defined yarp port has been developed and published here: https://github.com/MSECode/motionControlModule/tree/feature/temperatureManager.
It is possible to check the output of the test in this issue
Dod satisfied. closing
As per title. We need to define a new CAN periodic message and its period, but the ETH protocol is fine. The 2FOC and EMS fw should be updated according.
DoD The temperature values are stored in the EmbObjMotionControl. To test this feature, we need a test module that reads the motor temperature.