Alarm 8011 [59]: "Host on NIC check 2"

[ivanrulik]

I'm using a YRC1000micro with a motomini. For the connection I'm using an ubuntu 22.04 running ROS2 humble on docker
I have been trying to fix this alarm for a while but I have been unsuccessful.
After following the steps here https://github.com/Yaskawa-Global/motoros2/blob/main/doc/troubleshooting.md#alarm-801159
Here is the .yaml file the I'm uploading to fix the alarm but so far it still does not connect.

Any advice on this is greatly appreciated

[gavanderhoorn]

Could you please provide more information about the network configuration of your controller? Which IP addresses, netmasks and gateways do you have configured, and for which LAN ports?

Please also provide a copy of the PANELBOX.LOG file from your controller and a copy of a full debug log. Make sure to start the debug logger before you start the controller, to make sure you capture all output.

Please also confirm which version of MotoROS2 you have installed.

[ivanrulik]

Hi, thanks for replying fast.

• The controller has a manually set IP address of 192.168.1.95 while the computer that I'm using with micro-ros agent has the IP 192.168.1.101. This systems are connected over a network switch, more over I'm able to ping the controller IP address successfully
• I'll share you both PANELBOX.LOG and the debug log as soon as I get back to the robot
• I'm using the MotoROS2 version motoros2_0.1.2_yrc1000u_humble

[ivanrulik]

Hi, I'm attaching the PANELBOX.LOG file. As for the debug log I got this

python3 motoros2/tools/debug_listener.py 
Listening for MotoROS2 debug msgs (format: "[time_msg_rcvd] [ip:port] msg") ..
---
^C
No messages received, deleting empty log file

Not sure why I'm not even able to get the debug_listener to do anything, I can still ping the IP address of the controller from my PC

I'm also attaching a screenshot of the controller settings screen. The network config is new and I can still ping the controller from my PC

PANELBOX.LOG

Click to show screenshot

[gavanderhoorn]

I see the Ethernet/IP Option is Enabled while the Japanese model has it disabled. I'm not sure if that could be a cause for that controller to fail in connecting to the ROS PC.

It's unlikely.

If you could connect the monitor to the displayport and show us (using a video fi) what's being printed to it that would help.

I'm currently exporting the CMOS.BIN file but is taking hours (I'm not sure if that is normal).

it doesn't normally take that long, but it (partly) depends on the USB stick you're using. If it's particularly slow (writes that is), or somehow incompatible with the YRC1000u, it could take some time.

[ted-miller]

I'm currently exporting the CMOS.BIN file but is taking hours (I'm not sure if that is normal).

This is not normal. It should take 30-60 seconds to save the file from the pendant. Are you saving it on the pendant, or using a PC utility to retrieve the file? (Something like Robot Manager will be exceptionally slow to save the CMOS.BIN.)

I see the Ethernet/IP Option is Enabled while the Japanese model has it disabled. I'm not sure if that could be a cause for that controller to fail in connecting to the ROS PC.

E/IP doesn't necessarily need to be enabled. But the Network function does need to be enabled. I'm assuming it's enabled since you're seeing IP address settings. But I can confirm with the CMOS.BIN.

[ivanrulik]

Sorry guys, I have been busy trying to have a working setup for this repo and it has consumed most of my time. If by any chances you have experience with it I'm currently trying to debug something from the simulation with moveit.

For the current issue here is the CMOS.BIN file download

[gavanderhoorn]

Depending on what you need, I might suggest starting with a more vanilla MoveIt configuration that you create yourself.

The package hosted on the YEU organisation is quite complex, and might not be what you need.

[ivanrulik]

Thanks for the advice. I wanted to adapt that project to run it with our moto mini as a proof of concept before jumping into full development. But I'll take your advice.

I'll try to keep this discussion alive until we figure the solution if that makes sense.

[ted-miller]

For the current issue here is the CMOS.BIN file

Although DHCP is setting the controller IP to 10.1.1.x, MotoROS2 is reading the values that were input in Maintenance mode.

If you change these values in maintenance mode to be on the 10.1.1.x subnet, it will get rid of the alarm.

We generally don't recommend DHCP for robotic systems since the robot needs to definitively know the address of the agent PC.

[gavanderhoorn]

Tracking this in #242.

[ivanrulik]

Good news, @ted-miller solution solved the whole problem
I'll mark this discussion as solved. Thank you so much guys

docker run   -it   --rm   --net=host   --user=$(id -u):$(id -g)   microros/micro-ros-agent:humble     udp4     --port 8888
[1713986839.725128] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1713986839.725274] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[1713986840.658472] info     | ProxyClient.cpp    | ProxyClient              | session hard timeout enabled | client_key: 0xB5255AE1, timeout: 10000 ms
[1713986840.658532] info     | Root.cpp           | create_client            | create                 | client_key: 0xB5255AE1, session_id: 0x81
[1713986840.658627] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0xB5255AE1, address: 10.1.1.108:28635
[1713986840.773573] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0xB5255AE1, participant_id: 0x000(1)
[1713986840.993019] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x000(2), participant_id: 0x000(1)
[1713986840.997021] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x000(3), participant_id: 0x000(1)
[1713986841.002150] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[1713986841.279123] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x001(2), participant_id: 0x000(1)
[1713986841.282888] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x001(3), participant_id: 0x000(1)
[1713986841.288596] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[1713986841.292913] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x002(2), participant_id: 0x000(1)
[1713986841.297395] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x002(3), participant_id: 0x000(1)
[1713986841.301587] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[1713986841.319712] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x003(2), participant_id: 0x000(1)
[1713986841.323517] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x003(3), participant_id: 0x000(1)
[1713986841.328216] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x003(5), publisher_id: 0x003(3)
[1713986841.376269] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x000(7), participant_id: 0x000(1)
[1713986841.383290] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x001(7), participant_id: 0x000(1)
[1713986841.391954] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x002(7), participant_id: 0x000(1)
[1713986841.396732] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x004(2), participant_id: 0x000(1)
[1713986841.400349] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x004(3), participant_id: 0x000(1)
[1713986841.406296] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x004(5), publisher_id: 0x004(3)
[1713986841.408967] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0xB5255AE1, topic_id: 0x005(2), participant_id: 0x000(1)
[1713986841.413483] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0xB5255AE1, publisher_id: 0x005(3), participant_id: 0x000(1)
[1713986841.417460] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0xB5255AE1, datawriter_id: 0x005(5), publisher_id: 0x005(3)
[1713986841.540760] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x003(7), participant_id: 0x000(1)
[1713986841.578746] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x004(7), participant_id: 0x000(1)
[1713986841.585735] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x005(7), participant_id: 0x000(1)
[1713986841.591710] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x006(7), participant_id: 0x000(1)
[1713986841.598075] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x007(7), participant_id: 0x000(1)
[1713986841.603985] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x008(7), participant_id: 0x000(1)
[1713986841.609780] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x009(7), participant_id: 0x000(1)
[1713986841.648984] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x00A(7), participant_id: 0x000(1)
[1713986841.684201] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x00B(7), participant_id: 0x000(1)
[1713986841.723637] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x00C(7), participant_id: 0x000(1)
[1713986841.760837] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x00D(7), participant_id: 0x000(1)
[1713986841.797214] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0xB5255AE1, requester_id: 0x00E(7), participant_id: 0x000(1)

[gavanderhoorn]

I'm happy this now works, but I'm confused as to why only the "Japanese version" of the robots described by @ivanrulik would be affected by the static/DHCP configuration discrepancy.

@ivanrulik: were all the controllers you tested configured via DHCP, or were there some that had a static IP configured (in Maintenance mode)?

[ivanrulik]

At some point one of the robots, the japanese model was set manually but we moved it to dhcp once we figured how to set it properly. There is chance that this error could have happened with the global version of the controller

[ivanrulik]

Solution

Review that network setup in regular mode and maintenance mode point to the ROS2 computer network

For the current issue here is the CMOS.BIN file

Although DHCP is setting the controller IP to 10.1.1.x, MotoROS2 is reading the values that were input in Maintenance mode.

If you change these values in maintenance mode to be on the 10.1.1.x subnet, it will get rid of the alarm.

We generally don't recommend DHCP for robotic systems since the robot needs to definitively know the address of the agent PC.