ETH board setup - change IP address and see available cards

[plinioMoreno]

Brief description

We are setting up an ETH control board with some motors, and we want to know how to see the connected cards and the info on the firmware, and define IP address for instance.

Any manual or documentation is very appreciated.

Detailed context

Accompanying material

[marcoaccame]

Hi @plinioMoreno, here is some documentation related to the maintainance of the fw.

If for instance, you want to change the IP address of an EH board, follow instructions inside FirmwareUpdater.readme.fulldetails.txt and use the button Change IP Address after you have launched

$ FirmwareUpdater --admin 

[davidetome]

Hi @plinioMoreno , you should take a look also at https://icub-tech-iit.github.io/procedures/tp-boards-programming/#31-change-ip-address-to-eth-boards

ciao!

[plinioMoreno]

Hi all,

@davidetome and @marcoaccame thanks for the info. To be able to run the python script https://github.com/robotology/icub-firmware-build/blob/master/scripts/manageFWrobot.py on windows, what is your preferable way of installing python and its corresponding dependencies?

Thanks in advance

Plinio

[plinioMoreno]

Regarding the firmware updater,

To be able to run the python script https://github.com/robotology/icub-firmware-build/blob/master/scripts/manageFWrobot.py on windows, what is your preferable way of installing python and its corresponding dependencies?

Thanks in advance

[pattacini]

For what is worth, I've used choco package manager and python's been working smoothly for me.

Sooner or later winget will take over all competitors 😏

[plinioMoreno]

Hi all,

We are having troubles with finding two ETH boards that we purchase a while ago. The boards have the IP address 10.0.1.99 and when we plug the ethernet cable to a socket, the ping command replies as expected.

Next, we plug the ETH board to a network interface, and from a Windows PC with the FirmwareUpdater from the most recent release, we run the FirmwareUpdater, using the configuration file here, we cannot see the boards and the discover button cannot find the board either. Due to network configuration (broadcast, subnetwork, etc), we also tried plugging the ETH board directly to the LAN interface of the computer we are using, but this did not work either.

We also tried to detected the board from the PC104 of our icub, using the command

FirmwareUpdater --nogui --verbosity 1 --device ETH --id eth1 --eth_board 10.0.1.99

and the card was not found.

Let us know what are we missing on the tests, any info on the network configuration.

Best regards,

Plinio

[davidetome]

Hi all,

We are having troubles with finding two ETH boards that we purchase a while ago. The boards have the IP address 10.0.1.99 and when we plug the ethernet cable to a socket, the ping command replies as expected.

Next, we plug the ETH board to a network interface, and from a Windows PC with the FirmwareUpdater from the most recent release, we run the FirmwareUpdater, using the configuration file here, we cannot see the boards and the discover button cannot find the board either. Due to network configuration (broadcast, subnetwork, etc), we also tried plugging the ETH board directly to the LAN interface of the computer we are using, but this did not work either.

We also tried to detected the board from the PC104 of our icub, using the command

FirmwareUpdater --nogui --verbosity 1 --device ETH --id eth1 --eth_board 10.0.1.99

and the card was not found.

Let us know what are we missing on the tests, any info on the network configuration.

Best regards,

Plinio

Hi @plinioMoreno , did you config the ETH interface of the windows machine with the static iP address 10.0.1.104 ?

cc @marcoaccame @pattacini

[davidetome]

@plinioMoreno take a look at https://icub-tech-iit.github.io/procedures/tp-mc4plus/#32-configure-usb-eth-adapter

[plinioMoreno]

@davidetome, no we did not configure the static IP address as 10.0.1.104. Thanks for the pointer to the configuration.

We will try later and let you know.

Thanks,

Plinio

[plinioMoreno]

Hi again,
Defining the IP address 10.0.1.104 allows us to find the ETH boards. And we are able to change the IP address of the cards to any address in the subnetwork 10.0.1.X.

But we cannot change the IP address to another subnetwork, for instance 10.1.XX. Is it possible to define a 10.1.XX address? If yes, how do we do that?

Thanks in advance.

[davidetome]

Hi again,
Defining the IP address 10.0.1.104 allows us to find the ETH boards. And we are able to change the IP address of the cards to any address in the subnetwork 10.0.1.X.

But we cannot change the IP address to another subnetwork, for instance 10.1.XX. Is it possible to define a 10.1.XX address? If yes, how do we do that?

Thanks in advance.

Ciao @plinioMoreno , as far as I know FirmwareUpdater is intended to run on the iCub's head PC with the default gateway set to 10.0.1.104; unfortunately this address is hardcoded and not configurable at the moment.

@marcoaccame could you confirm this?

[plinioMoreno]

@marcoaccame, according to the instructions here, it is possible to change the IP address of the ETH boards to e.g. 10.0.0.1.
However, after looking into the code of EthManteiner.cpp, the condition does not allow to change the IP address to a new address, unless the new IP address is on the subnet 10.0.1.X. I guess this is because of the usual setup of your robots. But we want to change the address to for example 10.1.3.4.

Let us know if the following idea works:

1. Change the code of EthMantainer to remove the condition on the subnet
2. Change the IP address of the ETH board to 10.1.3.4
3. After this, the ETH board should not be visible, so we have to change the IP address of the host machine to e.g. 10.1.3.125 (both in the EthMantainer.cpp and on the network interface of the pc.
4. Run again the FirmwareUpdater with the new host address and the ETH board should be visible.

Looking forward to hearing from you @marcoaccame and @davidetome

[davidetome]

@marcoaccame, according to the instructions here, it is possible to change the IP address of the ETH boards to e.g. 10.0.0.1.
However, after looking into the code of EthManteiner.cpp, the condition does not allow to change the IP address to a new address, unless the new IP address is on the subnet 10.0.1.X. I guess this is because of the usual setup of your robots. But we want to change the address to for example 10.1.3.4.

Let us know if the following idea works:

1. Change the code of EthMantainer to remove the condition on the subnet
2. Change the IP address of the ETH board to 10.1.3.4
3. After this, the ETH board should not be visible, so we have to change the IP address of the host machine to e.g. 10.1.3.125 (both in the EthMantainer.cpp and on the network interface of the pc.
4. Run again the FirmwareUpdater with the new host address and the ETH board should be visible.

Looking forward to hearing from you @marcoaccame and @davidetome

Ciao @plinioMoreno ,

Take in account that both yarprobotinterface and ETH boards firmware work only in the 10.0.1.XX subnet.
Anyway feel free to go on with the mods you proposed.

cc @marcoaccame @pattacini

[davidetome]

@plinioMoreno please do your mods in a fork of the repo . Then , once done, open a pull request to the devel branch of the original repo so we can include your mods.

If you need any help feel free to ask us! 👍

[plinioMoreno]

@davidetome, thanks for the reply.

Following up on your reply, on the yarprobotinterface side I think we do the changes to work on other subnetworks. But on the firmware side I'm not sure where should I look on the ETH boards firmware, to see if the firmware code can be changed to work on other subnetworks than 10.0.1.X. Any pointers on the firmware code would be very appreciated.

[marcoaccame]

Hi @plinioMoreno, I confirm that so far we have used the ETH boards only talking to the Linux system of the robot or with a PC with fixed IP address 10.0.1.104 w/ the 10.0.1.X IP mask.

It is surely possible to adapt the system (formed by the ETH boards, yarprobotinterface but also FirmwareUpdater, maybe something else ...) to use other network configurations. It is something that I thought to be useful and I had a look at some solutions long ago but eventually we did not proceed, basically for lack of time.

Let me collect my thoughts about icub-main, icub-firmware and robots-configuration issues and I will post back soon today or on Monday something which I hope can be useful for you.

[marcoaccame]

Hi, here are some info.

firmware

Here are some info of the firmware.

• you need to understand which programs runs an ETH board. pls see: eth.board.implementation.md and here.

• in here you have the project for the eUpdater of the ems board.

• in here you have the project for the eApplication of the ems board.

To compile the above projects you need a valid license for mdk-arm for use on cortex-m MPUs.

We use an educational license which comes in bundle of 25 user which costs about 1000 EUR, but I know that there is also a bundle for 10 users only which costs less.

If I remember correctly, and I may miss something, here are the aspects to be considered:

how to have the ETH boards talk to a host different of 10.0.1.104

i think we need to change something in some repos.

here is a quick collection of thoughts.

in icub-main

• FirmwareUpdater must be able to talk correctly to the ETH boards. the used ports are 3333 for discovery and data transfer which stays on the ETH board and 3334 for CAN gateway. That includes unicast but also broadcast transmission. We should look at parts of icub-main/.../ethLoade and maybe also of icub-main/.../FirmwareUpdater

• yarprobotinterface must open correctly the socket vs the ETH boards. It is port 12345. I think/hope that the code in icub-main is able to run with any IP addresses inside the xml files in robots-configuration.

in icub-firmware or icub-firmware-shared.

• The eUpdater of ETH boards must be able to receive correctly from any IP address of a given netmask (ports 3333 and 3334). See firmware of eUpdater of the ems board. Surely the subnet mask needs to be changed and the project must hence be recompiled. Maybe that is enough. Tests are however required. For instance, try to run the FirmwareUpdater from 10.0.1.105... if it works you can change the netmask and test again with 10.1.1.105. More details if you need them.

• The eApplication of the ems board must be able to talk to the FirmwareUpdater: it accepts UDP packets on port 3333 and replies to them. For sure we need to change the subnet mask. Then, probably the ems is already able to talk to the FirmwareUpdatre on the discovery port 3333 if that address is on its subnet mask. I see code that I remember did that: see here and here and here. It should be tested.

• the eApplication must also be able to talk over port 12345 with yarprobotintrafce. the object EOMtheEMSsocket is responsible for that. At startup it attempts ARP connection to the host, which is configured by default as 10.0.1.4 (see here). Then, however, it can receive any UDP packet on port 12345. But unluckily the parser discards the packets which are not coming from the host. see here. The address of the host can however be changed in host address config. Conclusion: either you change the host address to be a different one and recompile the project, or ... you relax condition in here so that packets are not filtered by IP address.

Conclusions

I think that with focused changes the system can work with an IP address different from 10.0.1.104 and also with a different netmask. Some changes in icub-main and in icub-firmware are required. Tests also.

[plinioMoreno]

Hi @marcoaccame, many thanks for the detailed reply. To address the changes in the firmware and the FirmwareUpdater, we have to discuss here if we can find someone to do this task, because right now we do not have anybody with the right profile to do the changes in an efficient way.

Regarding the compilation

To compile the above projects you need a valid license for mdk-arm for use on cortex-m MPUs.

We would need to have additional hardware to do this? Or after compiling the FirmwareUpdater should be enough to transfer the firmware to the boards?

We use an educational license which comes in bundle of 25 user which costs about 1000 EUR, but I know that there is also a bundle for 10 users only which costs less.

Do you know if this license has to be renewed every year? From the maintenance point of view it would be nice if the changes reach your workflow, so we do not have to compile the firmware. This is the way we have been working for our robot Vizzy (which still has CAN boards), we do not have to compile the firmware.

If I remember correctly, and I may miss something, here are the aspects to be considered:

how to have the ETH boards talk to a host different of 10.0.1.104

i think we need to change something in some repos.

here is a quick collection of thoughts.

in icub-main

* `FirmwareUpdater` must be able to talk correctly to the `ETH` boards. the used ports are `3333` for discovery and data transfer which stays on the `ETH` board and `3334` for CAN gateway. That includes unicast but also broadcast transmission. We should look at parts of [icub-main/.../ethLoade](https://github.com/robotology/icub-main/tree/devel/src/tools/ethLoader) and maybe also of [icub-main/.../FirmwareUpdater](https://github.com/robotology/icub-main/tree/devel/src/tools/FirmwareUpdater)

* `yarprobotinterface` must open correctly the socket vs the `ETH` boards. It is port `12345`. I think/hope that the code in `icub-main` is able to run with any IP addresses inside the xml files in `robots-configuration`.

Regarding this point, I wonder if the ETH boards will work with their own 10.0.1.X network while having the rest of the robot (pc that runs the yarpserver and robot drivers) in another network (10.X.X.X). I'm asking this question to see if we can have an operational setup as soon as possible.

in icub-firmware or icub-firmware-shared.

* The `eUpdater` of  ETH boards must be able to receive correctly from any IP address of a given netmask (ports `3333` and `3334`). See firmware of  [eUpdater](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/env/eUpdater/proj/eom-eupdater-open.uvprojx) of the `ems` board. Surely the [subnet mask](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/env/eUpdater/abslayer-cfg/ipal_cfg.h#L184) needs to be changed and the project must hence be recompiled. Maybe that is enough. Tests are however required. For instance, try to run the `FirmwareUpdater` from `10.0.1.105`... if it works you can change the netmask and test again with `10.1.1.105`. More details if you need them.

* The  [eApplication](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/appl/v2/proj/ems4rd.diagnostic2ready.uvprojx) of the `ems` board must be able to talk to the `FirmwareUpdater`: it accepts UDP packets on port `3333 `and replies to them.  For sure we need to change the [subnet mask](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/appl/v2/cfg/abslayer/ipal_cfg.h#L191). Then, probably the `ems` is already able to talk to the `FirmwareUpdatre` on the discovery port `3333` if that address is on its  subnet mask. I see code that I remember did that: [see here](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/appl/v2/cfg/eoemsappl/EOMtheEMSapplCfg_cfg.h#L345) and [here](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/embobj/plus/ctrloop/EOMtheEMSsocket.c) and [here](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/embobj/plus/ctrloop/EOMtheEMSdiscoverytransceiver.c#L206). It should be tested.

* the `eApplication` must also be able to talk over port `12345` with `yarprobotintrafce`. the object [`EOMtheEMSsocket`](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/embobj/plus/ctrloop/EOMtheEMSsocket.c) is responsible for that. At startup it attempts ARP connection to the host, which is configured by default as `10.0.1.4 ` (see [here](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/embobj/plus/ctrloop/EOMtheEMSappl.c#L593)). Then, however, it can receive any UDP packet on port `12345`. But unluckily the parser discards the packets which are not coming from the host. see [here](https://github.com/robotology/icub-firmware-shared/blob/master/eth/embobj/plus/comm-v2/transport/EOtransceiver.c#L315). The address of the host can however be changed in [host address config](https://github.com/robotology/icub-firmware/blob/devel/emBODY/eBcode/arch-arm/board/ems004/appl/v2/cfg/eoemsappl/EOMtheEMSapplCfg_cfg.h#L32). `Conclusion`: either you change the host address to be a different one and recompile the project, or ... you relax condition in [here](https://github.com/robotology/icub-firmware-shared/blob/master/eth/embobj/plus/comm-v2/transport/EOtransceiver.c#L317) so that packets are not filtered by IP address.

Conclusions

I think that with focused changes the system can work with an IP address different from 10.0.1.104 and also with a different netmask. Some changes in icub-main and in icub-firmware are required. Tests also.

[pattacini]

A related issue just created on this topic: robotology/icub-firmware#122.

[plinioMoreno]

@marcoaccame, let me know about my questions in my last comment.

I also want to add that we are considering an upgrade of our icub, and the robot is currently in a local network that does not match the subnet of the ETH boards. This is related also to my question in the previous comment.

Thanks in advance

[davidetome]

Ciao @plinioMoreno , sorry for the late reply but we also had some period of vacation...
Anyway just an update, I'm working on FirmwareUpdater mods and then with @marcoaccame we're going to modify the fw ..

We'll update you asap.

cc @marcoaccame @pattacini

[plinioMoreno]

Hi @davidetome,

Hope you had a good vacation. Thanks for the update, and thank you @davidetome and @marcoaccame for working on this. Looking forward to hearing from you back.

[davidetome]

Ciao @plinioMoreno ,

Just an update, I'm working on firmware mods in these days with the support of @marcoaccame , we'll update you on this 👍

cc @pattacini

[plinioMoreno]

@davidetome thanks for the update. Looking forward to have those changes here for testing.

[davidetome]

Ciao @plinioMoreno ,

I'd like to inform you that the mods on the firmware side are done and under revision in the following PRs:

• ETH boards - added remote address configurator icub-firmware-shared#41
• ems v3.35, mc4plus v3.28, mc2plus v3.19 icub-firmware-build#18

cc @pattacini @marcoaccame

[plinioMoreno]

Hi @davidetome, thanks for the update. I see that the network of the pc104 is now a different one, that is great for the network setup of our robot Vizzy.

cc @rnun3s

[davidetome]

Ciao @plinioMoreno , just to inform you that the above PRs have been merged on devel branch 👍🏻

cc @pattacini @marcoaccame

[plinioMoreno]

Thanks @davidetome! If we want to try the IP change, how should we proceed?

[davidetome]

Ciao @plinioMoreno !

I've updated this PR adding some useful (hopefully) documentation on how to prepare the setup to use a different IP subnet from the standard one 10.0.1.X
Please, have a look and let me know if it is all clear.

cc @pattacini @marcoaccame

[plinioMoreno]

@davidetome, thanks for the pointer to the documentation. It seems to have the instructions to do the IP changes, but I have a more basic question: Is it enough to change all the repositories to the devel branch? Or is it enough to change just yarp and icub-main.

[pattacini]

icub-main, icub-firmware-shared, and icub-firmware-build put in devel alongside with yarp@master should suffice.
@davidetome correct me if I got it wrong.

[pattacini]

Side note: yarp@devel has been superseded in favor of yarp@master.

[davidetome]

icub-main, icub-firmware-shared, and icub-firmware-build put in devel alongside with yarp@master should suffice.
@davidetome correct me if I got it wrong.

You're right @pattacini 👍🏻

cc @plinioMoreno

[plinioMoreno]

@davidetome, by following your instructions we were able to change the IP address on one of our MC4plus boards (to a 10.1.x.x subnet). Thank you for the changes. We still have to do more tests with the EMS4 and let you know.

[plinioMoreno]

@davidetome, we were able to change the IP address of the one EMS4 board we have as well.