Create3 stuck in boot loop

[Marwan-Refaat]

Overview:
While setting up my create3 robots, they got stuck in a boot loop. The lightring is displaying the pattern that corresponds to booting up (white spinning animation). When trying to cycle power, they turn off for less than a second and start the booting animation again.

Is there a way to possibly do a factory reset?

Details:
I was setting up 9 Create3 robots. I followed the directions for the setup guide (https://edu.irobot.com/create3-setup). I connected to each robot's hotspot, updated the robots' firmware, and waited for them to boot again.

The issue started when trying to connect them to wifi. After trying to connect them to wifi, the robots' lightring turned a solid red color. Following the directions from the docs (https://iroboteducation.github.io/create3_docs/hw/face/), I cycled their power by holding the power button for 20 seconds until they turned off and on again. From this point on, the robots have been stuck in the booting sequence (lightring displaying a spinning white animation).

It is worth noting that this only occurred for 5 of the 9 robots, the other 4 robots are booting up successfully and connecting to wifi (This was verified by using ros2 topic list). It is also worth noting that I set separate ROS_DOMAIN_ID and ROS_NAMESPACE variables for each robot I was setting up, but I am not certain the changes were actually saved for all 9 of the robots.

Actions taken:

• I have tried cycling power by holding the power button for 20 seconds, which just turns off the robot for less than a second, then turns on again and continues the same booting animation

• I have tried holding the two user interface buttons to turn on the robot's hotspot to no avail.

• I have tried switching the Bluetooth/USB switch on the robots to the USB setting and tried connecting to the webserver through USB to no avail as well.

• I have also tried looking for ways to possibly do a "hard" reset or factory reset, but I was not able to find any sources online for that.

Any suggestions on possible fixes are highly appreciated.

[shamlian]

Hi there,

Edit: I see now that you did attempt to do this first paragraph, but I'm leaving it here for another person's future reference. The second paragraph continues to be my recommendation to get into one robot in order to pull its logs so that we can verify that's indeed the issue. It sounds to me like you put multiple robots on a multicast-capable network without first changing their domain IDs or giving them unique namespaces. This page covers the reason that is a problem, and how to set them up. Is that what happened? If so, you need to get to this page on the webserver of each robot either to change the domain ID or to set a unique namespace.

My recommendation is that you remove the battery from all but one of the misbehaving robots. Removing the battery requires removing the bottom cover using five captive Philips screws on the bottom of each robot. Once only one robot is powered up, see if you can communicate with the robot as you had before. If so, first pull the logs so that we can verify the reason for application restarts, and then either change the domain ID or namespace of that robot. Then power them up in turn, and get them all on the network.

If after doing this, the remaining robot continues to have a spinning white light, please do also try to pull its battery, and move to one of the other robots whose battery had been pulled; once the robots are without their batteries for 15 minutes, you will have to seat the robot on the dock to wake it up, again. Also, fully booting a robot if it needs to recover can take as many as seven minutes. Please do wait that long before power cycling it, there could be further issues.

Let us know if that helps. I can't guarantee a rapid response during the weekend but we'll do our best.

PS: I would also recommend contacting [email protected] in the case that it does not.

[pcapdessus-invn]

I managed to access the webserver ( line cmd + admin rigth).
I can move on in my debuggin process.
Thank you again @shamlian and courage to Marwan

[shamlian]

@pcapdessus-invn That's great!! Did you end up having to give your computer a default gateway for the NIC? Also -- I would be interested in your raw logs if you haven't already attempted another upgrade (if you would rather not share them, I understand, or if you would rather not share them publicly, you can email them to [email protected] and I will ask our customer service to forward them to the engineering team).

[pcapdessus-invn]

@shamlian,
Unfortunately I immediately ran a firmware update to keep my luck...
Thank your very much for your help.

[Marwan-Refaat]

Thank you for the suggestions @shamlian and @pcapdessus-invn , unfortunately I had no luck accessing the robot's webserver

I currently do not have access to neither a Raspberry Pi nor a USB-Ethernet switch, so I attempted to connect to do it using a USB-USB connection, making sure that the adapter board was switched to the USB setting. I didn't have any luck getting it to work neither on my Ubuntu 20.04 system nor my Windows system, although I am not 100% sure I correctly set up my usb interface's IP as described.

@shamlian I think setting up support call at this point would be extremely useful as I have attempted all I know of at this point, and we are starting to approach an important date where we have to have these robots functioning.

@pcapdessus-invn if it's possible, can you provide me with some details on what you did to connect to your robot? Maybe I did not set up my USB interface correctly

Thank you in advance for any help!

[shamlian]

@Marwan-Refaat Check your inbox :) . FWIW the robot is a USB-C host, so unless your laptop has an OTG port, you can't plug it in USB-C to USB-C.

[pcapdessus-invn]

hi @Marwan-Refaat

Here is what I have done

• On iRobot get out the dongle and put the little trigger from bluetooth to USB-C
• Plug a wire from USB-C -> USB-Ethernet converter -> my ethernet port
• Etablish a local network connection:
  IP adresss : 192.168.186.3
  Subset mask : 255.255.255.0
  For that I openned a cmd terminal and typed
  netsh interface ipv4 set address name=<ID> static 192.168.186.3 mask=255.255.255.0

with a number belonging to your LAN interface. It can be retrieved by typing:
Netsh interface ipv4 show interface (mine what 6)

Then, I accessed to webserver at http://192.168.10.1

Hope it might help.
pierre

[Marwan-Refaat]

Thank you very much @pcapdessus-invn for the instructions, they worked flawlessly. Just one note, I was only able to access the robot on 192.168.186.3, not on the usual 192.168.10.1, which I believe was mentioned on the docs somewhere.

Thank you @shamlian for the help, I will confirm when I have all the robots working again via email. I have also attached the logs I pulled from the robots. I believe the issue was with me setting the namespace to robot-5 instead of robot_5, I might be wrong though.

Log file: logs.txt

This link does mention that ROS2 namespaces can only contain alphanumeric characters, underscores or curly braces, so I believe this might have been the issue.

Thank you again, you have been a great help!

[shamlian]

Glad you got it working! For what it's worth, we fixed (I hope!) the webserver's namespace regex in G.3.1, so hopefully if your robots are updated, at least that won't be able to happen, again.

And yes, the robot uses 192.168.186.2 on the USB interface. Probably I need to make another docs page that more explicitly lays out how to use the robot over usb0. Thanks for all the feedback and for bearing with us!