Skip to content

Commit

Permalink
Correct typos
Browse files Browse the repository at this point in the history
  • Loading branch information
MSECode committed Dec 7, 2023
1 parent 5b410bf commit 761db36
Show file tree
Hide file tree
Showing 3 changed files with 7 additions and 7 deletions.
8 changes: 4 additions & 4 deletions docs/temperature_sensors/general/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,8 @@ Thus, once that is done, and keeping in mind the points defined at the previous

### How to read the motor temperature
The user need to update the robot configuration files accordingly as described in the [configuration section](#how-to-update-the-configuration-files), after ensuring that the sensor has been mounted on the desired motors.
The correct configuration ensures that the motor temperature is read and forwarded to yarprobotinterface, but currently this measure in not published on the yarp `stateExt` port. Therefore the user needs to develop a module application similar to [this one](https://github.com/MSECode/motionControlModule), in order to read the tempereature.
The correct configuration ensures that the motor temperature is read and forwarded to yarprobotinterface, but currently this measure in not published on the yarp `stateExt` port. Therefore the user needs to develop a module application similar to [this one](https://github.com/MSECode/motionControlModule), in order to read the temperature.

In addition, the user modul can retrive the `warningTemperatureLimits` and check if the current teperature exceds that limit to put the motor in a less-current consumption state.
Is it important to notice that the firware put the motor in fault when the teperature goes beyond the `hardwareTemperatureLimits`.
More details on the temperature flow are availble in the section [data flow](../software/dataflow.md)
In addition, the user module can retrieve the `warningTemperatureLimits` and check if the current temperature exceeds that limit to put the motor in a less-current consumption state.
Is it important to notice that the firmware put the motor in fault when the temperature goes beyond the `hardwareTemperatureLimits`.
More details on the temperature flow are available in the section [data flow](../software/dataflow.md)
4 changes: 2 additions & 2 deletions docs/temperature_sensors/software/dataflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@ Generally speaking the data flow related to the whole pipeline of the sensing of
In a nutshell, as introduced in the [introductory section](../general/overview.md#temperature-sensors), most of the `ergoCub` motors are currently provided with a `PT100`, which is roughly a particular resistor able to correlate a value of temperature to a value of resistance in `Ohm`. This is then linked to a board called Temperature Detection Board (TDB), whose internal components are meaningless for our aim.
Anyways, its function is to evaluate the `Ohm` value given by the `PT100` (or `PT1000` for different types of motors) and streams out with a `I2C` protocol the raw data. This are then read by the `2FOC` board with a frequency of around 200Hz, which also checks if there's any `overHeating` error depending on the values set by the end-user in the configuration files at the parameter `hardwareTemperatureLimits`. The raw temperatures are sent over `CAN` to the `EMS` board, which stores them in the memory and sends to `embObjMotionControl` together all the other motor information.

On reception of the motor temperature, `embObjMotionControl` converts the values from raw to Celsius and checks if the set `warningTemperatureLimit` is overcome. In that case it print a warning on the yarprobotinterface log just to advise the user. Any other actions are taken.
On reception of the motor temperature, `embObjMotionControl` converts the values from raw to Celsius and checks if the set `warningTemperatureLimit` is overcome. In that case it prints a warning on the yarprobotinterface log just to advise the user. No other actions are taken.

It is important to note that in the whole pipeline we are doing two different checks for the temperature:

1. when reading the raw temperature value the `2FOC` board checks that it is not higher than the `hardwareTemperatureLimits`, otherwise it triggers the `overHEating` error and sends the fault state to the robot
1. when reading the raw temperature value the `2FOC` board checks that it is not higher than the `hardwareTemperatureLimits`, otherwise it triggers the `overHeating` error and sends the fault state to the robot
2. when the temperature is received and converted to Celsius degree by the `embObjMotionControl`, this checks that the passed value is not beyond the `warningTemperatureLimit`, otherwise it prints a warning log until the temperature drops.

### Main Flow of Information
Expand Down
2 changes: 1 addition & 1 deletion docs/temperature_sensors/software/reading_data.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ The use the calculated temporary value for evaluate the denominator of the final
where:
- _ptc_gradient: slope of the PTXXX line
- _r_2: one of the two upper resistors in the voltage divider bridge, which for us is equal to 4700 [Ohm]
- _r_3: lower resistor of the bridge, which it should be set equal to the value, in Ohm, of the PTXXX at zero degree. Thererfore, if we are using the PT100 it should be equal to 100
- _r_3: lower resistor of the bridge, which it should be set equal to the value, in Ohm, of the PTXXX at zero degree. Therefore, if we are using the PT100 it should be equal to 100

Finally, the last calculation that outputs the value of the got temperature in Celsius Degree is:

Expand Down

0 comments on commit 761db36

Please sign in to comment.