Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sensor naming convention #248

Merged
merged 3 commits into from
Jan 31, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -158,6 +158,15 @@ P.S. The parenthesis around some of the numbers in the table below are only for
| neck\_roll | Revolute | (-1) | 0 | 0 | | |
| neck\_yaw | Revolute | 0 | 0 | \(1\) | | |

## Sensors

The naming for the sensors mounted on `iCub` follows this naming convention:
pattacini marked this conversation as resolved.
Show resolved Hide resolved

`<link>_<type>_<nr>`

Where `link` is the name where the sensor is attached (e.g. `head`), `type` is the type of sensor (e.g. `imu`) and `nr` is a number starting from **0**.
pattacini marked this conversation as resolved.
Show resolved Hide resolved


## Frames
---
In literature and in robotics software, the links and frames concepts are often confused, because every link is usually associated with a frame rigidly attached to it. However this link frame definition is dependent on the formalism that one uses for describing the robot. For example, if the Denavit Hartenberg convention is used the link frame origin is required to be placed on the axis of the child joint, while if the Modified Denavit Hartenberg convention or the URDF format the link frame origin is required to be place on the axis of the parent joint. To avoid inconsistency, we clearly separate frame and link concepts.
Expand Down