diff --git a/.github/workflows/check-links.yml b/.github/workflows/check-links.yml index 143d57338..43d6b4b25 100644 --- a/.github/workflows/check-links.yml +++ b/.github/workflows/check-links.yml @@ -11,15 +11,17 @@ jobs: runs-on: ubuntu-latest steps: + - uses: actions/checkout@main - name: Dependencies run: | - pip3 install git+https://github.com/linkchecker/linkchecker.git + pip install --user git+https://github.com/linkchecker/linkchecker.git + echo "${HOME}/.local/bin" >> ${GITHUB_PATH} - name: Fetch repository name id: repo-name run: | - echo "REPOSITORY_NAME=$(echo '${{ github.repository }}' | awk -F '/' '{print $2}')" >> $GITHUB_OUTPUT + echo "REPOSITORY_NAME=$(echo '${{ github.repository }}' | awk -F '/' '{print $2}')" >> ${GITHUB_OUTPUT} - name: Run checker run: | - linkchecker https://${{ github.repository_owner }}.github.io/${{ steps.repo-name.outputs.REPOSITORY_NAME }} + linkchecker --config=./scripts/linkchecker/linkcheckerrc https://${{ github.repository_owner }}.github.io/${{ steps.repo-name.outputs.REPOSITORY_NAME }}/ diff --git a/.gitpod.Dockerfile b/.gitpod.Dockerfile index fe34ba154..2b3591667 100644 --- a/.gitpod.Dockerfile +++ b/.gitpod.Dockerfile @@ -1,6 +1,9 @@ FROM ubuntu:latest LABEL org.opencontainers.image.authors="Ugo Pattacini " +# Increment this variable to force Docker to build the image for the sections below w/o relying on cache +ENV INVALIDATE_DOCKER_CACHE_ALL=0 + ENV DEBIAN_FRONTEND=noninteractive RUN apt update && \ diff --git a/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-01.png b/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-01.png new file mode 100644 index 000000000..287f59091 Binary files /dev/null and b/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-01.png differ diff --git a/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-02.png b/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-02.png new file mode 100644 index 000000000..4bdacb184 Binary files /dev/null and b/docs/battery_boards/bat_board/assets/bat-2-ems-R1-connection-02.png differ diff --git a/docs/battery_boards/bat_board/bat_protocol.md b/docs/battery_boards/bat_board/bat_protocol.md new file mode 100644 index 000000000..8e44f17cc --- /dev/null +++ b/docs/battery_boards/bat_board/bat_protocol.md @@ -0,0 +1,104 @@ +# BAT board Protocol + +## Introduction +This page describes the `BAT` board and its protocol. Basically, this board is responsible for the management of the data and signals provided by the battery pack in `R1`, `iCub`, and `ergoCub` robots. Moreover, it should be noted that in these robots it is always coupled with the `BMS` board, which is responsible for fine-tuning and managing the battery pack status. +In general, as shown in the figures below (illustrating the connection between the BAT and EMS boards in the base of `R1/SN003`), the `BAT` can be connected to an EMS board through the `CAN` connector devoted to receiving the CAN frames sent out by the `BAT`. + +
+ + + +
+
+ +Specifically, at the current status of the development (July 2023), the `BAT` board can send the following data: + +- Battery Pack Voltage in Volt. +- Battery Pack Charge in $\%$. +- Battery Pack Status (detail will follow). + +### Communication characteristics +The `BAT` board sends the pieces of information detailed above with a FIFO cycle of 1 ms. Then, the `EMS` board handles the CAN frames sent by the `BAT`, parses them, and finally forwards them to the higher level of the `yarprobotinterface` at the specific port defined in the configuration files with a frequency of 1 Hz. +Furthermore, that info is also sent directly from the `BAT` to the display attached to the robot, every 10 ms. + +### Types of data transmitted + +As mentioned at the end of the [introduction section](#introduction), the CAN frames sent by the `BAT` to the `EMS` and parsed by this latter board are: + +- Battery pack info message sent at address `0x620` as: + + | Byte | Value | Description | + |:---:|:---:|:---| + | 0 | Vbattery & 0xFF | LSBs of the battery pack voltage | + | 1 | (Vbattery >> 8) & 0xFF | MSBs of the battery pack voltage | + | 2 | 0x00 | Not used | + | 3 | 0x00 | Not used | + | 4 | battery_charge & 0xFF | byte of the battery pack charge | + | 5 | 0x00 | Not used | + | 6 | 0x00 | Not used | + | 7 | 0x00 | Not used | + +- Battery pack status message sent at address `0x629` as: + + | Byte | Value | Description | + |:---:|:---:|:---| + | 0 | DCDC_status_A & 0xFF | DCDC status A | + | 1 | DCDC_status_B & 0xFF | DCDC status A | + | 2 | 0x00 | Not used | + | 3 | 0x00 | Not used | + | 4 | 0x00 | Not used | + | 5 | 0x00 | Not used | + | 6 | 0x00 | Not used | + | 7 | 0x00 | Not used | + +where: + +- DCDC_status_A (bits are summed up together): + + Position | BIT[7] | BIT[6] | BIT[5] | BIT[4] | BIT[3] | BIT[2] | BIT[1] | BIT[0] | + |:---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| + Value | V12board | V12board_F | V12motor | V12motor_F | HSM | HSM_PG | HSM_F | HSM_broken | + Description | 12V DCDC board regulator | 12V DCDC board regulator OVERCURRENT fault | 12V DCDC motor regulator | 12V DCDC motor regulator OVERCURRENT fault | Hot Swap Manager | Hot Swap Manager POWER GOOD | Hot Swap Manager OVERCURRENT/OVERVOLTAGE fault | Hot Swap Manager MOSFETs damaged | + Possible status | ON(1)/OFF(0) | OC/NORMAL | ON/OFF | OC/NORMAL| ON/OFF | HSM output voltage stable after transient/HSM output voltage not guaranteed | OC-OV/NORMAL | HSM MOSFETs probably burned/NORMAL | + +- DCDC_status_B: + + Position | BIT[3] | BIT[2] | BIT[1] | BIT[0] | + |:---|:---:|:---:|:---:|:---:| + Value | HSM_SW_F | HSM_HW_F | PB1_restart | PB2_restart | + Description | OC Fault on the HSM triggered by overcurrent (threshold defined in the FW) | OC Fault on the HSM triggered by FLT Pin on the HSM micro | Restart phase of the push button 1 | Restart phase of the push button 2 | + Possible status | FAULT_OFF(0)/FAULT_ON(1) | FAULT_OFF(0)/FAULT_ON(1) | Start-up phase(1)/stable operation(0) | Start-up phase/stable operation | + +- Final status shown at the port is equal to: + + `(DCDC_status_B << 8 ) | DCDC_status_A` + +Thereby, the end user sees a decimal number on the BAT Display, which can be transformed into BITs and analyzed as described below: + +| BIT Position | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +| :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | +| VALUE | NAN | NAN | NAN | NAN | HSM_SW_F | HSM_HW_F | PB1 | PB2 | V12board | V12board_F | V12motor | V12motor_F | HSM | HSM_PG | HSM_F | HSM_broken | + +```console +Example: + +If we get 172 as a decimal value, then we will have in bits: + + 0000 0000 1010 1100 + +The active bits are thus related to: +- HSM_PG +- HSM +- V12motor +- V12board +``` + +### Data displayed on the YARP port +The user gets the data from a specific YARP port defined in the configuration file. Here's the format: + +- Voltage is displayed in the Volts. +- Battery charge is displayed in $\%$. +- Status is displayed as a 16-bit integer (only the first 10 bits are valid), whose mapping adheres to the tables above. + +Moreover, at start-up, a **DEBUG** message with the initial values of the status (converted to the description strings) is sent to `yarprobotinterface`. +Then, each time the status changes, a **DEBUG** message is sent to `yarprobotinterface`, which in turn prints out a description only about the values of those bits that have switched. diff --git a/docs/bcb_board/assets/fig-1.png b/docs/battery_boards/bcb_board/assets/fig-1.png similarity index 100% rename from docs/bcb_board/assets/fig-1.png rename to docs/battery_boards/bcb_board/assets/fig-1.png diff --git a/docs/bcb_board/assets/fig-2.png b/docs/battery_boards/bcb_board/assets/fig-2.png similarity index 100% rename from docs/bcb_board/assets/fig-2.png rename to docs/battery_boards/bcb_board/assets/fig-2.png diff --git a/docs/bcb_board/bcb_bluetooth_protocol.md b/docs/battery_boards/bcb_board/bcb_bluetooth_protocol.md similarity index 100% rename from docs/bcb_board/bcb_bluetooth_protocol.md rename to docs/battery_boards/bcb_board/bcb_bluetooth_protocol.md diff --git a/docs/battery_boards/index.md b/docs/battery_boards/index.md new file mode 100644 index 000000000..929b5cc61 --- /dev/null +++ b/docs/battery_boards/index.md @@ -0,0 +1,5 @@ +# Battery Documentation +Here you can find information about different boards related to the battery in the various versions of the robot and some related resources. + +- [**BCB Board Documentation**](./bcb_board/bcb_bluetooth_protocol.md) +- [**BAT Board Documentation**](./bat_board/bat_protocol.md) \ No newline at end of file diff --git a/docs/ergoCub1_wiring/ergoCub1_0.md b/docs/ergoCub1_wiring/ergoCub1_0.md index a74bf01ee..fb0400f2e 100644 --- a/docs/ergoCub1_wiring/ergoCub1_0.md +++ b/docs/ergoCub1_wiring/ergoCub1_0.md @@ -7,9 +7,5 @@ The system architecture of ergoCub1.0 is depicted in the following image: ### Logic and Harness ergoCub 1.0 E1.0 Full Robot -- [ergoCub1.0 Logic_1.2.0](https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/ergocub1/ergocub1.0/pdf/ergoCub1.1_E1.0_16963_1.2.0_Logic.pdf) -- [ergoCub1.0 Harness_1.2.0](https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/ergocub1/ergocub1.0/pdf/ergoCub1.1_E1.0_16965_1.2.0_Harness.pdf) - -!!! note "note" - motor and board placement is still under development - \ No newline at end of file +- [ergoCub1.0 Logic_1.0.0](https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/ergocub1/ergocub1.0/pdf/ergoCub1.0_E1.0_16963_1.0.0_Logic.pdf) +- [ergoCub1.0 Harness_1.0.0](https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/ergocub1/ergocub1.0/pdf/ergoCub1.0_E1.0_16965_1.0.0_Harness.pdf) diff --git a/docs/hands/hands_mk5.md b/docs/hands/hands_mk5.md index eb50ad81a..019dcdada 100644 --- a/docs/hands/hands_mk5.md +++ b/docs/hands/hands_mk5.md @@ -31,8 +31,8 @@ | Joint number | Motors | Identifier | Type | Parent link | Child link | HW lower limit | HW upper limit | SW low. l. | SW upp. l. | Notes | |--------------|--------|---------------|------|-----------------|-----------------|----------------|----------------|------------|------------|------------| | | | l_thumb_add | ROT | l_hand_palm | l_hand_thumb_1 | 0° | 90° | | | T1 in fig. | -| | | l_thumb_prox | ROT | l_hand_thumb_1 | l_hand_thumb_2 | 0° | 90° | | | T2 in fig. | -| | | l_thumb_dist | ROT | l_hand_thumb_2 | l_hand_thumb_3 | 0° | 59.2° | | | T3 in fig. | +| | | l_thumb_prox | ROT | l_hand_thumb_1 | l_hand_thumb_2 | 0° | 82.1° | | | T2 in fig. | +| | | l_thumb_dist | ROT | l_hand_thumb_2 | l_hand_thumb_3 | 0° | 53.6° | | | T3 in fig. | | | | l_index_add | ROT | l_hand_palm | l_hand_index_1 | 0° | 15° | | | I1 in fig. | | | | l_index_prox | ROT | l_hand_index_1 | l_hand_index_2 | 0° | 90° | | | I2 in fig. | | | | l_index_dist | ROT | l_hand_index_2 | l_hand_index_3 | 0° | 99.2° | | | I3 in fig. | diff --git a/docs/hands/hands_mk5_coupling.md b/docs/hands/hands_mk5_coupling.md index 5df14920f..ba01538a3 100644 --- a/docs/hands/hands_mk5_coupling.md +++ b/docs/hands/hands_mk5_coupling.md @@ -69,33 +69,33 @@ $$q_{1} = \tan^{- 1}\left( \frac{A_{y}(q_{0}) - P_{0y}}{A_{x}(q_{0}) - P_{0x}} \ The following table describes the coupling variables of the finger mechanisms in the **hand Mk5.1**. -| Name | UoM | | | Values | | | Description | | | | -|-------------|-----|-----------|-----------|------------|----------|-----------|------------------------------------------------------------------------------------|---|---|---| -| | | **THUMB** | **INDEX** | **MIDDLE** | **RING** | **PINKY** | | | | | -| $L_{0x}$ | mm | -5 | -5 | -5 | -5 | -5 | $x$ coordinate of the first end of the leverism | | | | -| $L_{0y}$ | mm | 4 | 4 | 4 | 4 | 4 | $y$ coordinate of the the first end of the leverism | | | | -| $L_{1x}$ | mm | 29 | 34 | 34 | 34 | 29 | $x$ coordinate of the second end of the leverism | | | | -| $L_{1y}$ | mm | 0.8 | 0.8 | 0.8 | 0.8 | 0.5 | $y$ coordinate of the second end of the leverism | | | | -| $P_{1x}$ | mm | 35 | 40 | 40 | 40 | 35 | $x$ coordinate of the axis of the joint between the first and the second phalanx | | | | -| $P_{1y}$ | mm | 1.5 | 1.5 | 1.5 | 1.5 | 1.5 | $y$ coordinate of the axis of the joint between the first and the second phalanx | | | | -| | | | | | | | | | | | -| $q_{0off}$ | deg | -97.54 | -97.54 | -97.54 | -97.54 | -97.52 | Angle of $A-C$ when the finger is fully open | | | | -| $q_{2bias}$ | deg | -173.35 | -173.35 | -173.35 | -173.35 | -170.53 | Angle of $L_1-P_1$ when the finger is fully open | | | | -| $q_{1off}$ | deg | 2.45 | 2.15 | 2.15 | 2.15 | 2.46 | Angle of $P_1-P_0$ when the finger is fully open | | | | -| $q_{1bias}$ | deg | -90 | -90 | -90 | -90 | -90 | Angle of $B-P_0$ when the finger is fully open | | | | -| | | | | | | | | | | | -| $q_{0max}$ | deg | -12 | -12 | -12 | -12 | -11.97 | Max value of $q_0$, i.e. when the finger is fully closed | | | | -| $q_{1max}$ | deg | 90 | 90 | 90 | 90 | 90 | Max value of $q_1$, same as above | | | | -| $q_{2max}$ | deg | 191.44 | 193.06 | 193.06 | 193.06 | 188.7 | Max value of $q_2$, same as above | | | | -| | | | | | | | | | | | -| $k$ | mm | 17.1 | 29.18 | 29.18 | 29.18 | 24.25 | Connecting rod length, $\|L_1-L_0\|$ | | | | -| $d$ | mm | 20.06 | 30.04 | 30.04 | 30.04 | 25.04 | Distance between the two joints, $P_1$ and $P_0$ | | | | -| $l$ | mm | 8.5 | 6.04 | 6.04 | 6.04 | 6.08 | Distance between $L_1$ and $P_1$ | | | | -| $b$ | mm | 6.24 | 6.4 | 6.4 | 6.4 | 6.4 | Distance between $L_0$ and $P_0$ | | | | -| $s$ | mm | 6.52 | 5.5 | 5.5 | 5.5 | 5.5 | Distance between joint $B$ of the connecting rod $A-B$ and joint $P_0$ | | | | -| $t$ | mm | 13 | 14.5 | 14.5 | 14.5 | 14.5 | Length of the connecting rod $A-B$ | | | | -| $f$ | mm | 6 | 5.5 | 5.5 | 5.5 | 5.5 | Length of the connecting rod $A-C$ | | | | -| $r$ | mm | 7.5 | 8.5 | 8.5 | 8.5 | 8.5 | Length of the connecting rod $D-C$ | | | | +| Name | UoM | | | Values | | | Description | +|-------------|-----|-----------|-----------|------------|----------|-----------|------------------------------------------------------------------------------------| +| | | **THUMB** | **INDEX** | **MIDDLE** | **RING** | **PINKY** | | +| $L_{0x}$ | mm | -5 | -5 | -5 | -5 | -5 | $x$ coordinate of the first end of the leverism | +| $L_{0y}$ | mm | 4 | 4 | 4 | 4 | 4 | $y$ coordinate of the the first end of the leverism | +| $L_{1x}$ | mm | 29 | 34 | 34 | 34 | 29 | $x$ coordinate of the second end of the leverism | +| $L_{1y}$ | mm | 0.8 | 0.8 | 0.8 | 0.8 | 0.5 | $y$ coordinate of the second end of the leverism | +| $P_{1x}$ | mm | 35 | 40 | 40 | 40 | 35 | $x$ coordinate of the axis of the joint between the first and the second phalanx | +| $P_{1y}$ | mm | 1.5 | 1.5 | 1.5 | 1.5 | 1.5 | $y$ coordinate of the axis of the joint between the first and the second phalanx | +| | | | | | | | | +| $q_{0off}$ | deg | -97.54 | -97.54 | -97.54 | -97.54 | -97.52 | Angle of $A-C$ when the finger is fully open | +| $q_{2bias}$ | deg | -173.35 | -173.35 | -173.35 | -173.35 | -170.53 | Angle of $L_1-P_1$ when the finger is fully open | +| $q_{1off}$ | deg | 2.45 | 2.15 | 2.15 | 2.15 | 2.46 | Angle of $P_1-P_0$ when the finger is fully open | +| $q_{1bias}$ | deg | -90 | -90 | -90 | -90 | -90 | Angle of $B-P_0$ when the finger is fully open | +| | | | | | | | | +| $q_{0max}$ | deg | -12 | -12 | -12 | -12 | -11.97 | Max value of $q_0$, i.e. when the finger is fully closed | +| $q_{1max}$ | deg | 90 | 90 | 90 | 90 | 90 | Max value of $q_1$, same as above | +| $q_{2max}$ | deg | 191.44 | 193.06 | 193.06 | 193.06 | 188.7 | Max value of $q_2$, same as above | +| | | | | | | | | +| $k$ | mm | 34.15 | 39.13 | 39.13 | 39.13 | 34.18 | Connecting rod length, $\|L_1-L_0\|$ | +| $d$ | mm | 35.03 | 40.03 | 40.03 | 40.03 | 35.03 | Distance between the two joints, $P_1$ and $P_0$ | +| $l$ | mm | 6.04 | 6.04 | 6.04 | 6.04 | 6.08 | Distance between $L_1$ and $P_1$ | +| $b$ | mm | 6.4 | 6.4 | 6.4 | 6.4 | 6.4 | Distance between $L_0$ and $P_0$ | +| $s$ | mm | 5.5 | 5.5 | 5.5 | 5.5 | 5.5 | Distance between joint $B$ of the connecting rod $A-B$ and joint $P_0$ | +| $t$ | mm | 14.5 | 14.5 | 14.5 | 14.5 | 14.5 | Length of the connecting rod $A-B$ | +| $f$ | mm | 5.5 | 5.5 | 5.5 | 5.5 | 5.5 | Length of the connecting rod $A-C$ | +| $r$ | mm | 8.5 | 8.5 | 8.5 | 8.5 | 8.5 | Length of the connecting rod $D-C$ | diff --git a/docs/icub_firmware/firmware/firmware.md b/docs/icub_firmware/firmware/firmware.md index 5a5c46863..64b7bba9e 100644 --- a/docs/icub_firmware/firmware/firmware.md +++ b/docs/icub_firmware/firmware/firmware.md @@ -3,18 +3,12 @@ Here you can find informations about updating firmware, changing boards properti ## FirmwareUpdater -With the `FirmwareUpdater` application it is possible to perform GUI-based FW update on both CAN- and ETH-based robots; the commonly used functionalities are: - -- Upload `application` firmware both on `ETH` boards and `CAN` boards -- Change the `IP addrress` for ethernet based boards -- Change the `CAN ID` for the CAN based boards -- Update the `bootloader` (advanced option) -- Access to the `F/T` sensors calibration data of the `STTRAIN`/`STRAIN2` - +With the [FirmwareUpdater](../firmwareupdater/firmwareupdater.md) application it is possible to perform GUI-based FW update on both CAN- and ETH-based robots. + ![FirmwareUpdater GUI](./img/2-firmware-updater.png) ## Firmware tools - With the FirmwareUpdater application it is possible to perform GUI-based FW update on both CAN- and ETH-based robots. + With the [FirmwareUpdater](../firmwareupdater/firmwareupdater.md) application it is possible to perform GUI-based FW update on both CAN- and ETH-based robots. Here you can find [quick](https://github.com/robotology/icub-firmware-build/blob/master/docs/FirmwareUpdater.readme.quick.txt ) and [detailed](https://github.com/robotology/icub-firmware-build/blob/master/docs/FirmwareUpdater.readme.fulldetails.txt ) instructions. @@ -51,196 +45,12 @@ You can view some of this information with: - scripts/FirmwareUpdater.script.info.all.sh: it prints the list of all boards with all details - scripts/FirmwareUpdater.script.topology.all.sh: it prints the list of all ETH boards in link order. -### Advanced operations -The user can also launch FirmwareUpdater in administration mode to perform advance (but also potentially destructive) operations: - -- change IP or CAN address, -- change bootstrap mode of boards, -- upload special system processes which helps maintenance and execution of the application, -- management of strain and strain2 boards. - -For how to operate in this mode please refer to [this](https://github.com/robotology/icub-firmware-build/tree/master/docs). - -### Robot Versions and Firmware -Below you'll find a detailed description of the various robot versions, in particular for the `board` type-`id` or `ip address`-`firmware` associations. and the services offered by each board. - -## Command Line Interface (CLI) -`FirmwareUpdater` provides a CLI with a set of options to do operations via the command line. - -By running `FirmwareUpdater -h`, you'll be prompted with the list of all available options: - - - -## CLI options to change CAN ID and IP address -Here's below a summary of the CLI functionalities: - -- CAN board ID via `SOCKETCAN` device -- CAN board ID via `ETH` device -- IP address of an ETH board - -### Change CAN ID via SOCKETCAN -In this example, we change the `CAN ID` on an `mtb` board connected via `SOCKETCAN` from 1 to 2. -The syntax of the command is the following : -```bash -FirmwareUpdater -g -e SOCKETCAN -i 0 -c 0 -n 1 -k 2 -``` -where : -- `-g -e SOCKETCAN -i 0 -c 0` is required to use a `SOCKETCAN` device (i.e. `ESD CAN/USB`) with `ID=0` and `canline=0` -- `-n 1 -k 2` changes old id 1 (-n 1) to 2 (-k 2) - - - - -### Change CAN ID via ETH -In this example, we change the `CAN ID` on an `mtb` board connected via `ETH ` through an `ems4` board w/ `IP address = 10.0.1.1` from 1 to 2. -The syntax of the command is the following : -```bash -FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 1 -k 2 -``` -where : -- `-g -e ETH -i eth1 -t 10.0.1.1 -c 1` is required to use a `ETH` device (i.e. `ems4`) with `ip address = 10.0.1.1` and `canline=1` -- `-n 1 -k 2` changes old id 1 (-n 1) to 2 (-k 2) - - - - -### Change IP address of an ETH board -In this example, we change the `IP address on an `ems4` board from `10.0.1.1` to 110.0.1.21. -The syntax of the command is the following : -```bash - FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -2 10.0.1.2 -``` -where : -- ` -g -e ETH -i eth1` is required to use a `ETH` device (i.e. `ems4`) -- `-t 10.0.1.1 -2 10.0.1.2` changes old i`IP address` 10.0.1.1 to 10.0.1.2 - - - -## How to use ETH boards with a different IP subnet -We provide here the instructions to use ETH boards with a subnet different from the standard 10.0.1.X. - -### Change IP to the board -Let's assume that the board we use has the `10.0.1.1` IP and that we aim to switch to `10.0.2.1`. You ought to follow these steps: - -1. Run `FirmwareUpdater -a` -2. Select the eth interface and then `Discover` -3. Select the board and then ` Force ETH Maintenance` -4. Select `Upload Application` and flash the new firmware (`icub-firmware-build` on branch `devel`) -4. Select `Change IP Address` and input `10.0.2.1` - -### Configure the system -1. Change the IP address of your ETH interface to `10.0.2.104` -2. Change the `firmwareupdater.ini` file including this line -```xml -ETH "10.0.2.104:3333" -``` -3. Reset the board and check if it is discoverable with the `FirmwareUpdater` -4. Change the following `xml` files : - -**/hardware/electronics/pc104.xml** -```xml - - - - - - - 10.0.2.104 - 12345 - 1 - 5 - - - -``` - -**hardware/electronics/knee-eb10-j0-eln.xml** -```xml - - - - - - - - - - - 10.0.2.1 - 12345 - mc4plus - 768 - 384 - - - - "knee-eb10-j0" - - 1000 - 400 - 300 - 300 - 5 - - - - - - true - 0.020 - 60.0 - - - - - - -``` - -### Run yarprobotinterace -Finally, if all the operations above came off, you're then able to run `yarprobotinterface` using the new subnet `10.0.2.X`. - -### Test -The software has been compiled also on the Linux machine running `yarprobotinterface` and it works. - -See below an example of `yarprobotinterface` running with a gateway set to `10.0.2.104` connected to an `ems4` board with address `10.0.2.1` and an `F/T` sensor (`strain2`) connected to it. - - - - -## Strain2 dedicated CLI Options - -The `CLI` options implemented for the strain2 (F/T sensors) are : - -- `-z` or `--load-dat-file` : Loads the calibration .dat file into STRAIN2 eeprom (pass the file.dat with -l or --file option) -``` -example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -z -l calibrationDataSN003.dat -``` -- `-w` or `--set-strain-sn ` : Sets the passed serialNumber (i.e. SN001) on STRAIN2 -``` -example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -w SN001 -``` -- `-j` or ``--set-strain-gains`` : Sets on STRAIN2 default gains to (8,24,24,10,10,24) , adjust the offset and check if some channel saturates -``` -example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -j -``` -- `-b` or `--get-canboard-version ` : Gets Bootloader or Application version ( must be y or n to save or not a file containing fw info) -``` -example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -b y -``` -- `-u` or `--save-dat-file` : Saves the calibration .dat file from STRAIN2 EEPROM -``` -example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -u -``` - -!!!info - **All the example are running on a setup with an `EMS4` board with `IP=10.0.1.1` and a `STRAIN2` board attached to it in the `CAN1` line with `ID=13`** - - ## Useful Resources Below a list of useful links: + - Low-level [boards programming](https://icub-tech-iit.github.io/procedures/tp-boards-programming/) (using degugger/programmer) - Firmware [sources](https://github.com/robotology/icub-firmware) - Firmware [binaries](https://github.com/robotology/icub-firmware-build) +- `FirmwareUpdater` [doc](../firmwareupdater/firmwareupdater.md) - `FirmwareUpdater` [sources](https://github.com/robotology/icub-main/tree/master/src/tools/FirmwareUpdater) diff --git a/docs/icub_firmware/firmwareupdater/firmwareupdater.md b/docs/icub_firmware/firmwareupdater/firmwareupdater.md new file mode 100644 index 000000000..c009e0e54 --- /dev/null +++ b/docs/icub_firmware/firmwareupdater/firmwareupdater.md @@ -0,0 +1,453 @@ +# FirmwareUpdater Walkthrough +With the `FirmwareUpdater` application it is possible to perform GUI-based FW update on both CAN- and ETH-based robots; the commonly used functionalities are: + +- Upload `application` firmware both on `ETH` boards and `CAN` boards +- Change the `IP addrress` for ethernet based boards +- Change the `CAN ID` for the CAN based boards +- Update the `eLoader` (advanced option) +- Update the `eUpdater` (advanced option) +- Change `bootstrap` mode +- Access to the `F/T` sensors calibration data of the `STTRAIN`/`STRAIN2`/`STRAIN2C` + + +To launch `FirmwareUpdater` GUI just open a terminal and type : + +```sh +FrimwareUpdater +``` + +![image](img/fu.png) + +!!!info + In order to have all possible drivers that `FirmwareUpdater` can use to communicate with the boards, make sure you have the [firmwareupdater.ini](https://github.com/robotology/icub-main/blob/master/src/tools/FirmwareUpdater/firmwareupdater.ini) file in the place where you launch the GUI + +## GUI interface +Here are described the main basic and advanced operations that the `FirmwareUpdater` GUI allows you to do. + + +### Operations on ETH boards +Here are the main operations on the ETH based boards. + +#### Discover +This allow you to discover all `ETH` boards in the current `IP subnet` (titpically `10.0.1.X) + +- In a terminal type `FirmwareUpdater` + +- It opens the GUI, select the `ETH` driver in the devices list and click `Discover` +If any ETH boards are availabe they'll be listed prompting board info. +Detailed processesinfo of each board are available in the `Board Properties` box clicking on the board. + +![image](img/fu-discover.png) + +#### Force ETH Maintenance +This allow you tu force the board in maintenance mode and do operations such as upload FW, change IP, change bootstrap mode etc.. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Force ETH Maintenance` + +You should see the board running in the `eUpdater` process and related version. + +![image](img/fu-maintenance.png) + +#### Force ETH Application +This allow you tu force the board in application mode. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Force ETH Application` + +You should see the board running in the `eApplication` process and related version. + +![image](img/fu-app.png) + +#### Set default boot process eUpdater +This allow you tu force the default boot process to eUpdater + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Set Def Boot eUpdater` + +![image](img/fu-defupdater.png) + +#### Set default boot process eApplication +This allow you tu force the default boot process to eApplication + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Set Def Boot eApplication` + +![image](img/fu-defapp.png) + +#### Change board IP address +This allow you to change the IP address of the board. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the board by checking its checkbox +- Click on `Change IP Address` and insert the wanted new IP address in the dialog box. + +![image](img/fu-change-ip.png) + +#### Upload Application +This allow you to upload a new application binary onto the board uP. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the board by checking its checkbox +- Click on `Upload Application` and browse to the correct binary application file (official FW binaries are located at https://github.com/robotology/icub-firmware-build) +- Click on `Set Def Boot eApplication` + +![image](img/fu-upload.png) + +#### Update of the eLoader +This allow you to update the eLoader. + +!!!warning + This is a critical operation! Do this only if strictly necessary and pay attention to respect the steps described! + If the procedure fails you'll have to flash the board using the debugger, this means that probably you'll have to unmount the board from the robot if not accessible. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox + +!!!warning + select only a board at once! + +- Click on `Force ETH Maintenance` +- Select the board by checking its checkbox +- Click on `Upload eLoader` and browse to the respective binary file (i.e. for a EMS select this [file](https://github.com/robotology/icub-firmware-build/blob/master/ETH/EMS/bin/environment/emsLoader.hex)) +- Verify that the new eLoader has been flashed : + - Select the `ETH` driver in the devices list + - Click on `Discover` + - Check the version in the `Board Properties` panel + +![image](img/fu-updeloader.png) + +#### Update of the eUpdater +This allow you to update the eLoader. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the board by checking its checkbox + +!!!warning + select only a board at once! + + +- Click on `Force ETH Maintenance` +- Select the board by checking its checkbox +- Click on `Upload Application` and browse to the binary file (i.e. for a EMS select this [file](https://github.com/robotology/icub-firmware-build/blob/master/ETH/EMS/bin/environment/emsApplPROGupdater.hex)) + +![image](img/fu-updeupdater-1.png) + +- Select the board by checking its checkbox +- Click on `Restart ETH Board(s)` +- wait at least 5 sec +- Select the `ETH` driver in the devices list +- Click on `Discover` +- The GUI will show that the executing process is `eApplPROGupdater` +- Select the board by checking its checkbox +- Click on `Upload eUpdater` and browse to the binary file (i.e. for a EMS select this [file](https://github.com/robotology/icub-firmware-build/blob/master/ETH/EMS/bin/environment/emsUpdater.hex)) + +![image](img/fu-updeupdater-2.png) + +- Click on `Set Def Boot eUpdater` +- Click on `Restart ETH Board(s)` +- Select the `ETH` driver in the devices list +- Click on `Discover` +- The board has Startup, Default, and Running processed all set to value eUpdater (see the right panel called `Board Properties`,group `Bootstrap Processes`). +- Select the board by checking its checkbox +- Click on `Upload Application` and browse to the correct binary application file (official FW binaries are located at https://github.com/robotology/icub-firmware-build) +- Click on `Set Def Boot eApplication` + +### Operations on CAN boards +Here are the main operations on the CAN based boards connected to ETH boards. + +#### Discover +This allow you to discover all `CAN` boards connected to a selected `ETH` board + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Discover` + +You should see all `CAN` boards connected to the slected `ETH` board. + +![image](img/fu-candiscover.png) + +#### Change CAN ID +This allow you to change the ID to a `CAN` board connected to a selected `ETH` board + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Discover` +- Select the `CAM` board on which you want to change the ID +- Click on `Chanhe CAN address` +- Type the new ID (1-14) int the dialog box an hit OK + +You should see the new board `CAN` ID set. + +![image](img/fu-canaddr.png) + +#### Upload CAN application +This allow you to upload a new application to a `CAN` board connected to a selected `ETH` board + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Discover` +- Select the `CAM` board on which you want to upload the new application +- Click on `Upload Application` +- Browse to the wanted binary file (i.e. for a `MTB4` board select this [file](https://github.com/robotology/icub-firmware-build/blob/master/CAN/mtb4/mtb4.hex)) + +You should see the new application version set. + +![image](img/fu-canupload.png) + +#### Discover hidden CAN boards +This section describes the procedure that you should use when you cannot discover a `CAN` board connected to a specific `ETH` board, even if the master `ETH` board is in `maintenance` mode and you checked that there are no hardware issues related to the cabling. +Here is the step-by-step procedure (also shown in the animated GIF at the end of the section): + +- In a terminal, type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`). +- Select the `ETH` driver in the devices list. +- Click on `Discover`. +- Select the `ETH` board under which you aim to discover the `CAN` board by ticking in its checkbox. +- If the `ETH` board `Status` is `application (IDLE)`, press the button `Force ETH Maintenance` and wait until the board `Status` has changed to `maintenance`. + +!!! warning + It is important that you run the following two points in a row quickly, just one after the other, without waiting more than `5 seconds` in between. + +- Click on `Restart ETH Board(s)`. +- Click on `Discover`. + +!!! note + These two steps are fundamental for sending the discovery signal while the `CAN` boards are booting. In the animated GIF below, the boards that are not discoverable (e.g., `strain2`) are in the status `canBootloader` and not `canApplication`. Forcing the restart of the `ETH` boards is crucial as it will power-cycle the `CAN` boards too. The discovery command should be then sent at that right moment, that is when the `CAN` board is in `canBootloader`. + +- Update the `CAN` board as usual. + + + +### Access Strain/Strain2/Strain2c calibration data +In order to acces the GUI containing the calibration data for F/T sensors do the following. + +- In a terminal type `FirmwareUpdater -a` (or `FirmwareUpdater --admin`) +- Select the `ETH` driver in the devices list +- Click on `Discover` +- Select the `ETH` board under which the `Strain/Strain2/Strain2c` is attached by checking its checkbox +- Click on `Force ETH Maintenance` +- Select the `ETH` board under which you want discover `CAN` boards by checking its checkbox +- Click on `Discover` +- Select the `Strain/Strain2/Strain2c` board on which you want to visualize calibation data by checking its checkbox +- Click on `Calibrate` + +![image](img/fu-calib1.png) +![image](img/fu-calib2.png) + +## Command Line Interface (CLI) +`FirmwareUpdater` provides a CLI with a set of options to do operations via the command line. + +By running `FirmwareUpdater -h`, you'll be prompted with the list of all available options: + + + +### CLI options to change CAN ID and IP address +Here's below a summary of the CLI functionalities: + +- CAN board ID via `SOCKETCAN` device +- CAN board ID via `ETH` device +- IP address of an ETH board + +#### Change CAN ID via SOCKETCAN +In this example, we change the `CAN ID` on an `mtb` board connected via `SOCKETCAN` from 1 to 2. +The syntax of the command is the following : +```bash +FirmwareUpdater -g -e SOCKETCAN -i 0 -c 0 -n 1 -k 2 +``` +where : +- `-g -e SOCKETCAN -i 0 -c 0` is required to use a `SOCKETCAN` device (i.e. `ESD CAN/USB`) with `ID=0` and `canline=0` +- `-n 1 -k 2` changes old id 1 (-n 1) to 2 (-k 2) + + + + +#### Change CAN ID via ETH +In this example, we change the `CAN ID` on an `mtb` board connected via `ETH ` through an `ems4` board w/ `IP address = 10.0.1.1` from 1 to 2. +The syntax of the command is the following : +```bash +FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 1 -k 2 +``` +where : +- `-g -e ETH -i eth1 -t 10.0.1.1 -c 1` is required to use a `ETH` device (i.e. `ems4`) with `ip address = 10.0.1.1` and `canline=1` +- `-n 1 -k 2` changes old id 1 (-n 1) to 2 (-k 2) + + + + +#### Change IP address of an ETH board +In this example, we change the `IP address on an `ems4` board from `10.0.1.1` to 110.0.1.21. +The syntax of the command is the following : +```bash + FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -2 10.0.1.2 +``` +where : +- ` -g -e ETH -i eth1` is required to use a `ETH` device (i.e. `ems4`) +- `-t 10.0.1.1 -2 10.0.1.2` changes old i`IP address` 10.0.1.1 to 10.0.1.2 + + + +## How to use ETH boards with a different IP subnet +We provide here the instructions to use ETH boards with a subnet different from the standard 10.0.1.X. + +### Change IP to the board +Let's assume that the board we use has the `10.0.1.1` IP and that we aim to switch to `10.0.2.1`. You ought to follow these steps: + +1. Run `FirmwareUpdater -a` +2. Select the eth interface and then `Discover` +3. Select the board and then ` Force ETH Maintenance` +4. Select `Upload Application` and flash the new firmware (`icub-firmware-build` on branch `devel`) +4. Select `Change IP Address` and input `10.0.2.1` + +### Configure the system +1. Change the IP address of your ETH interface to `10.0.2.104` +2. Change the `firmwareupdater.ini` file including this line +```xml +ETH "10.0.2.104:3333" +``` +3. Reset the board and check if it is discoverable with the `FirmwareUpdater` +4. Change the following `xml` files : + +**/hardware/electronics/pc104.xml** +```xml + + + + + + + 10.0.2.104 + 12345 + 1 + 5 + + + +``` + +**hardware/electronics/knee-eb10-j0-eln.xml** +```xml + + + + + + + + + + + 10.0.2.1 + 12345 + mc4plus + 768 + 384 + + + + "knee-eb10-j0" + + 1000 + 400 + 300 + 300 + 5 + + + + + + true + 0.020 + 60.0 + + + + + + +``` + +### Run yarprobotinterace +Finally, if all the operations above came off, you're then able to run `yarprobotinterface` using the new subnet `10.0.2.X`. + +### Test +The software has been compiled also on the Linux machine running `yarprobotinterface` and it works. + +See below an example of `yarprobotinterface` running with a gateway set to `10.0.2.104` connected to an `ems4` board with address `10.0.2.1` and an `F/T` sensor (`strain2`) connected to it. + + + + +### Strain2 dedicated CLI Options + +The `CLI` options implemented for the strain2 (F/T sensors) are : + +- `-z` or `--load-dat-file` : Loads the calibration .dat file into STRAIN2 eeprom (pass the file.dat with -l or --file option) +``` +example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -z -l calibrationDataSN003.dat +``` +- `-w` or `--set-strain-sn ` : Sets the passed serialNumber (i.e. SN001) on STRAIN2 +``` +example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -w SN001 +``` +- `-j` or ``--set-strain-gains`` : Sets on STRAIN2 default gains to (8,24,24,10,10,24) , adjust the offset and check if some channel saturates +``` +example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -j +``` +- `-b` or `--get-canboard-version ` : Gets Bootloader or Application version ( must be y or n to save or not a file containing fw info) +``` +example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -b y +``` +- `-u` or `--save-dat-file` : Saves the calibration .dat file from STRAIN2 EEPROM +``` +example : FirmwareUpdater -g -e ETH -i eth1 -t 10.0.1.1 -c 1 -n 13 -u +``` + +!!!info + **All the example are running on a setup with an `EMS4` board with `IP=10.0.1.1` and a `STRAIN2` board attached to it in the `CAN1` line with `ID=13`** + + +## Useful Resources +Below a list of useful links: + +- Firmware [binaries docs](https://github.com/robotology/icub-firmware-build/tree/master/docs) +- Firmware [binaries](https://github.com/robotology/icub-firmware-build) +- Low-level [boards programming](https://icub-tech-iit.github.io/procedures/tp-boards-programming/) (using degugger/programmer) + + diff --git a/docs/icub_firmware/firmwareupdater/img/fu-app.png b/docs/icub_firmware/firmwareupdater/img/fu-app.png new file mode 100644 index 000000000..ee58116e3 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-app.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-calib1.png b/docs/icub_firmware/firmwareupdater/img/fu-calib1.png new file mode 100644 index 000000000..383939e73 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-calib1.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-calib2.png b/docs/icub_firmware/firmwareupdater/img/fu-calib2.png new file mode 100644 index 000000000..042455a6a Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-calib2.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-canaddr.png b/docs/icub_firmware/firmwareupdater/img/fu-canaddr.png new file mode 100644 index 000000000..00456c886 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-canaddr.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-candiscover.png b/docs/icub_firmware/firmwareupdater/img/fu-candiscover.png new file mode 100644 index 000000000..b2127fd0e Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-candiscover.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-canupload.png b/docs/icub_firmware/firmwareupdater/img/fu-canupload.png new file mode 100644 index 000000000..a0a7752ec Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-canupload.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-change-ip.png b/docs/icub_firmware/firmwareupdater/img/fu-change-ip.png new file mode 100644 index 000000000..f7fd2d00d Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-change-ip.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-defapp.png b/docs/icub_firmware/firmwareupdater/img/fu-defapp.png new file mode 100644 index 000000000..a49afb3ee Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-defapp.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-defupdater.png b/docs/icub_firmware/firmwareupdater/img/fu-defupdater.png new file mode 100644 index 000000000..b32e139a3 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-defupdater.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-discover.png b/docs/icub_firmware/firmwareupdater/img/fu-discover.png new file mode 100644 index 000000000..b0c1822e3 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-discover.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-maintenance.png b/docs/icub_firmware/firmwareupdater/img/fu-maintenance.png new file mode 100644 index 000000000..c1d19252d Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-maintenance.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-updeloader.png b/docs/icub_firmware/firmwareupdater/img/fu-updeloader.png new file mode 100644 index 000000000..6f7058603 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-updeloader.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-1.png b/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-1.png new file mode 100644 index 000000000..d6b98389f Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-1.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-2.png b/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-2.png new file mode 100644 index 000000000..2d136d12b Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-updeupdater-2.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu-upload.png b/docs/icub_firmware/firmwareupdater/img/fu-upload.png new file mode 100644 index 000000000..10a2864ae Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu-upload.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/fu.png b/docs/icub_firmware/firmwareupdater/img/fu.png new file mode 100644 index 000000000..9aefa5bad Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/fu.png differ diff --git a/docs/icub_firmware/firmwareupdater/img/procedure-discover-hidden-can-boards.gif b/docs/icub_firmware/firmwareupdater/img/procedure-discover-hidden-can-boards.gif new file mode 100644 index 000000000..c4e65a7e9 Binary files /dev/null and b/docs/icub_firmware/firmwareupdater/img/procedure-discover-hidden-can-boards.gif differ diff --git a/docs/icub_firmware/index.md b/docs/icub_firmware/index.md index 1c20ceddb..97ce0a8f1 100644 --- a/docs/icub_firmware/index.md +++ b/docs/icub_firmware/index.md @@ -1,9 +1,7 @@ # Firmware Documentation Here you can find information about firmware in the various versions of the robot and some related resources. -[**Firmware Toolchain Documentation**](./fw_toolchain/index.md) - -[**Firmware Documentation**](./firmware/firmware.md) - -[**Associated Firmware**](./associated-firmware/associated-firmware.md) - +- [**Firmware Toolchain Documentation**](./fw_toolchain/index.md) +- [**Firmware Documentation**](./firmware/firmware.md) +- [**FirmwareUpdater Walkthrough**](./firmwareupdater/firmwareupdater.md) +- [**Associated Firmware**](./associated-firmware/associated-firmware.md) diff --git a/docs/icub_force_control/icub-force-control.md b/docs/icub_force_control/icub-force-control.md index ae367c6c7..ebc5af309 100644 --- a/docs/icub_force_control/icub-force-control.md +++ b/docs/icub_force_control/icub-force-control.md @@ -155,7 +155,7 @@ Repeat the command above for all parts having a sensor (typically left_arm, righ after the RobotName, in the first lines. -- Open yarpmotorgui and check the torque value reading for affected joints, typically they should read as follow : +- Open yarpmotorgui and check the torque value reading for affected joints, typically they should read as follows: |Part|Joint 0|Joint 1| Joint 2 | Joint 3 | Joint 4 | |---|---|---|---|---|---| @@ -184,16 +184,16 @@ For each part to test, first select soft spring, move it by hand checking a righ ## `wholebodydynamics` YARP device -The `wholebodydynamics` YARP device (contained in the C++ class [`yarp::dev::WholeBodyDynamicsDevice`](http://wiki.icub.org/codyco/dox/html/classyarp_1_1dev_1_1WholeBodyDynamicsDevice.html)) +The `wholebodydynamics` YARP device (contained in the C++ class [`yarp::dev::WholeBodyDynamicsDevice`](https://github.com/robotology/whole-body-estimators/blob/master/devices/wholeBodyDynamics/README.md)) is reading measurements of the embedded force-torque sensors, of the joint position and low-level estimates of joint velocity and accelerations and of one IMU mounted in the robot, and from this reading is estimating the external force-torques and internal joint torques of the robot. ## Differences with respect to the wholeBodyDynamics YARP module From the user perpective, the main differences w.r.t. to the wholeBodyDynamics YARP module are: * The estimation is performed using the iDynTree library, replacing the use of the iDyn library. -* The model of the robot and of the sensor is loaded from a URDF model, as documented in https://github.com/robotology/idyntree/blob/master/doc/model_loading.md . - This permits to run the estimation algorithm on arbitrary robot without modifyng the code, as in the case of the iCubHeidelberg01 that w.r.t. to normal iCub is missing the head and the arms. -* The RPC interface is implemented using [YARP Thrift](http://www.yarp.it/thrift_tutorial_simple.html). +* The model of the robot and of the sensor is loaded from a URDF model, as documented in https://github.com/robotology/idyntree/blob/master/doc/model_loading.md. + This permits running the estimation algorithm on arbitrary robots without modifying the code, as in the case of the iCubHeidelberg01 that w.r.t. to normal iCub is missing the head and the arms. +* The RPC interface is implemented using [YARP Thrift](https://yarp.it/latest//thrift_tutorial_simple.html). This means that the `0` shorthand for performing the calibration of the force-torque offset is not supported anymore. The `calib` command however is compatible between the wholeBodyDynamics YARP module and the `wholebodydynamics` YARP device, so please use that one in your code to be compatible with both interfaces. * The functionality of the gravityCompensator module are now integrated in the `wholebodydynamics` device, and can be enabled/disabled using the parameters in the `GRAVITY_COMPENSATION` group. diff --git a/docs/icub_kinematics/icub-robot-configuration/icub-robot-configuration.md b/docs/icub_kinematics/icub-robot-configuration/icub-robot-configuration.md index 10d9457af..97a6686eb 100644 --- a/docs/icub_kinematics/icub-robot-configuration/icub-robot-configuration.md +++ b/docs/icub_kinematics/icub-robot-configuration/icub-robot-configuration.md @@ -4,9 +4,9 @@ The aim of this page is to explain the configuration of a Ethernet based robot a ## Introduction --- -[Yarprobotinterface](http://www.yarp.it/git-master/yarprobotinterface.html) application starts all devices and modules required by a robot to work properly. Any device needs a configuration data set that could differs from robot to robot, so each robot has own configuration, saved in xml files contained in a folder called with robot's name in the repository [robots-configuration](https://github.com/robotology/robots-configuration). +[yarprobotinterface](https://yarp.it/latest/group__yarprobotinterface.html) application starts all devices and modules required by a robot to work properly. Any device needs a configuration data set that could differs from robot to robot, so each robot has own configuration, saved in xml files contained in a folder called with robot's name in the repository [robots-configuration](https://github.com/robotology/robots-configuration). -Each robot has a main configuration file, usually named icub_all.xml, that contains the list of all devices and other modules, like Calibrators and Cartesian, that [Yarprobotinterface](http://www.yarp.it/git-master/yarprobotinterface.html) starts. +Each robot has a main configuration file, usually named icub_all.xml, that contains the list of all devices and other modules, like Calibrators and Cartesian, that [yarprobotinterface](https://yarp.it/latest/group__yarprobotinterface.html starts. (Note: here "device" means DeviceDriver of Yarp. The reader is supposed to have knowledge about a driver and a wrapper of yarp. If not, please see [YARP documentation](http://www.yarp.it/).) @@ -33,7 +33,7 @@ RobotNameFolder: - Mechanicals: description of mechanical features involved in motion control - Wrappers: configuration of yarp wrappers of devices - Some .ini files. Among .ini files, there is yarprobotinterface.ini that specifies which is the file containing list of devices to start, usually its name is [icub_all.xml](https://github.com/robotology/robots-configuration/blob/master/iCubTemplates/iCubTemplateV3_0/icub_all.xml). -- [general.xml](https://github.com/robotology/robots-configuration/blob/master/iCubTemplates/iCubTemplateV3_0/general.xml): contains some flags that change behavior of [Yarprobotinterface](http://www.yarp.it/git-master/yarprobotinterface.html). +- [general.xml](https://github.com/robotology/robots-configuration/blob/master/iCubTemplates/iCubTemplateV3_0/general.xml): contains some flags that change behavior of [yarprobotinterface](https://yarp.it/latest/group__yarprobotinterface.html). In the following snippet there is typical main configuration file: it shows the configuration of left arm only. If you desire to have look at the entire file, see icub_all.xml in a robot folder. @@ -188,7 +188,7 @@ The calibrator in the startup phase launches the calibration procedure: after a - If the joint completes the calibration sucessfully, then it tries to move it to the “startupPosition” using “startupVelocity” specified in calibration file. If an error occurred in calibration phase, the joint is in fault error. - If the “startupPosition” is reached, then the joint is ready, else is in fault error. -When the user shuts down [Yarprobotinterface](http://www.yarp.it/git-master/yarprobotinterface.html), the calibrator moves all joints to the park position, that is the position specified in “positionHome” parameter using “velocityHome”. +When the user shuts down [yarprobotinterface](https://yarp.it/latest/group__yarprobotinterface.html), the calibrator moves all joints to the park position, that is the position specified in “positionHome” parameter using “velocityHome”. ## Note for robots in iCub Tech (IIT Genoa, Italy) --- diff --git a/docs/icub_microphones/icub_microphones.md b/docs/icub_microphones/icub_microphones.md index 83580bb23..009b68671 100644 --- a/docs/icub_microphones/icub_microphones.md +++ b/docs/icub_microphones/icub_microphones.md @@ -1,44 +1,44 @@ # iCub Microphones -This page gives info about recording and playing back sound troght the `icub-head` microphones +This page gives info about recording and playing back sound troght the `icub-head` microphones. ## Dependencies For using the head microphones we must install the `PortAudio` on the head and local computer. - Install portaudio (in Ubuntu `sudo apt install portaudio19-dev`) -- In the cmake configurations, we should turn on four options by running ccmake . in the `yarp` folder: +- In the cmake configurations, we should turn on four options by running ccmake . in the `yarp` folder: ```xml - ENABLE_yarpmod_AudioPlayerWrapper ON - ENABLE_yarpmod_AudioRecorderWrapper ON - ENABLE_yarpmod_portaudio ON + ENABLE_yarpmod_AudioPlayerWrapper ON + ENABLE_yarpmod_AudioRecorderWrapper ON + ENABLE_yarpmod_portaudio ON ENABLE_yarpmod_portaudioPlayer ON - ENABLE_yarpmod_portaudioRecorder ON + ENABLE_yarpmod_portaudioRecorder ON ``` -- Run `make -j4` +- Run `make` If you rely on [`robotology-superbuild`](https://github.com/robotology/robotology-superbuild), the configuration and the building process will automatically take care of the `portaudio`related options. ## Recording and Playback Recording and playback is supported in yarp via `libportaudio`, which wraps on the top of the linux device drivers. - These yarp devices are `portaudioPlayer` (http://www.yarp.it/git-master/classPortAudioPlayerDeviceDriver.html) and `portaudioRecorder` (http://www.yarp.it/git-master/classPortAudioRecorderDeviceDriver.html), we need to enable them from ccmake when we compile yarp on the laptop (the option is avilable only if libportaudio needs to be installed). On icub, these devices are already enabled by default. + These yarp devices are [`portaudioPlayer`](http://www.yarp.it/git-master/classPortAudioPlayerDeviceDriver.html) and [`portaudioRecorder`](http://www.yarp.it/git-master/classPortAudioRecorderDeviceDriver.html), we need to enable them from ccmake when we compile yarp on the laptop (the option is avilable only if libportaudio needs to be installed). On icub, these devices are already enabled by default. - Then, yarp has two network wrappers to send received audio data to/from the network. These devices are `AudioPlayerWrapper` (http://www.yarp.it/git-master/classAudioPlayerWrapper.html) and `AudioRecorderWrapper` (http://www.yarp.it/git-master/classAudioRecorderWrapper.html) . Again, we need to check our yarp ccmake configuration to enable and compile them. + Then, yarp has two network wrappers to send received audio data to/from the network. These devices are [`AudioPlayerWrapper`](http://www.yarp.it/git-master/classAudioPlayerWrapper.html) and [`AudioRecorderWrapper`](http://www.yarp.it/git-master/classAudioRecorderWrapper.html) . Again, we need to check our yarp ccmake configuration to enable and compile them. We can record audio from a microphone and stream it over the network with the command: - ``` + ```console yarpdev --device AudioRecorderWrapper --subdevice portaudioRecorder --start ``` On the other side, we can played some sound received from the network with: - ``` + ```console yarpdev --device AudioPlayerWrapper --subdevice portaudioPlayer --start ``` We can connect the two modules with the command: - ``` - yarp connect /audioPlayerRecorder/audio:o /audioPlayerWrapper/audio:i tcp_fast + ```console + yarp connect /audioRecorderWrapper/audio:o /audioPlayerWrapper/audio:i fast_tcp ``` The option --start will automatically enable the devices on startup; otherwise, we can start/stop the recording/playback by sending the command on the corresponding RPC ports. @@ -57,10 +57,10 @@ Please note that buffering introduces some inevitable delay (five seconds by def - read the audio data directly from the `/audioPlayerRecorder/audio:o` port - open an AudioPlayerWrapper in your module, using the standard polydriver. -- + Using the second option, the audio packets should be already assembled by the wrapper. - Finally, we also have some test devices: +Finally, we also have some test devices: ``` yarp_fakeMicrophone @@ -69,20 +69,25 @@ Using the second option, the audio packets should be already assembled by the wr yarp_audioFromFileDevice ``` - which can be used for testing/development purpose without the need of the real hardware. +which can be used for testing/development purpose without the need of the real hardware. ### Grabbing audio from the microphones -```xml -yarpdev --device AudioRecorderWrapper --subdevice portaudioRecorder --start on the head pc104, you'll get audio from icub microphones. +If you launch the following on the icub-head: + +```console +yarpdev --device AudioRecorderWrapper --subdevice portaudioRecorder --start ``` + +you'll get audio from icub microphones. + ### Simulate a microphone -If you want to simulate a microphone, i.e. play a file from disk: -```xml +If you want to simulate a microphone, i.e. play a file from disk, type: + +```console yarpdev --device AudioRecorderWrapper --subdevice audioFromFileDevice --file_name myfile.wav --start ``` -In both cases, the port opened by default by AudioRecorderWrapper is /audioRecorderWrapper/audio:o. You can check the options described in AudioRecorderWrapper.h if you want to choose a custom port name. +In both cases, the port opened by default by AudioRecorderWrapper is `/audioRecorderWrapper/audio:o``. You can check the options described in AudioRecorderWrapper.h if you want to choose a custom port name. ## References -- http://www.portaudio.com/ - +- http://www.portaudio.com diff --git a/docs/icub_operating_systems/icubos/bios.md b/docs/icub_operating_systems/icubos/bios.md index 95c5b3a12..007efb3d6 100644 --- a/docs/icub_operating_systems/icubos/bios.md +++ b/docs/icub_operating_systems/icubos/bios.md @@ -1,6 +1,6 @@ # The OS on icub-head - BIOS tweaks -Some tweaks to the bios are necessary to setup the icub-head board (*Kontron COMe-cKL6*). +Some tweaks to the BIOS are necessary to setup the icub-head board (*Kontron COMe-cKL6*). They are directly realted to icubOS installation and it's necessary to perform the tweaks below only once, regadless if the operating systems is reinstalled. ## How to access BIOS @@ -10,8 +10,7 @@ Then, power on the board and press a key (it is different on each model of the i ## How to set the max power (TDP) of the processor -Set the TDP to 10000 (10w). See page 65 of the user manual of the board for more details https://www.kontron.com/downloads/manuals/c/come-ckl6_user-guide_rev-1.5_2020-07-23.pdf?product=146491 - +Set the TDP to 10000 (10w). See page 65 of the user manual of the board for more details, which you can download from https://www.kontron.com/en/products/come-ckl6/p146491. ## USB Legacy support diff --git a/docs/icub_operating_systems/icubos/installation-from-scratch.md b/docs/icub_operating_systems/icubos/installation-from-scratch.md index e905f16be..049d1fada 100644 --- a/docs/icub_operating_systems/icubos/installation-from-scratch.md +++ b/docs/icub_operating_systems/icubos/installation-from-scratch.md @@ -1,74 +1,75 @@ # The OS on icub-head - Installation from scratch -Since iCubOS is based on Ubuntu server, we will install Ubuntu server from the default installer and the we manually costimize it +Since iCubOS is based on the Ubuntu server, we will install it from the default installer and then manually customize it. -# Latest versions +## Latest versions -Latest version is based on Ubuntu Server 20.04.1 +The latest version is based on Ubuntu Server 20.04.1 -# Create the USB installer +## Create the USB installer -The first step is to download the [official Ubuntu 20.04 LTS Server install media](https://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso) from the [release page](https://releases.ubuntu.com/focal) +The first step is to download the **official Ubuntu 20.04 LTS Server install media** from the [release page](https://releases.ubuntu.com/focal). Search for `ubuntu-20.04.x-live-server-amd64.iso`. -Then please create the USB installer using an USB memory and a tool like [Balena Etcher](https://www.balena.io/etcher/). +Then, please create the USB installer using a USB memory and a tool like [Balena Etcher](https://www.balena.io/etcher/). -On Ubuntu website, you can find further informations about creating a bootable USB stick on [Windows](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-windows?_ga=2.181742695.1184983981.1588944309-600352565.1586438290), [Ubuntu](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-ubuntu?_ga=2.181742695.1184983981.1588944309-600352565.1586438290) or [macOS](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-macos?_ga=2.236980288.1184983981.1588944309-600352565.1586438290) +On the Ubuntu website, you can find further information about creating a bootable USB stick on [Windows](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-windows?_ga=2.181742695.1184983981.1588944309-600352565.1586438290), [Ubuntu](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-ubuntu?_ga=2.181742695.1184983981.1588944309-600352565.1586438290) or [macOS](https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-macos?_ga=2.236980288.1184983981.1588944309-600352565.1586438290) -# Install Ubuntu +## Install Ubuntu -Follow the below steps to install Ubuntu server on icub-head. +Follow the below steps to install the Ubuntu server on icub-head. -Please note that the installation procedure can be slight different in each release, you can see the [Ubuntu server official install guide](https://ubuntu.com/tutorials/tutorial-install-ubuntu-server) +Please, note that the installation procedure can be slightly different in each release, you can see the [Ubuntu server official install guide](https://ubuntu.com/tutorials/tutorial-install-ubuntu-server) -**WARNING** : the installation procedure will overwrite the disk of your icub-head, so all data will be deleted. +!!! warning -## Ubuntu Installer configuration + The installation procedure will overwrite the disk of your icub-head, so all data will be deleted. -Install the system by choosing the default options, except the follow steps: +### Ubuntu Installer configuration -### Keyboard and language +Install the system by choosing the default options, except for the following steps: + +#### Keyboard and language - **Layout** : `US` - **Variant** : `US` -### Storage configuration +#### Storage configuration - _**Disable** the following option_ : `Setup this disk as an LVM group` -### Identity +#### Identity - **Your name** : `icub` - **Your Server's name** : `icub-head' - **Pick a username** : `icub` - **Choose a password** : `icub` -### SSH +#### SSH - _**Enable** the following option_ : `Install SSH server` - -# Required Packages +## Required Packages Install the following packages ``` nfs-common python-tk libopencv-dev ntpdate vim ssh cmake-curses-gui iperf libportaudio2 portaudio19-dev linux-sound-base alsa-base alsa-utils gdb meld bmon libi2c-dev expect libgfortran10-dev qml-module-qt-labs-folderlistmodel qml-module-qt-labs-settings ``` -## Low Latency kernel +### Low Latency kernel Install the following packages ``` linux-image-lowlatency linux-headers-lowlatency ``` -## Disable X server at startup +### Disable X server at startup The x server is started automatically at startup by GDM, so please disable GDM ``` sudo systemctl disable gdm ``` -## iCub repository and package +### iCub repository and package 1. Add the file ``` @@ -91,9 +92,9 @@ sudo systemctl disable gdm icub-common ``` -# Configuration steps +## Configuration steps -## SSH configuration +### SSH configuration 1. Configure passwordless ssh: see this [link](https://askubuntu.com/questions/46930/how-can-i-set-up-password-less-ssh-login) 2. Disable reverse DNS lookup in SSH server: add the following line to the file `/etc/ssh/sshd_config` @@ -101,26 +102,26 @@ sudo systemctl disable gdm UseDNS no ``` -## Network performances tweaks +### Network performances tweaks -1. Install the following packages : +1. Install the following packages ``` sudo apt install linux-image-lowlatency linux-headers-lowlatency ``` -2. Modify the real time priority of process, add the file `/etc/security/limits.d/icub.conf ` as follows +2. Modify the real-time priority of the process, add the file `/etc/security/limits.d/icub.conf ` as follows ``` icub soft rtprio 99 icub hard rtprio 99 ``` -3. Set the max OS receive buffer size for all types of connections, by adding the file `/etc/sysctl.d/20-net-rbuffer.conf` as follows +3. Set the max OS receive-buffer size for all types of connections, by adding the file `/etc/sysctl.d/20-net-rbuffer.conf` as follows ``` - # This sets the max OS receive buffer size for all types of connections + # This sets the max OS receive-buffer size for all types of connections net.core.rmem_max=8388608 ``` -## NTP +### NTP Edit the file `/etc/default/ntpdate` by changing the following lines ``` @@ -129,9 +130,9 @@ NTPDATE_USE_NTP_CONF="no" NTPSERVERS="10.0.0.1 ntp.ubuntu.com" ``` -## IMU Bosch +### IMU Bosch -### Installation +#### Installation To use the IMU Bosch BNO055 through the i2c bus these additional steps are required: @@ -146,7 +147,7 @@ To use the IMU Bosch BNO055 through the i2c bus these additional steps are requi make sudo make install ``` - {ver} is the linux version (see uname -r). Ignore ssl errors during installation. + {ver} is the Linux version (see uname -r). Ignore ssl errors during installation. 4. Load the required kernel module(the best should be add them at the startup): ``` @@ -159,67 +160,64 @@ To use the IMU Bosch BNO055 through the i2c bus these additional steps are requi usermod -a -G i2c icub ``` -### Test the configuration of i2c and BNO055 +#### Test the configuration of i2c and BNO055 To test the installation with the [python script BNO055](https://github.com/icub-tech-iit/icub-os-files/blob/master/drivers/imu-bosch/BNO055.zip): ``` python BNO055.py ``` -Note that to make it work you might change script at line 195: +Note that to make it work you might change the script at line 195: ``` # Open I2C bus self._bus = smbus.SMBus(1) ``` -specifing the right number instead of 1 the correct number that can be found throught: +specifying the right number: instead of 1, specify the correct number that can be found through: ``` i2cdetect -l ``` -Another possible troubleshooting could be change in the script BNO055.py (line 187) the default address from 0x28 to 0x29 +Another possible troubleshooting could be to change in the script BNO055.py (line 187) the default address from 0x28 to 0x29 -## fixed USB resources names +### Fixed USB resource names In order to get a fixed device name for some USB resources such as IMU and USB2SERIAL, you have to create the following UDEV rules -- IMU BOSCH : adde the file `/etc/udev/rules.d/88-bosch-i2c-imu.rules` as follows +- IMU BOSCH: add the file `/etc/udev/rules.d/88-bosch-i2c-imu.rules` as follows ``` # iCub Bosch i2c IMU SUBSYSTEM=="i2c-dev", ATTRS{name}=="i2c-kempld", SYMLINK+="bosch-i2c-imu", MODE="0660", GROUP="i2c" ``` -- USB to Serial interface : add the file `/etc/udev/rules.d/99-usb-serial.rules` as follows +- USB to Serial interface: add the file `/etc/udev/rules.d/99-usb-serial.rules` as follows ``` # tty Xsens SUBSYSTEM=="tty", ATTRS{idVendor}=="2639", SYMLINK+="ttyXsens", MODE="0660", GROUP="tty" - ``` - -Further installation steps and configuration + ``` -# Tweaks +## Further installation steps and configuration -## Mount via SSH +### Mount via SSH -On the icub-head, graphics-based tools have not been installed (except the ones required for firmware interfaces) and it is better not to install them. Anyway, to use graphic tools (like editors, files managers, etc..) is very useful and sometimes essential. Instead of running remotely a tool and displaying it locally (like we did in old PC104), we can mount locally via SSH the icub-head filesystem and run locally all the tools we need. +On the icub-head, graphics-based tools have not been installed (except the ones required for firmware interfaces) and it is better not to install them. Anyway, using graphic tools (like editors, file managers, etc..) is very useful and sometimes essential. Instead of running remotely a tool and displaying it locally (like we did in old PC104), we can mount locally the icub-head filesystem via SSH and run locally all the tools we need. In order to mount locally the icub-head filesystem on your client: 1. install the sshfs package ``` sudo apt-get install sshfs ``` - 2. create a mount point for the remote filesystem (eg.) `mkdir /home/icub/icub-head_fs` 3. mount the remote `/usr/local/src/robot` via SSH ``` sudo sshfs -o allow_other icub@10.0.0.2:/usr/local/src/robot/ /home/icub/icub-head_fs ``` -If you already setup the passwordless SSH login, you can skip the password: +If you already set the passwordless SSH login, you can skip the password: ``` sudo sshfs -o allow_other,IdentityFile=/home/icub/.ssh/id_rsa icub@10.0.0.2:/usr/local/src/robot/ /home/icub/icub-head_fs ``` -# Customize the system +## Customize the system -What now you need to do is to customize the installation with your hardware and enviroment (see the "_Required configuration_" paragraph in [_Networking_](networking.md), [_Bluetooth_](bluetooth.md), [_User Environment_](user-env.md) chapters as well as [_Further Tasks_ chapter](further-tasks.md) ) +What now you need to do is to customize the installation with your hardware and environment (see the "_Required configuration_" paragraph in [_Networking_](networking.md), [_Bluetooth_](bluetooth.md), [_User Environment_](user-env.md) chapters as well as [_Further Tasks_ chapter](further-tasks.md) ) diff --git a/docs/icub_operating_systems/other-machines/icub-server-from-scratch.md b/docs/icub_operating_systems/other-machines/icub-server-from-scratch.md index 9f5059a5e..5ae15d174 100644 --- a/docs/icub_operating_systems/other-machines/icub-server-from-scratch.md +++ b/docs/icub_operating_systems/other-machines/icub-server-from-scratch.md @@ -8,7 +8,7 @@ Latest version is based on Ubuntu Server 20.04.2 Please check that the BIOS configuration allows to boot from USB drive. ## Create the USB installer -The first step is download the [official Ubuntu 20.04 LTS Server install media](https://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso) from the [release page](https://releases.ubuntu.com/focal/) +The first step is to download the **official Ubuntu 20.04 LTS Server install media** from the [release page](https://releases.ubuntu.com/focal). Search for `ubuntu-20.04.x-live-server-amd64.iso`. Then please create the USB installer using an USB memory and a tool like [Balena Etcher](https://www.balena.io/etcher/). diff --git a/docs/icub_operating_systems/other-machines/icub-server-laptop.md b/docs/icub_operating_systems/other-machines/icub-server-laptop.md index 85548148a..469e30960 100644 --- a/docs/icub_operating_systems/other-machines/icub-server-laptop.md +++ b/docs/icub_operating_systems/other-machines/icub-server-laptop.md @@ -141,7 +141,7 @@ yarp conf ip socketport where `ip` is the IP address of the iCub Console Server and `socketport` is the port retained by the YARP server (usually, `10000`). -To find out more on the YARP CLI, refer to the [YARP official documentation](http://yarp.it/latest/yarp.html). +To find out more on the YARP CLI, refer to the [YARP official documentation](https://yarp.it/latest/). ## Install the ssh keys for password-less login on icub-head diff --git a/docs/icub_operating_systems/pc104/icub-live.md b/docs/icub_operating_systems/pc104/icub-live.md index 400e6ca27..018b323ac 100644 --- a/docs/icub_operating_systems/pc104/icub-live.md +++ b/docs/icub_operating_systems/pc104/icub-live.md @@ -14,7 +14,7 @@ The latest version is 7.10 based on [Debian 10 (Buster)](https://www.debian.org/ ## Versioning - 1.x This is an Etch'n'half based distribution, built on a Debian LIVE system. - 2.x This is a Debian Lenny based distribution, built on a Debian LIVE system. -- 3.x This is a Debian Squeeze based distribution, contains a kernel with [Real-Time patch](https://rt.wiki.kernel.org/index.php/Main_Page)). +- 3.x This is a Debian Squeeze based distribution, contains a kernel with [Real-Time patch](https://wiki.linuxfoundation.org/realtime/start). - 4.x This is a Debian Wheezy based distribution, this version contains an updated version of libportaudio. - 5.x This is a Debian Wheezy based distribution, built on a Debian LIVE system with overlay persistence, compiled for kernel rt-amd64 (x86 64 bit with real time PREEMPT_RT patches) - 6.x This is a Debian Jessie based distribution, built on a Debian LIVE system with overlay persistence, compiled for kernel rt-amd64 (x86 64 bit with real time PREEMPT_RT patches) diff --git a/docs/icub_operating_systems/pc104/the-icub-live-installation.md b/docs/icub_operating_systems/pc104/the-icub-live-installation.md index 55683bb5d..51c93a447 100644 --- a/docs/icub_operating_systems/pc104/the-icub-live-installation.md +++ b/docs/icub_operating_systems/pc104/the-icub-live-installation.md @@ -117,9 +117,7 @@ This must be done from each machine you want to connect to the PC104. *See also [this link](http://askubuntu.com/questions/9800/remote-host-identification-has-changed-warning-when-connecting-over-ssh)* ## I used the live USB first on a computer, then when I plugged it into the PC104 it does not work anymore - -Probably the PC104 booted correctly, but the network is not reachable (you can check it by [connecting a vga cable to the PC104](https://svn.robotology.eu/repos/iCubHardware-pub/trunk/mechanics/public/doc/howTo/Connect_VGA_to_PC104.pd) -inside iCub's head) +Probably the PC104 booted correctly, but the network is not reachable (you can check it by connecting a VGA cable to the PC104 inside iCub's head). Live systems write some info about the network card the first time they boot on a machine. This implies that if you boot the live on a desktop and then you plug it to a different machine the network may not work (since the network card is different). diff --git a/docs/icub_r1_icub3_calibration_types/icub_r1_calibration_types.md b/docs/icub_r1_icub3_calibration_types/icub_r1_calibration_types.md index 8372d8e4c..663d8f44d 100644 --- a/docs/icub_r1_icub3_calibration_types/icub_r1_calibration_types.md +++ b/docs/icub_r1_icub3_calibration_types/icub_r1_calibration_types.md @@ -17,7 +17,7 @@ For this reason, if the calibration needs a particular value of `calibrationZero ## General procedure for retrieving calibration parameters 1. First off, you need to make sure that the boards have been reset after last calibration. If not, please swich off and swich on the boards. -2. In the [general.xml](https://github.com/robotology/robots-configuration/blob/master/CER01/general.xml) file set both `useRawEncoderValue` and `skipCalibration` parameters to `true` +2. In the [general.xml](https://github.com/robotology/robots-configuration/blob/master/R1SN003/general.xml) file set both `useRawEncoderValue` and `skipCalibration` parameters to `true` 3. Press the fault button, so that you are sure that the procedure runs safely. @@ -32,7 +32,7 @@ For this reason, if the calibration needs a particular value of `calibrationZero ## The available calibrations in details --- -Here are described the usage of the various calibration types; the `param` are in the [calibrators files](https://github.com/robotology/robots-configuration/tree/master/iCubHongKong01/calibrators) where you'll find a file for each part of the robot and looks like : +Here are described the usage of the various calibration types; the `param` are in the [calibrators files](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators) where you'll find a file for each part of the robot and looks like : ```xml @@ -68,7 +68,7 @@ This calibration is used on joints with incremental encoder that needs to reach |`calibrationDelta`| defined by user expressed in degree| !!!note - **The hardstop could be out of range of user limits, but it needs to be inside hardware limits; so the hardstop could be a hardware limit and the joint is calibrated after reaching it, but the controller verifies that the first received setpoint is inside user limits, else limits it to the nearest user limit.** + The hardstop could be out of range of user limits, but it needs to be inside hardware limits; so the hardstop could be a hardware limit and the joint is calibrated after reaching it, but the controller verifies that the first received setpoint is inside user limits, else limits it to the nearest user limit. ### Calibration 6 This calibration can be used for joint with `MAIS` and `FAP` board encoders. On iCub robots, distal and proximal joints use `MAIS`, while `FAP` are employed on ergoCub fingers. @@ -136,7 +136,7 @@ If for some reason it insn't enough, the calibration fails. ### Calibration 10 -This calibration is used for joints with relative encoders, which are calibrated by moving against the hard-stop limit. It is used for example in R1 lower arm pronosupination and in iCub 3 lower body when AMO sensors are used as relative encoders. +This calibration is used for joints with relative encoders, which are calibrated by moving against the hard-stop limit. It is used for example in R1 lower arm pronosupination and in iCub 3 when AMO sensors are used as relative encoders. Regarding iCub 3 and the AMO boards, the AMO magnetic target is subdivided into 64 or 32 sectors. The AMO sensor provides a 14-bit resolution per sector, for a total of 14+6=20 or 14+5=19 bits per revolution resolution, respectively. The `Gearbox_E2J` parameter must be configured with the number of sectors in the corresponding `mechanicals/part-mec.xml` file. @@ -151,6 +151,9 @@ Regarding iCub 3 and the AMO boards, the AMO magnetic target is subdivided into |`calibrationZero`| position (in degrees) at the hard-stop limit| |`calibrationDelta`| defined by user expressed in degree| +!!!note + On AMO-based robots (e.g., iCub 3, ergoCub), the AMO sensors can be completely disabled to favor the use of the quadrature encoders only by changing the value of the `amo` parameter to `none` within the `hardware/motorControl/*service.html` files. + ### Calibration 12 This calibration is used for joint with absolute encoder, it is the newest version of calibration 3 and it simplifies the calibration procedure for the user; in fact the user needs only to write in calibration1 parameter the raw value read when jont is in 0.0 position and the firmware calculates the correct offset. @@ -191,7 +194,7 @@ After that, by observing how the values printed out by the port change, you woul |`calibrationDelta`| defined by user expressed in degree | !!!note - **The `calibration14` rotation parameter cannot assume any value. Allowed values are: `0`, `32768`, `16384`, `-16384`, expressed in `iCubDegrees` as specified in the table above. Specifically, these values correspond to the following numbers in degrees: `0`, `180`, `90`, `-90`. Notice how these values are only accepted without decimals; therefore, only integer parts are checked. In fact, multiplying the degrees by the conversion factor, defined in the [Legend](#legend) section, generates outputs with decimals. Thus, it has been decided to round them up.** + The `calibration14` rotation parameter cannot assume any value. Allowed values are: `0`, `32768`, `16384`, `-16384`, expressed in `iCubDegrees` as specified in the table above. Specifically, these values correspond to the following numbers in degrees: `0`, `180`, `90`, `-90`. Notice how these values are only accepted without decimals; therefore, only integer parts are checked. In fact, multiplying the degrees by the conversion factor, defined in the [Legend](#legend) section, generates outputs with decimals. Thus, it has been decided to round them up. !!!info Considering that this calibration works in close relation with absolute encoders, it is necessary to keep in mind the following note. @@ -205,7 +208,7 @@ After that, by observing how the values printed out by the port change, you woul - `iCubDegree`: the firmware uses iCubDegree instead of degree in order to use more resolution. !!!info - 1 Degree = 182.044 iCubDegree, where 182.044 is 65535/360; The value 182.044 is contained in the parameter “Encoder” of mechanicals configuration files of each robot. + 1 Degree = 182.044 iCubDegree, where 182.044 is 65535/360; The value 182.044 is contained in the parameter “Encoder” of mechanical configuration files of each robot. - `Encoder conversion` factor: is the factor used by firmware to convert the value read from encoder to iCubDegree. diff --git a/docs/icub_robot_calibration/icub-robot-calibration-v2.x.md b/docs/icub_robot_calibration/icub-robot-calibration-v2.x.md index 0e02b41a2..c5c537197 100644 --- a/docs/icub_robot_calibration/icub-robot-calibration-v2.x.md +++ b/docs/icub_robot_calibration/icub-robot-calibration-v2.x.md @@ -19,8 +19,6 @@ This page shows how to calibrate the robot. `icub@icubsrv:~$ ssh -X icub-head` - - ## Run yarprobotinterface in calibration mode First turn on the motors. Go to the robot folder: @@ -169,7 +167,7 @@ Run `yarprobotinterface` and wait for the robot calibration (press Enter multipl After running yarprobotinterface you will see some errors messages related to the fault button pressed. ## Calibration -For the calibration of every part of the robot, there is a specific `.xml` file located in the `calibrators` folder (see [here for an example](https://github.com/robotology/robots-configuration/tree/master/iCubHongKong01/calibrators)). +For the calibration of every part of the robot, there is a specific `.xml` file located in the `calibrators` folder (see [here for an example](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators)). ### Calibration types There are different types of joints calibration, specified in the calibrationType parameter: @@ -232,7 +230,7 @@ There are different types of joints calibration, specified in the calibrationTyp ![yarpmoorgui](./img/yarpmotorgui.png) ### Head calibration (only V2) -Open the [calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/head-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3` in the `` inside the ``. +Open the [calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/head-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3` in the `` inside the ``. !!!info The joints params in the `xml` files are organized as: @@ -260,7 +258,7 @@ Open the [calibrator file](https://github.com/robotology/robots-configuration/bl Take care that the ` ` has all values seto to 0. ### Torso -Open the [calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/torso-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2` in the `` inside the ``. +Open the [calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/torso-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2` in the `` inside the ``. !!!info The joints params in the `xml` files are organized as: @@ -288,7 +286,7 @@ Open the [calibrator file](https://github.com/robotology/robots-configuration/bl Take care that the ` ` param has all values seto to 0. ## Arms calibration -Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3` in the `` inside the ``. +Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3` in the `` inside the ``. !!!info The joints params in the `xml` files are organized as: @@ -322,7 +320,7 @@ Place the wrist in the `zero position` : |---|---| |![img-3](./img/img-3.png) | ![img-4](./img/img-4.png)| -Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values read from `yarpmotorgui` for the `joints 5,6` in the `` inside the ``. +Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values read from `yarpmotorgui` for the `joints 5,6` in the `` inside the ``. !!!info The joints params in the `xml` files are organized as: @@ -369,7 +367,7 @@ Referring to the table below, using a screwdriver read the values `Min` and `Max Take care that values read respect the relationship :`Min` < `Max`s Otherwise you have to move the magnet until you reach the above situation. -Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values `Min` and `Max` read from `yarpmotorgui` respectively in the `` and `` inside the `` for each joint in the table above. +Open the [letf arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/left_arm-calib.xml) or [right arm calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/right_arm-calib.xml), and put the values `Min` and `Max` read from `yarpmotorgui` respectively in the `` and `` inside the `` for each joint in the table above. !!!info The joints params in the `xml` files are organized as: @@ -397,7 +395,7 @@ Open the [letf arm calibrator file](https://github.com/robotology/robots-configu Take care that the ` ` param has all values seto to 0. ## Legs calibration -Open the [letf leg calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/left_leg-calib.xml) or [right leg calibrator file](https://github.com/robotology/robots-configuration/blob/master/iCubHongKong01/calibrators/right_leg-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3,4,5` in the `` inside the ``. +Open the [letf leg calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/left_leg-calib.xml) or [right leg calibrator file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubHongKong01/calibrators/right_leg-calib.xml), and put the values read from `yarpmotorgui` for the `joints 0,1,2,3,4,5` in the `` inside the ``. !!!info The joints params in the `xml` files are organized as: diff --git a/docs/icub_robot_calibration/icub3-stator-rotor-autocalibration.md b/docs/icub_robot_calibration/icub3-stator-rotor-autocalibration.md index 9a83952ca..3f8cf84a1 100644 --- a/docs/icub_robot_calibration/icub3-stator-rotor-autocalibration.md +++ b/docs/icub_robot_calibration/icub3-stator-rotor-autocalibration.md @@ -4,7 +4,7 @@ This page shows how to run the autocalibration procedure of the rotor/stator ali ## Prepare the `XML` files In order to get the values to put in the `XML` files, we need to modify the file enabling the autocalibration. -The files are located in [`robots-configuration/iCubGenova09/hardware/mechanicals`](https://github.com/robotology/robots-configuration/tree/master/iCubGenova09/hardware/mechanicals). +The files are located in [`robots-configuration/robots-icebox/iCubGenova09/hardware/mechanicals`](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubGenova09/hardware/mechanicals). Accordingly to the joint you have to calibrate, select the corresponding file and set `AutoCalibration` param to 1 and `RotorIndexOffset` to 0: @@ -27,7 +27,7 @@ In order to get the value to be written in the `XML` file above, `yarprobotinter !!!info In order to get less messages from the `yarprobotinterface` log, better off enabling the calibration only for the joint that needs to be calibrated. - To do that in the corresponding [calibration file](https://github.com/robotology/robots-configuration/tree/master/iCubGenova09/calibrators), edit the `CALIB_ORDER` param to contain only the number of the joint you need: + To do that in the corresponding [calibration file](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubGenova09/calibrators), edit the `CALIB_ORDER` param to contain only the number of the joint you need: ```xml (0) (1) (2) (3) (4) (5) ``` @@ -56,9 +56,9 @@ Looking at par64, the rightmost 4 digits are the offset: `0x0079` = `121` degree ## Put the values in the `XML` files -Once the value of the autocalibration is retrieved, just put it in the corresponding [`XML`](https://github.com/robotology/robots-configuration/tree/master/iCubGenova09/hardware/mechanicals) file. +Once the value of the autocalibration is retrieved, just put it in the corresponding [`XML`](https://github.com/robotology/robots-configuration/tree/master/robots-icebox/iCubGenova09/hardware/mechanicals) file. -For the value retrieved above we need to modify the `joint 0` column of [file](https://github.com/davidetome/robots-configuration/blob/master/iCubGenova09/hardware/mechanicals/right_leg-eb10-j0_1-mec.xml) and set `AutoCalibration` back to `0`: +For the value retrieved above we need to modify the `joint 0` column of [file](https://github.com/robotology/robots-configuration/blob/master/robots-icebox/iCubGenova09/hardware/mechanicals/right_leg-eb11-j0_2-mec.xml) and set `AutoCalibration` back to `0`: The column order in the file follows the joint order in the file-name; in the case of `right_leg-eb10-j0_1-mec.xml`, the first column is for `joint 0` and the second one is for `joint 1`. diff --git a/docs/icub_robot_configuration/icub_robot_configuration_index.md b/docs/icub_robot_configuration/icub_robot_configuration_index.md index 1f71aa574..80b959a1f 100644 --- a/docs/icub_robot_configuration/icub_robot_configuration_index.md +++ b/docs/icub_robot_configuration/icub_robot_configuration_index.md @@ -4,14 +4,12 @@ The aim of this page is to explain the configuration of a Ethernet based robot a ## Introduction [Yarprobotinterface](https://www.yarp.it/latest/group__yarprobotinterface.html) application starts all devices and modules required by a robot to work properly. Any device needs a configuration data set that could differs from robot to robot, so each robot has own configuration, saved in xml files contained in a folder called with robot's name in the repository [robots-configuration](https://github.com/robotology/robots-configuration). -Each robot has a main configuration file, usually named `icub_all.xml`, that contains the list of all devices and other modules, like Calibrators and Cartesian, that [Yarprobotinterface](https://www.yarp.it/latest/group__yarprobotinterface.html) starts. - +Each robot has a main configuration file, usually named `icub_all.xml`, that contains the list of all devices and other modules, like Calibrators and Cartesian, that [Yarprobotinterface](https://yarp.it/latest/group__yarprobotinterface.html) starts. ## Contents [**Structure of robot configuration data set**](./structure_robot_configuration_data_set/structure_robot_configuration_data_set.md) - [**Naming convention**](./naming_convention/naming_convention.md) - [Rules for naming devices](./naming_convention/naming_convention.md#1-rules-for-naming-devices) @@ -20,8 +18,6 @@ Each robot has a main configuration file, usually named `icub_all.xml`, that con - [Rules for naming joints](./naming_convention/naming_convention.md#3rules-for-naming-joints) - - [**Configuration of devices**](./devices_configuration/devices_configuration.md) - [Motor control device](./devices_configuration/devices_configuration.md#motor-control-device) @@ -36,17 +32,10 @@ Each robot has a main configuration file, usually named `icub_all.xml`, that con - [Inertial device](./devices_configuration/devices_configuration.md#inertial-device) - [**Configuration of calibrator module**](./calibrator_configuration/calibrator_configuration.md) - - - ## Note for robots hosted at the iCub Tech Facility Robots hosted at the iCub Tech Facility often run developing software, that is, they use the same software modules, but on the development branch instead of stable (master). This means that in the newest version new parameters may be available or there might be some changes that are not described in the latest stable version. You can find these differences in the changelog. If you are interested in the rationale underlying these changes, please check the files `[iCubTemplates](https://github.com/robotology/robots-configuration/tree/devel/iCubTemplates)/iCubTemplateVX_0`, where `X` identifies the latest version in the devel branch. - - - diff --git a/docs/icub_ros/index.md b/docs/icub_ros/index.md index a9f646638..038b1591a 100644 --- a/docs/icub_ros/index.md +++ b/docs/icub_ros/index.md @@ -21,7 +21,7 @@ To keep track of the various sets of coordinates, ROS TF requires 2 things: ### Modules description The piece of software that can be used to publish the joint position information exposed by a YARP device for YARP <= 3.4 (so for any robotology distro <= 2021.08) is the `controlboardwrapper2` (see [this page](http://www.yarp.it/v3.4/classControlBoardWrapper.html#details)). This is exactly the same device used to publish joint information on YARP ports, but that can be configured also to publish on ROS topics via the ROS group. -However, notice that `controlboardwrapper2` device is deprecated in the new YARP 3.5 relese (that will be use in robotology distros from >= 2021.11), and its functionality is going to be replaced by middleware-specific devices. In particular [`controlBoard_nws_yarp`](http://www.yarp.it/v3.5/classControlBoard__nws__yarp.html) for YARP, [`controlBoard_nws_ros`](http://www.yarp.it/v3.5/classControlBoard__nws__ros.html) for ROS(1) and [`controlBoard_nws_ros2`](https://github.com/robotology-playground/yarp-ros2/tree/master/src/devices/controlBoard_nws_ros2) for ROS2 (still unreleased work in progress). See [this page](http://www.yarp.it/latest/nws_and_nwc_architecture.html) and [this issue](https://github.com/robotology/yarp/discussions/2441) for architecture details on the changes in YARP 3.5 . +However, notice that `controlboardwrapper2` device is deprecated in the new YARP 3.5 relese (that will be use in robotology distros from >= 2021.11), and its functionality is going to be replaced by middleware-specific devices. In particular [`controlBoard_nws_yarp`](http://www.yarp.it/v3.5/classControlBoard__nws__yarp.html) for YARP, [`controlBoard_nws_ros`](http://www.yarp.it/v3.5/classControlBoard__nws__ros.html) for ROS(1) and [`controlBoard_nws_ros2`](https://github.com/robotology-playground/yarp-ros2/tree/master/src/devices/controlBoard_nws_ros2) for ROS2 (still unreleased work in progress). See [this page](https://yarp.it/latest/group__nws__and__nwc__architecture.html) and [this issue](https://github.com/robotology/yarp/discussions/2441) for architecture details on the changes in YARP 3.5 . ### Using `controlboardwrapper2` The module can be activated using an `xml` file such as [`icub_ros_wrapper.xml`](https://github.com/robotology/robots-configuration/blob/v1.21.0/iCubLondon01/wrappers/motorControl/icub_ros_wrapper.xml). In general all the `xml` configuration files related to YARP devices are only meant to be used by applications that use the `libYARP_robotinterface` YARP library, i.e. either the `yarprobotinteface` tool (unfortunaly docs are missing for this tool, see [this issue](https://github.com/robotology/yarp/issues/870)) or the `gazebo_yarp_robotinterface` Gazebo plugin. diff --git a/docs/icub_setup_multiple_robots/two_robots_real.md b/docs/icub_setup_multiple_robots/two_robots_real.md index ebea055bf..f272e36a5 100644 --- a/docs/icub_setup_multiple_robots/two_robots_real.md +++ b/docs/icub_setup_multiple_robots/two_robots_real.md @@ -15,28 +15,26 @@ The robots network configuration is set using [netplan](https://netplan.io/examp Now, change the ip address `10.0.0.2` to some other ip address such as `10.0.0.200`. Once the ip address is change do `sudo netplan apply` to load the new network configuration file. At this point you will not be able access icub-head any longer and you need to to `ssh 10.0.0.200` to reach the head of the robot. -**NOTE 1:** Ensure to switch the ip address back to the original default ip value of `10.0.0.2` and do `sudo netplan apply` once the experiments with the robot are finished. +!!! note -**NOTE 2:** Previously the network was configured without using netplan. You can can find the instructions in the [history of this wiki page](https://github.com/dic-iit/lab-organisation/wiki/How-to-use-two-real-iCub-robots-on-the-same-network/dfcdedcdb8bf7ae414d1e479ba4238306985fd3a). + Ensure to switch the ip address back to the original default ip value of `10.0.0.2` and do `sudo netplan apply` once the experiments with the robot are finished. ## Robot configurations side To launch an icub robot multiple [configuration files](https://github.com/robotology/robots-configuration) are launched through `yarprobotinterface`. In general, these files are robot specific (Eg. [iCubGenova02](https://github.com/robotology/robots-configuration/tree/master/iCubGenova02)) and contains parameters tuned for -that particular robot. But the port names used in all these configuration files are usually the same. So, while trying to launch multiple robots on the same network, port address conflict happens. This issue can be solved by using different port prefix names in the configuration files, e.g. changing from `icub` to more robot specific like `icub02` for `iCubGenova02` and `icub04` for `iCubGenova04`. An example can be found in [dic-iit/robots-configuration/icub02-prefix](https://github.com/dic-iit/robots-configuration/tree/icub02-prefix) were the `iCubGenova02` configuration files have been updated in order to run `icub_wbd.xml` application with all the port prefixes changed to `icub02`. +that particular robot. But the port names used in all these configuration files are usually the same. So, while trying to launch multiple robots on the same network, port address conflict happens. This issue can be solved by using different port prefix names in the configuration files, e.g. changing from `icub` to more robot specific like `icub02` for `iCubGenova02` and `icub04` for `iCubGenova04`. An example can be found in [ami-iit/robots-configuration/icub02-prefix](https://github.com/ami-iit/robots-configuration/tree/icub02-prefix) were the `iCubGenova02` configuration files have been updated in order to run `icub_wbd.xml` application with all the port prefixes changed to `icub02`. In particular, the following files have to be changed: -- Update robot `yarprobotinterface` port prefix (e.g. https://github.com/dic-iit/robots-configuration/commit/91b2ee0865ac61ec429d577c6fdf3de289ec2b26) -- Update nterfaces wrapper port prefix (e.g. https://github.com/dic-iit/robots-configuration/commit/47d6a1beb0b5596749d975dd681e57dadaf6acee) -- Add port prefix to whole-Body-Dynamics (e.g. https://github.com/dic-iit/robots-configuration/commit/08081819b46621c364a488695bcff8b986202a87), by adding the following line: +- Update robot `yarprobotinterface` port prefix. +- Update interfaces wrapper port prefix. +- Add port prefix to Whole-Body-Dynamics by adding the following line: ```xml //wholebodydynamics ``` - and adding the prefix to [external wrench port names](https://github.com/robotology/robots-configuration/blob/404230b69663aadf4be7c526b0f93324826ba729/iCubGenova02/estimators/wholebodydynamics.xml#L38) - e.g. + and adding the prefix to **external wrench port names**, e.g.: ```xml (l_foot,l_sole,root_link) ``` -- Update cartesian controllers port prefix (e.g. https://github.com/dic-iit/robots-configuration/commit/fe05701db580aebe81df89d48574ad9f04f8e51a) - +- Update cartesian controllers port prefix. As a simple test, you can launch `yarpmotorgui --robot ` to try to control the robot, and check all the opened ports with `yarp name list`. diff --git a/docs/icub_setup_multiple_robots/two_robots_simulation.md b/docs/icub_setup_multiple_robots/two_robots_simulation.md index 251a0bdb3..c49ab4e76 100644 --- a/docs/icub_setup_multiple_robots/two_robots_simulation.md +++ b/docs/icub_setup_multiple_robots/two_robots_simulation.md @@ -1,12 +1,12 @@ ## How to use two iCub robots in gazebo simulation -In order to use icub robot in gazebo simulation environment one needs to have the repository [icub-gazebo](https://github.com/robotology/icub-gazebo) and have to set GAZEBO_MODEL_PATH to this repository as indicated in the [readme](https://github.com/robotology/icub-gazebo) file. Furthermore, [icub-gazebo-wholebody](https://github.com/robotology/icub-gazebo-wholebody) repository contains complex `gazebo models` and `gazebo worlds`, for example [icub-standup-world](https://github.com/robotology/icub-gazebo-wholebody/blob/master/worlds/icub_standup_world/icub_standup_world). In general, these two repositories can be used as standalone or they can be used as a part of [robotology-superbuild](https://github.com/robotology/robotology-superbuild). +In order to use icub robot in gazebo simulation environment one needs to have the repository [icub-gazebo](https://github.com/robotology/icub-gazebo) and have to set GAZEBO_MODEL_PATH to this repository as indicated in the [readme](https://github.com/robotology/icub-gazebo) file. Furthermore, [icub-gazebo-wholebody](https://github.com/robotology/icub-gazebo-wholebody) repository contains complex `gazebo models` and `gazebo worlds`, for example [icub-standup-world](https://github.com/robotology/icub-gazebo-wholebody/blob/master/worlds/icub_standup_world/README.md). In general, these two repositories can be used as standalone or they can be used as a part of [robotology-superbuild](https://github.com/robotology/robotology-superbuild). When an iCub model is spawned in gazebo, all the ports that are opened take the name placed in the [gazebo_icub_robotname.ini](https://github.com/robotology/icub-gazebo/blob/master/icub/conf/gazebo_icub_robotname.ini) configuration file as a port prefix. The default name used is `icubSim`: `gazeboYarpPluginsRobotName icubSim` -The **model name** displayed in gazebo is taken `iCub` from the [icub.sdf](https://github.com/robotology/icub-gazebo/blob/ab22fdc34c0a9faa6f72428c2abdb6afc3145872/icub/icub.sdf#L3) file and the gazebo-yarp-plugin motor control board ports and ports of the other gazebo-yarp-plugins you placed in your iCub model are opened with the portprefix `/icubSim`. +The **model name** displayed in gazebo is taken `iCub` from the [icub.sdf](https://github.com/robotology/icub-gazebo/blob/master/icub/icub.sdf#L3) file and the gazebo-yarp-plugin motor control board ports and ports of the other gazebo-yarp-plugins you placed in your iCub model are opened with the portprefix `/icubSim`. diff --git a/docs/icub_sw.md b/docs/icub_sw.md index 5273fa7c2..35a8c4c98 100644 --- a/docs/icub_sw.md +++ b/docs/icub_sw.md @@ -3,7 +3,7 @@ - [`Software Installation`](./sw_installation/index.md) - [`Software Versioning Table`](./sw_versioning_table/index.md) - [`The OS for the iCub environment`](./icub_operating_systems/index.md) -- [`The YARP Documentation`](https://yarp.it/latest) +- [`The YARP Documentation`](https://yarp.it/latest/) - [`The iCub Software Documentation`](https://robotology.github.io/robotology-documentation/doc/html/index.html) - [`How to set up multiple iCubs on the same network`](./icub_setup_multiple_robots/index.md) - [`iCub Firmware`](./icub_firmware/index.md) @@ -14,4 +14,7 @@ - [`Calibration Types`](./icub_r1_icub3_calibration_types/icub_r1_calibration_types.md) - [`iCub and R1 Calibration Types`](./icub_r1_icub3_calibration_types/icub_r1_calibration_types.md) - [`Configure IP on a setup for ETH boards`](./configure_static_ip/configure-static-ip.md) +- [`Using iCub with ROS`](./icub_ros/index.md) - [`iCub Force Control`](./icub_force_control/icub-force-control.md) +- [`Sensor Interfaces`](./robot_sensors/index.md) +- [`Tactile Sensors`](./tactile_sensors/index.md) diff --git a/docs/robot_power/assets/display-fault-screen-131.png b/docs/robot_power/assets/display-fault-screen-131.png new file mode 100644 index 000000000..583d71405 Binary files /dev/null and b/docs/robot_power/assets/display-fault-screen-131.png differ diff --git a/docs/robot_power/assets/display-screen-131.png b/docs/robot_power/assets/display-screen-131.png new file mode 100644 index 000000000..e98e2cbdd Binary files /dev/null and b/docs/robot_power/assets/display-screen-131.png differ diff --git a/docs/robot_power/robot_power_button.md b/docs/robot_power/robot_power_button.md index 0f2dc6dc1..4a7131beb 100644 --- a/docs/robot_power/robot_power_button.md +++ b/docs/robot_power/robot_power_button.md @@ -21,3 +21,17 @@ On iCub3 and on R1 there is also a display that shows the voltage and current pr |:---:|:---:| | | | + +## Display Interface + +Lately, we released a new version of the Display UX/UI. +The main screen is described in the image below for both iCub3, ergoCub, and R1: + + + + +If a fault occurs, the Display will switch to a different mode displaying a string that includes the error type and the last values of voltage and currents acquired at the moment of the fault. + +An example is shown below. On the left, the errors are related to CPU line, whereas on the right, we have errors related to BOARDS/MOTORS line. + + diff --git a/docs/robot_sensors/ergocub_sensors.md b/docs/robot_sensors/ergocub_sensors.md index 694eefe94..300945013 100644 --- a/docs/robot_sensors/ergocub_sensors.md +++ b/docs/robot_sensors/ergocub_sensors.md @@ -11,7 +11,7 @@ This page lists all the sensors mounted on ergoCub, and how to access their info |**IMU** | `head/imu` | RFE, BNO055 | `/ergocub/head/imu/measures:o` | Defined in [multipleAnalogSensorsSerializations.thrift](https://github.com/robotology/yarp/blob/master/src/devices/multipleAnalogSensorsMsgs/multipleAnalogSensorsSerializations.thrift?rgh-link-date=2023-05-10T12%3A50%3A28Z) | 100 | |**Depth Camera** | `depthCamera` | Intel Realsense D450 | `/ergocub/depthCamera/rgbImage:o` | ( (R channel) (G channel) (B channel) ) | 30 | | - | - | - | `/ergocub/depthCamera/depthImage:o` | (depth_pixels_list) | 30 | -|**Lidar** | `laser` | Slamtec RP Lidar S2 | `/ergocub/laser:o` | Defined in [LaserScan2D.thrift](https://github.com/robotology/yarp/blob/2d3aacc1493b9f1813afecbc1a272f21f358915d/src/libYARP_dev/src/idl/LaserScan2D.thrift#L15-L34) | 100 | +|**Lidar** | `laser` | Slamtec RP Lidar S2 | `/ergocub/laser:o` | Defined in [LaserScan2D.thrift](https://github.com/robotology/yarp/blob/master/src/libYARP_dev/src/idl/LaserScan2D.thrift#L15-L34) | 100 | ## Torso diff --git a/docs/robot_sensors/yarp_nws_convention.md b/docs/robot_sensors/yarp_nws_convention.md index a1ac44cb1..3f5db8c06 100644 --- a/docs/robot_sensors/yarp_nws_convention.md +++ b/docs/robot_sensors/yarp_nws_convention.md @@ -26,7 +26,7 @@ Next, we will list the port convention for each type of functionality. For each ## Controlboards -The `ControlBoard` functionality is exposed via the [`controlBoard_nws_yarp`](https://www.yarp.it/latest/classControlBoard__nws__yarp.html) device. It can be used to get and set input-output quantities associated to the part's joints, by communicating with the ETH boards of the robot. +The `ControlBoard` functionality is exposed via the [`controlBoard_nws_yarp`](https://yarp.it/latest/classControlBoard__nws__yarp.html) device. It can be used to get and set input-output quantities associated to the part's joints, by communicating with the ETH boards of the robot. For each part, there will be a `controlBoard_nws_yarp` device that will open the following YARP ports: @@ -57,15 +57,15 @@ For each part, there will be a `multipleanalogsensorsserver` device that will op !!! warning These YARP ports are not meant to be accessed directly, but should be accessed instead via the [`multipleanalogsensorsclient`](https://www.yarp.it/git-master/classMultipleAnalogSensorsClient.html) device. -The client device will expose sensors related to the following [Multiple Analog Sensors Interfaces](https://www.yarp.it/latest/group__dev__iface__multiple__analog.html), so they can be easily queried: +The client device will expose sensors related to the following [Multiple Analog Sensors Interfaces](https://yarp.it/latest/group__dev__iface__multiple__analog.html), so they can be easily queried: - [`yarp::dev::IOrientationSensors`](https://www.yarp.it/latest/classyarp_1_1dev_1_1IOrientationSensors.html) -- [`yarp::dev::IThreeAxisGyroscopes`](https://www.yarp.it/git-master/classyarp_1_1dev_1_1IThreeAxisGyroscopes.html) +- [`yarp::dev::IThreeAxisGyroscopes`](https://yarp.it/latest/classyarp_1_1dev_1_1IThreeAxisGyroscopes.html) -- [`yarp::dev::IThreeAxisLinearAccelerometers`](https://www.yarp.it/git-master/classyarp_1_1dev_1_1IThreeAxisLinearAccelerometers.html) +- [`yarp::dev::IThreeAxisLinearAccelerometers`](https://yarp.it/latest/classyarp_1_1dev_1_1IThreeAxisLinearAccelerometers.html) -- [`yarp::dev::IThreeAxisMagnetometers`](https://www.yarp.it/git-master/classyarp_1_1dev_1_1IThreeAxisMagnetometers.html) +- [`yarp::dev::IThreeAxisMagnetometers`](https://yarp.it/latest/classyarp_1_1dev_1_1IThreeAxisMagnetometers.html) ## Force-Torque Sensors @@ -104,13 +104,13 @@ For each eye, there will be a `frameGrabber_nws_yarp` that will open the followi !!! warning - These YARP ports are not meant to be accessed directly, but should be accessed instead via the [`remote_framegrabber`](https://www.yarp.it/latest/classRemoteFrameGrabber.html) device. + These YARP ports are not meant to be accessed directly, but should be accessed instead via the `remote_framegrabber` device. The client device will expose the sensors thanks to the related [Media Interfaces](https://www.yarp.it/latest/group__dev__iface__media.html). ### Depth cameras -Depth cameras, such as the Intel Realsense series of devices, have their capabilities exposed by the [`RgbdSensor_nws_yarp`](https://www.yarp.it/latest/classRgbdSensor__nws__yarp.html) device. The port names do not follow the convention mentioned above, but use the naming `//`. `` is a string that is set as `depthCamera` if only one RGBD device is mounted on the robot. +Depth cameras, such as the Intel Realsense series of devices, have their capabilities exposed by the [`RgbdSensor_nws_yarp`](https://yarp.it/latest/classRgbdSensor__nws__yarp.html) device. The port names do not follow the convention mentioned above, but use the naming `//`. `` is a string that is set as `depthCamera` if only one RGBD device is mounted on the robot. The `RgbdSensor_nws_yarp` device will open the following YARP ports: @@ -126,6 +126,6 @@ The `RgbdSensor_nws_yarp` device will open the following YARP ports: Even though client devices are not available, YARP provides interfaces to create a client application: -- [`yarp::dev::IRGBDSensor`](https://www.yarp.it/latest/classyarp_1_1dev_1_1IRGBDSensor.html) -- [`yarp::dev::IDepthVisualParams`](https://www.yarp.it/latest/classyarp_1_1dev_1_1IDepthVisualParams.html) -- [`yarp::dev::IRgbVisualParams`](https://www.yarp.it/latest/classyarp_1_1dev_1_1IRgbVisualParams.html) +- [`yarp::dev::IRGBDSensor`](https://yarp.it/latest/classyarp_1_1dev_1_1IRGBDSensor.html) +- [`yarp::dev::IDepthVisualParams`](https://yarp.it/latest/classyarp_1_1dev_1_1IDepthVisualParams.html) +- [`yarp::dev::IRgbVisualParams`](https://yarp.it/latest/classyarp_1_1dev_1_1IRgbVisualParams.html) diff --git a/docs/sw_installation/check_your_installation.md b/docs/sw_installation/check_your_installation.md index 6b7e0a831..607c745f3 100644 --- a/docs/sw_installation/check_your_installation.md +++ b/docs/sw_installation/check_your_installation.md @@ -18,7 +18,7 @@ Depending on the system the console will look something like this: ![](img/yarpserver.jpg) -If you type on a web browser http://127.0.0.1:10000 you get +If you type on a web browser `http://127.0.0.1:10000` you get information about the name server (registered ports, info, etc.). We can just check functionality by running a simple example. On another @@ -112,7 +112,7 @@ yarp connect /icubSim/cam/right/rgbImage:o /view/right ## Play a recorded sequence You can also use the dataSetPlayer to replay a recorded sequence. This will reproduce all the sensory information available on the real robot -during a simple experiment. Follow the instructions here http://www.yarp.it/group__yarpdataplayerExample.html. +during a simple experiment. Follow the instructions at https://yarp.it/latest/group__yarpdataplayer__example.html. ![](img/datasetplayer-example.jpg) diff --git a/docs/sw_versioning_table/2023.08.0.md b/docs/sw_versioning_table/2023.08.0.md new file mode 100644 index 000000000..6f61cbf64 --- /dev/null +++ b/docs/sw_versioning_table/2023.08.0.md @@ -0,0 +1,71 @@ +📦 Distro 2023.08.0 +=== + +| CMake Packages | Repositories | Versions | +| :--- | :--- | :--- | +| [**`YCM`**](https://github.com/robotology/ycm.git) | https://github.com/robotology/ycm.git | `v0.15.3` | +| [**`YARP`**](https://github.com/robotology/yarp.git) | https://github.com/robotology/yarp.git | `v3.8.1` | +| [**`ICUB`**](https://github.com/robotology/icub-main.git) | https://github.com/robotology/icub-main.git | `v2.3.0` | +| [**`robots-configuration`**](https://github.com/robotology/robots-configuration.git) | https://github.com/robotology/robots-configuration.git | `v2.5.0` | +| [**`icub-firmware`**](https://github.com/robotology/icub-firmware.git) | https://github.com/robotology/icub-firmware.git | `v1.36.0` | +| [**`icub-firmware-models`**](https://github.com/robotology/icub-firmware-models.git) | https://github.com/robotology/icub-firmware-models.git | `v1.36.0` | +| [**`icub_firmware_shared`**](https://github.com/robotology/icub-firmware-shared.git) | https://github.com/robotology/icub-firmware-shared.git | `v1.36.0` | +| [**`icub-firmware-build`**](https://github.com/robotology/icub-firmware-build.git) | https://github.com/robotology/icub-firmware-build.git | `v1.36.0` | +| [**`ICUBcontrib`**](https://github.com/robotology/icub-contrib-common.git) | https://github.com/robotology/icub-contrib-common.git | `v1.19.0` | +| [**`icub-basic-demos`**](https://github.com/robotology/icub-basic-demos.git) | https://github.com/robotology/icub-basic-demos.git | `v1.24.0` | +| [**`icub-tests`**](https://github.com/robotology/icub-tests.git) | https://github.com/robotology/icub-tests.git | `v1.25.0` | +| [**`GazeboYARPPlugins`**](https://github.com/robotology/gazebo-yarp-plugins.git) | https://github.com/robotology/gazebo-yarp-plugins.git | `v4.8.0` | +| [**`icub-models`**](https://github.com/robotology/icub-models.git) | https://github.com/robotology/icub-models.git | `v2.3.0` | +| [**`iDynTree`**](https://github.com/robotology/idyntree.git) | https://github.com/robotology/idyntree.git | `v9.1.0` | +| [**`qpOASES`**](https://github.com/robotology-dependencies/qpOASES.git) | https://github.com/robotology-dependencies/qpOASES.git | `v3.2.0.1` | +| [**`osqp`**](https://github.com/oxfordcontrol/osqp.git) | https://github.com/oxfordcontrol/osqp.git | `v0.6.3` | +| [**`manif`**](https://github.com/robotology-dependencies/manif.git) | https://github.com/robotology-dependencies/manif.git | `0.0.4.103` | +| [**`qhull`**](https://github.com/qhull/qhull.git) | https://github.com/qhull/qhull.git | `2020.2` | +| [**`CppAD`**](https://github.com/coin-or/CppAD.git) | https://github.com/coin-or/CppAD.git | `20230000.0` | +| [**`casadi`**](https://github.com/casadi/casadi.git) | https://github.com/casadi/casadi.git | `3.6.3` | +| [**`ergocub-software`**](https://github.com/icub-tech-iit/ergocub-software.git) | https://github.com/icub-tech-iit/ergocub-software.git | `v0.4.0` | +| [**`yarp-matlab-bindings`**](https://github.com/robotology/yarp-matlab-bindings.git) | https://github.com/robotology/yarp-matlab-bindings.git | `v3.8.0` | +| [**`RobotTestingFramework`**](https://github.com/robotology/robot-testing-framework.git) | https://github.com/robotology/robot-testing-framework.git | `v2.0.1` | +| [**`blocktestcore`**](https://github.com/robotology/blocktest.git) | https://github.com/robotology/blocktest.git | `v2.3.7` | +| [**`blocktest-yarp-plugins`**](https://github.com/robotology/blocktest-yarp-plugins.git) | https://github.com/robotology/blocktest-yarp-plugins.git | `v1.1.4` | +| [**`BlockFactory`**](https://github.com/robotology/blockfactory.git) | https://github.com/robotology/blockfactory.git | `v0.8.3` | +| [**`WBToolbox`**](https://github.com/robotology/wb-toolbox.git) | https://github.com/robotology/wb-toolbox.git | `v5.6.0` | +| [**`OsqpEigen`**](https://github.com/robotology/osqp-eigen.git) | https://github.com/robotology/osqp-eigen.git | `v0.8.1` | +| [**`UnicyclePlanner`**](https://github.com/robotology/unicycle-footstep-planner.git) | https://github.com/robotology/unicycle-footstep-planner.git | `v0.6.0` | +| [**`walking-controllers`**](https://github.com/robotology/walking-controllers.git) | https://github.com/robotology/walking-controllers.git | `v0.7.0` | +| [**`icub-gazebo-wholebody`**](https://github.com/robotology/icub-gazebo-wholebody.git) | https://github.com/robotology/icub-gazebo-wholebody.git | `v0.1.0` | +| [**`whole-body-controllers`**](https://github.com/robotology/whole-body-controllers.git) | https://github.com/robotology/whole-body-controllers.git | `v2.5.6` | +| [**`whole-body-estimators`**](https://github.com/robotology/whole-body-estimators.git) | https://github.com/robotology/whole-body-estimators.git | `v0.10.0` | +| [**`walking-teleoperation`**](https://github.com/robotology/walking-teleoperation.git) | https://github.com/robotology/walking-teleoperation.git | `v1.3.3` | +| [**`yarp-devices-forcetorque`**](https://github.com/robotology/yarp-devices-forcetorque.git) | https://github.com/robotology/yarp-devices-forcetorque.git | `v0.3.1` | +| [**`wearables`**](https://github.com/robotology/wearables.git) | https://github.com/robotology/wearables.git | `v1.7.2` | +| [**`HumanDynamicsEstimation`**](https://github.com/robotology/human-dynamics-estimation.git) | https://github.com/robotology/human-dynamics-estimation.git | `v2.8.0` | +| [**`human-gazebo`**](https://github.com/robotology/human-gazebo.git) | https://github.com/robotology/human-gazebo.git | `v1.1.0` | +| [**`yarp-device-xsensmt`**](https://github.com/robotology/yarp-device-xsensmt.git) | https://github.com/robotology/yarp-device-xsensmt.git | `v0.2.2` | +| [**`yarp-device-ovrheadset`**](https://github.com/robotology/yarp-device-ovrheadset.git) | https://github.com/robotology/yarp-device-ovrheadset.git | `v1.0.0` | +| [**`speech`**](https://github.com/robotology/speech.git) | https://github.com/robotology/speech.git | `v1.2.0` | +| [**`funny-things`**](https://github.com/robotology/funny-things.git) | https://github.com/robotology/funny-things.git | `v2.2.0` | +| [**`bipedal-locomotion-framework`**](https://github.com/ami-iit/bipedal-locomotion-framework.git) | https://github.com/ami-iit/bipedal-locomotion-framework.git | `v0.15.0` | +| [**`LieGroupControllers`**](https://github.com/ami-iit/lie-group-controllers.git) | https://github.com/ami-iit/lie-group-controllers.git | `v0.2.0` | +| [**`event-driven`**](https://github.com/robotology/event-driven.git) | https://github.com/robotology/event-driven.git | `v2.0` | +| [**`matioCpp`**](https://github.com/ami-iit/matio-cpp.git) | https://github.com/ami-iit/matio-cpp.git | `v0.2.2` | +| [**`diagnosticdaemon`**](https://github.com/robotology/diagnostic-daemon.git) | https://github.com/robotology/diagnostic-daemon.git | `v1.0.0` | +| [**`osqp-matlab`**](https://github.com/ami-iit/osqp-matlab-cmake-buildsystem.git) | https://github.com/ami-iit/osqp-matlab-cmake-buildsystem.git | `v0.6.2.3` | +| [**`robometry`**](https://github.com/robotology/robometry.git) | https://github.com/robotology/robometry.git | `v1.2.2` | +| [**`gym-ignition`**](https://github.com/robotology/gym-ignition.git) | https://github.com/robotology/gym-ignition.git | `v1.3.1` | +| [**`matlab-whole-body-simulator`**](https://github.com/ami-iit/matlab-whole-body-simulator.git) | https://github.com/ami-iit/matlab-whole-body-simulator.git | `v3.3.0` | +| [**`casadi-matlab-bindings`**](https://github.com/ami-iit/casadi-matlab-bindings.git) | https://github.com/ami-iit/casadi-matlab-bindings.git | `v3.6.3.0` | +| [**`idyntree-yarp-tools`**](https://github.com/robotology/idyntree-yarp-tools.git) | https://github.com/robotology/idyntree-yarp-tools.git | `v0.0.7` | +| [**`pyqtconsole`**](https://github.com/pyqtconsole/pyqtconsole.git) | https://github.com/pyqtconsole/pyqtconsole.git | `v1.2.2` | +| [**`meshcat-python`**](https://github.com/rdeits/meshcat-python.git) | https://github.com/rdeits/meshcat-python.git | `v0.3.2` | +| [**`robot-log-visualizer`**](https://github.com/ami-iit/robot-log-visualizer.git) | https://github.com/ami-iit/robot-log-visualizer.git | `v0.6.0` | +| [**`OpenXR`**](https://github.com/KhronosGroup/OpenXR-SDK.git) | https://github.com/KhronosGroup/OpenXR-SDK.git | `release-1.0.29` | +| [**`OpenVR`**](https://github.com/ami-iit/openvr.git) | https://github.com/ami-iit/openvr.git | `v1.16.8.1` | +| [**`yarp-device-openxrheadset`**](https://github.com/ami-iit/yarp-device-openxrheadset.git) | https://github.com/ami-iit/yarp-device-openxrheadset.git | `v0.0.2` | +| [**`yarp-openvr-trackers`**](https://github.com/ami-iit/yarp-openvr-trackers.git) | https://github.com/ami-iit/yarp-openvr-trackers.git | `v0.0.1` | +| [**`find-superquadric`**](https://github.com/robotology/find-superquadric.git) | https://github.com/robotology/find-superquadric.git | `v1.1.0` | +| [**`tomlplusplus`**](https://github.com/marzer/tomlplusplus.git) | https://github.com/marzer/tomlplusplus.git | `v3.3.0` | +| [**`proxsuite`**](https://github.com/Simple-Robotics/proxsuite.git) | https://github.com/Simple-Robotics/proxsuite.git | `v0.4.1` | +| [**`BayesFilters`**](https://github.com/robotology/bayes-filters-lib.git) | https://github.com/robotology/bayes-filters-lib.git | `0.10.0` | +| [**`mujoco`**](https://github.com/ami-iit/mujoco.git) | https://github.com/ami-iit/mujoco.git | `2.3.5.1` | +| [**`mujoco-simulink-blockset`**](https://github.com/ami-iit/mujoco-simulink-blockset-cmake-buildsystem.git) | https://github.com/ami-iit/mujoco-simulink-blockset-cmake-buildsystem.git | `v3.0.0` | diff --git a/docs/sw_versioning_table/index.md b/docs/sw_versioning_table/index.md index bdfecb29d..1c7bd237f 100644 --- a/docs/sw_versioning_table/index.md +++ b/docs/sw_versioning_table/index.md @@ -26,10 +26,11 @@ $ git clone https://github.com/robotology/icub-main.git -b v1.17.0 ``` ## Table -This table has been generated automatically by processing data available in [`robotology/robotology-superbuild@v2023.05.2/releases`](https://github.com/robotology/robotology-superbuild/tree/v2023.05.2/releases). +This table has been generated automatically by processing data available in [`robotology/robotology-superbuild@v2023.08.0/releases`](https://github.com/robotology/robotology-superbuild/tree/v2023.08.0/releases). Click on the distros below to explore their package versions: +- [📦 Distro **2023.08.0**](./2023.08.0.md){:target="_blank"} - [📦 Distro **2023.05.2**](./2023.05.2.md){:target="_blank"} - [📦 Distro **2023.05.1**](./2023.05.1.md){:target="_blank"} - [📦 Distro **2023.05.0**](./2023.05.0.md){:target="_blank"} diff --git a/docs/upgrade_kits/head_4k/support.md b/docs/upgrade_kits/head_4k/support.md index 490a0b5e1..32283d2af 100644 --- a/docs/upgrade_kits/head_4k/support.md +++ b/docs/upgrade_kits/head_4k/support.md @@ -174,7 +174,7 @@ The NVIDIA Jetson has to be configured following [the flash procedure](../../icu If the image has been [installed from scratch](../../icub_operating_systems/icubos/jetpack.md#flash-a-new-image-from-scratch), an initial configuration is also required, which consists in: -- Set the `icub` as `host` and `icub-head-cam` as `hostname` -- [Configure the network bridge and wifi](https://github.com/icub-tech-iit/setups-os-configuration/tree/master/system-files/iCubOS/ubuntu_20.04_bridge) +- Set the `icub` as `host` and `icub-head-cam` as `hostname`. +- [Configure the network bridge and wifi](https://github.com/icub-tech-iit/icub-os-files/blob/master/system-files/iCubOS/ubuntu_20.04_bridge/README.md). For using the images provided by the new Basler camera over the YARP network, it is needed to compile and install [`yarp-device-pylon`](https://github.com/robotology/yarp-device-pylon#2-how-to-use-basler-pylon-cameras-as-a-yarp-device). diff --git a/mkdocs.yml b/mkdocs.yml index cf303705b..fab0d988f 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -84,8 +84,8 @@ markdown_extensions: repo_url_shortener: true repo_url_shorthand: true - pymdownx.emoji: - emoji_index: !!python/name:materialx.emoji.twemoji - emoji_generator: !!python/name:materialx.emoji.to_svg + emoji_index: !!python/name:material.extensions.emoji.twemoji + emoji_generator: !!python/name:material.extensions.emoji.to_svg - pymdownx.mark - pymdownx.smartsymbols - pymdownx.superfences @@ -96,13 +96,13 @@ not_in_nav: | /sw_versioning_table/[0-9]*.md nav: - - iCub Tech Docs: - - Home Page: index.md + - 🟦 iCub Tech Docs: + - 🏠 Home Page: index.md - - iCub Starter Kits: + - 1️⃣ iCub Starter Kits: - First steps with the Humanoid iCub: icub_starter_kits/first_steps.md - - iCub HW: + - ⚙️ iCub HW: - Summary: icub_hw.md - The iCub Versions Table: - iCub Versions Table: icub_versions/index.md @@ -187,7 +187,7 @@ nav: - Power push buttons: robot_power/robot_power_button.md - Custom components: custom_components/custom_components.md - - iCub SW: + - 💻 iCub SW: - Summary: icub_sw.md - Software Installation: - Summary: sw_installation/index.md @@ -249,13 +249,18 @@ nav: - Installing Keil: icub_firmware/fw_toolchain/installing_keil.md - Installing MPLAB: icub_firmware/fw_toolchain/installing_mplab.md - Firmware Documentation: icub_firmware/firmware/firmware.md + - FirmwareUpdater Walkthrough: icub_firmware/firmwareupdater/firmwareupdater.md - Associated Firmware: icub_firmware/associated-firmware/associated-firmware.md - Old Tools: - CanLoader: icub_firmware/canLoader/canLoader.md - iCub Microphones: - How to use microphones: icub_microphones/icub_microphones.md - - BCB Board: - - Bluetooth Protocol: bcb_board/bcb_bluetooth_protocol.md + - Battery Boards: + - Summary: battery_boards/index.md + - BCB Board: + - Bluetooth Protocol: battery_boards/bcb_board/bcb_bluetooth_protocol.md + - BAT Board: + - BAT board Protocol: battery_boards/bat_board/bat_protocol.md - Robot Calibration: - iCub 2.X Robot Calibration: icub_robot_calibration/icub-robot-calibration-v2.x.md - iCub 1.3 Robot Calibration: icub_robot_calibration/icub-robot-calibration-v1.3.md diff --git a/scripts/linkchecker/linkcheckerrc b/scripts/linkchecker/linkcheckerrc new file mode 100644 index 000000000..4b1f2abaf --- /dev/null +++ b/scripts/linkchecker/linkcheckerrc @@ -0,0 +1,9 @@ +[checking] +threads=20 +sslverify=0 + +[output] +warnings=0 + +[filtering] +checkextern=1