[Q] Is it expected that the McuConfigure Hangs & Takes Effect on Reboot?

[SteveMacenski]

I'm removing the namespacing from my robot system so I can have a single repository and capability that generalizes to all robots in the fleet. This has turned into quite the challenge, but I'm broadly done with it except something worth digging into.

This is where the namespace for the MCU ROS 2 code

        self.configure_mcu = LaunchFile.Process(
            name='configure_mcu',
            cmd=[
                ['export ROS_DOMAIN_ID=0;'],
                [LaunchFile.Variable("FindExecutable(name='ros2')"),
                 ' service call platform/mcu/configure',
                 ' clearpath_platform_msgs/srv/ConfigureMcu',
                 ' \"{{domain_id: {0},'.format(self.clearpath_config.system.domain_id),
                 ' robot_namespace: \\\'{0}\\\'}}\"'.format(self.namespace)]
            ]
        )

When I try calling this, no matter the contents, it hangs indefinitely and never gives a result. I was about to email you guys about how to make this work but before I did I tried rebooting and that made it take effect.

So, my question is: is it expect behavior that this doesn't work and hangs forever without a response to the service call - then takes effect on the next reboot? Some logging or notification about that would be wonderful. I don't even mind the reboot, that makes sense to me, but the lack of a response + hanging makes me think the MCU didn't get the service call at all.

[roni-kreinin]

When the MCU first boots it will default to domain ID 0 and namespace /. This service call assumes that the MCU is in this default configuration and will use ROS_DOMAIN_ID=0 and /platform/mcu/configure to reconfigure the MCU. The MCU will then internally restart its microROS application with the new domain ID and namespace.

If the domain ID or namespace have already been changed by a service call then this service call will hang indefinitely because the launch file doesn't have any way of knowing what domain ID or namespace the MCU is on. As a result, the new domain ID or namespace will only take effect on the next reboot because the MCU will have reset back to domain ID 0 and namespace /.

If you want to reconfigure the MCU without rebooting the robot, you can manually call the platform/mcu/configure service at whatever domain ID and namespace it is currently on.

[SteveMacenski]

the launch file doesn't have any way of knowing what domain ID or namespace the MCU is on
If you want to reconfigure the MCU without rebooting the robot, you can manually call the platform/mcu/configure service at whatever domain ID and namespace it is currently on.

I'm manually checking with ros2 service list and calling the service on the CLI ros2 service call ... and that is hanging, so the MCU is broadcasting the service in the j100_XXXX namespace since the systemd bringup sends that service once before I get in to call it again to revert. So I've tried that and that's what I reported as the indefinite hang in my CLI.

That makes sense then why after a reboot it worked for me. Its not that it hung indefinitely and needed a reboot; its that while I was testing this, I disableed the clearpath systemd daemons so when I rebooted the MCU reverted back to / namespace on its own volition and there was no service call on bootup to remap otherwise.

That's making me think possibly calling it 2x in one session is a problem? Or something else is afoot? Regardless, I have my solution then if it defaults to / namespace and I disable the CPR daemon which moves it to something else. If you can't reproduce this, then I suppose there's no issue on my side needing solution - I have my path forward just removing the bootup call.

[roni-kreinin]

This issue was fixed in clearpath_firmware release 1.0.0.