Robot fails to boot after any issues with RMW config override XML for Cyclonedds

[lukeopteran]

The robot is unable to fully boot (LED keeps spinning with no Chime), with an issues in the XML config. It would be best if it could handle the exception and add an error to the log output.

Examples include setting a non-existing network device ID or setting the wrong network interface parameter for cyclone, e.g. using the Humble format for Galactic robot firmware.

Humble XML

     <General>
        <Interfaces>
          <NetworkInterface name="usb0"/>
        </Interfaces>     
      <AllowMulticast>true</AllowMulticast>
      <MaxMessageSize>65500B</MaxMessageSize>
      <DontRoute>true</DontRoute>
    </General>

Rather than

        <General>
      <Interfaces>
          <NetworkInterface name="usb0" />
      </Interfaces>
      <AllowMulticast>true</AllowMulticast>
      <DontRoute>true</DontRoute>
    </General>

The robot was only recoverable using the api approach to factory reset it, via the ethernet over USB, no hotspot available....

Setup
Robot firmware = G5.2
Pi4 Ubuntu 20.04 inside inside on Usb0

[shamlian]

You are right -- the robot application does not start when the DDS XML configuration is malformed (forcing the user to use the webserver to fix the robot). We can look into some kind of fallback, but I am not sure that ROS 2 has an easy/native way to do this with a misconfigured middleware. (This is why editing the XML is considered a "beta feature.")

[lukeopteran]

@shamlian Thanks, it's quite easy to get the config wrong (especially the Galactic / Humble changes), so a safe fall over would be a really useful / appreciated feature!

[alsora]

Validating the xml when is written in the webserver won't be easy. We can validate generic xml syntax, but to do more you need a c++ application that uses the dds APIs, there's not even a generic (rmw-agnostic) approach exposed by ros.

I would also not want to fallback to the default xml if there's a problem.
Users will likely not notice that we are falling back and then waste time using a different xml than what they were looking for.

If anything, we should make the cause of the error more prominent and allow fixing it without having to factory reset.

[shamlian]

There is no need to factory reset. The user just has to connect to the webserver and delete (or change) their custom XML profile. (And possibly restart the application, if it's not already crashlooping. 😬 ) Deleting the custom profile will cause the robot to fall back to its default.

[alsora]

Ok, that's good.
I was commenting based on @lukeopteran experience:

The robot was only recoverable using the api approach to factory reset it, via the ethernet over USB, no hotspot available....

We could have a page in the docs that describes how to use this feature, what could go wrong and what's the approach to recover.

[shamlian]

That is odd, because the web server was running for the API to be served. It should have been just as possible to instead connect to the web page hosting the XML file and delete it (I could probably toss together a curl command for this). Agree that we could improve the docs.

[shamlian]

The call should be as simple as curl -X POST -d "config=" "http://192.168.186.2/rmw-profile-override-save" to clear the custom XML profile and get the robot back. This should work over any active interface (so if you were configuring over Wi-Fi, use that IP address instead). If the robot's application is not crashlooping, it would also be necessary to restart the application with curl -X POST http://192.168.186.2/api/restart-app

[lukeopteran]

That's great thanks, will give it a go