Unknown mode detected

[rwayong]

Hi, I'm using Roomba 642 and a simple USB-serial connection to connect it to my raspberry pi 3. When first I run roslaunch ca_driver create_2.launch, it outputs [CREATE] Unknown mode detected but I ignore it. Then, I run teleop_joy_keyboard and successfully control my roomba with the keyboard. However, when I try it again, this time when I run roslaunch ca_driver create_2.launch, it gives me an error as below and my roomba freezes. I'm running create_autonomy on ROS kinetic.

pi@pi-desktop:~/catkin_ws$ roslaunch ca_driver create_2.launch 
... logging to /home/pi/.ros/log/93e6802c-306c-11ea-85c7-b827eba5a161/roslaunch-pi-desktop-2378.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

xacro: Traditional processing is deprecated. Switch to --inorder processing!
To check for compatibility of your document, use option --check-order.
For more infos, see http://wiki.ros.org/xacro#Processing_Order
xacro.py is deprecated; please use xacro instead
started roslaunch server http://pi-desktop:44355/

SUMMARY
========

PARAMETERS
 * /ca_driver/base_frame: base_footprint
 * /ca_driver/dev: /dev/ttyUSB0
 * /ca_driver/latch_cmd_duration: 0.2
 * /ca_driver/loop_hz: 10.0
 * /ca_driver/odom_frame: odom
 * /ca_driver/publish_tf: True
 * /ca_driver/robot_model: CREATE_2
 * /robot_description: <?xml version="1....
 * /rosdistro: kinetic
 * /rosversion: 1.12.14

NODES
  /
    ca_driver (ca_driver/ca_driver)
    robot_state_publisher (robot_state_publisher/robot_state_publisher)

ROS_MASTER_URI=http://localhost:11311

process[ca_driver-1]: started with pid [2431]
process[robot_state_publisher-2]: started with pid [2438]
[ INFO] [1578305369.481359865]: [CREATE] "CREATE_2" selected
[ INFO] [1578305370.552198949]: [CREATE] Connection established.
[ INFO] [1578305370.553044573]: [CREATE] Battery level 49.81 %
[ INFO] [1578305370.808227190]: [CREATE] Ready.
[ERROR] [1578305370.809554949]: [CREATE] Unknown mode detected
[ERROR] [1578305370.909520832]: [CREATE] Unknown mode detected
[ERROR] [1578305371.009491455]: [CREATE] Unknown mode detected
[ERROR] [1578305371.110775420]: [CREATE] Unknown mode detected
[ERROR] [1578305371.209784284]: [CREATE] Unknown mode detected
[ERROR] [1578305371.309791583]: [CREATE] Unknown mode detected
[ERROR] [1578305371.410613726]: [CREATE] Unknown mode detected
[ERROR] [1578305371.509811808]: [CREATE] Unknown mode detected
[ERROR] [1578305371.609841555]: [CREATE] Unknown mode detected
[create::Serial] serial error - End of file
[ERROR] [1578305371.709839584]: [CREATE] Unknown mode detected
[FATAL] [1578305371.711663644]: [CREATE] Runtime error: write: Input/output error
[ INFO] [1578305371.712741767]: [CREATE] Destruct sequence initiated.
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  write: Input/output error
[ca_driver-1] process has died [pid 2431, exit code -6, cmd /home/pi/catkin_ws/devel_isolated/ca_driver/lib/ca_driver/ca_driver __name:=ca_driver __log:=/home/pi/.ros/log/93e6802c-306c-11ea-85c7-b827eba5a161/ca_driver-1.log].
log file: /home/pi/.ros/log/93e6802c-306c-11ea-85c7-b827eba5a161/ca_driver-1*.log

I really hope you can help me with this error. Thanks!

[jacobperron]

Apologies for not replying sooner. Seeing that "unknown mode detected" error is concerning. It means that it is not correctly reading packets over serial. This probably also explains the driver crashing unexpectedly.

I suggest starting and stopping the driver to try and get the Create into the OFF state (or trying a hard reset by holding down the power button until you hear a reset sound).

I'm going to close this since it seems to be an issue unique to your robot. But feel free to keep commenting if the issue persists (or you found a solution!).

[GrobaxGrappleBlast]

i am experiencing a similar issue with roomba 675, unknown mode detected, I have no idea how to handle the issue. seeing this closed is troubeling since its clearly not an isolated case

[jacobperron]

@GrobaxGrappleBlast Thanks for reporting, it's good to know it may not be an isolated issue.

I don't have a Roomba 6xx, and not able to reproduce. Have you tried resetting the robot as I suggested above?

[vinnnyr]

Just chiming in here, I have gotten this in the foxy port as well, but can get the robot to move with some sequence of restarting the robot and launching the driver. I also have a 600 series robot. Is there some information we should report back to help further drill down this issue?

[hypertechnic]

+1, same "unknown mode detected" error on 675, running melodic on jetson nano

[blaine141]

+1, same "unknown mode detected" error on 694, running kinetic on Raspberry Pi Zero W. I'm going to see if I can find out why only that command is failing.

[eddiem3]

Just happened to me on a 694 w/ a Raspberry PI 3B on melodic. After the unknown mode error started, the Roomba shut off. I think it's bricked now :/

[blaine141]

Hey! A fellow 694! I will say I've been using this code with a 694 and while I do get the message, I've never had any negative consequences and definitely never bricked it

[eddiem3]

Haha yes Team 694! It came back on after I plugged the MDIN back in and ran the launch file again go figure. It still isn't acting the same so I'm trying to factory reset it. You were able to eventually use this package even with the error?

[blaine141]

Yeah, I am using it currently haven't run into any major issues so far but there may be some feature that doesn't work that I haven't used yet.

On Fri, Jan 14, 2022, 10:36 PM Eddie Massey III @.***> wrote:

Haha yes Team 694! It came back on after I plugged the MDIN back in and ran the launch file again go figure. It still isn't acting the same so I'm trying to factory reset it. You were able to eventually use this package even with the error?

— Reply to this email directly, view it on GitHub https://github.com/AutonomyLab/create_robot/issues/64#issuecomment-1013600632, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQRTEZMYR4PCOJXP634PKTUWDTS5ANCNFSM4KDOIB6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[jacobperron]

@eddiem3 @blaine141 Which version of create_robot are you using?

It'd be interesting to know if an older version exhibits the same issue. E.g. build 1.3.0 from source. I think it might require libcreate 1.6.1, but you may also get away with 2.0.0.

I'm wondering if there was a recent change that is causing this issue.

[jacobperron]

Note, the issue is likely coming from libcreate, so playing around with the version of that package might be good to try.

[process1183]

Hi. I have also encountered this issue on a 690 using a RPi ZW and ROS2 Foxy. I am using the foxy branch of this create_robot repo (create_driver v1.3.0) and themaster branch of libcreate (v2.0.0). The problem appears to be caused by libcreate reporting the mode as 4. I made a simple change to create_driver.cpp so it includes the mode in the error message, and got the following console output.

josh@roomba:~$ ros2 run create_driver create_driver
[INFO] [1643605421.270118629] [create_driver]: [CREATE] "CREATE_2" selected
[INFO] [1643605422.390801433] [create_driver]: [CREATE] Connection established.
[INFO] [1643605422.393783411] [create_driver]: [CREATE] Battery level 94.05 %
[INFO] [1643605422.892660763] [create_driver]: [CREATE] Ready.
[ERROR] [1643605423.019346836] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.095406280] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.194536555] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.294530824] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.394526093] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.494524361] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.594800628] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.694520899] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.794520167] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.894517436] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605423.994521705] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605424.094808971] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605424.194519242] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605424.294591510] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605424.394601779] [create_driver]: [CREATE] Unknown mode (4) detected
[ERROR] [1643605424.494618047] [create_driver]: [CREATE] Unknown mode (4) detected
^C[INFO] [1643605424.506785958] [rclcpp]: signal_handler(signal_value=2)
[INFO] [1643605424.558102583] [create_driver]: [CREATE] Destruct sequence initiated.

I was not able to test libcreate 1.6.1 or 1.6.0 due to build failures. Please let me know if you would like more info or want me to test any changes!

[jacobperron]

4 is not a valid mode that I'm aware of. From the spec, we expect values of OI Mode to be:

0 - Off 1 - Passive 2 - Safe 3 - Full

Maybe you are getting some packet corruption. Can you check the diagnostics topic? If you can connect to the robot with a display (e.g. with a laptop), run create_driver and then run ros2 run rqt_robot_monitor rqt_robot_monitor and check for any warnings or errors. You can install the graphical monitor with sudo apt install ros-foxy-rqt-robot-monitor.

[jacobperron]

Or if you can't run a graphical application, you might be able to get something useful from echoing the diagnostics topic:

ros2 topic echo /diagnostics_agg

[process1183]

Right, I also didn't think mode 4 was valid (and checked the spec.) I didn't see a /diagnostics_agg topic, but there is a plain /diagnostics topic. Here's one of the messages:

---
header:
  stamp:
    sec: 1643684803
    nanosec: 461987635
  frame_id: ''
status:
- level: "\0"
  name: 'create_driver: Battery Status'
  message: Battery is OK
  hardware_id: CREATE_2
  values:
  - key: Charge (Ah)
    value: '1.888'
  - key: Capacity (Ah)
    value: '2.068'
  - key: Temperature (Celsius)
    value: "\x15"
  - key: Current (A)
    value: '-0.111'
  - key: Voltage (V)
    value: '16.028'
  - key: Charging state
    value: Not charging
- level: "\x01"
  name: 'create_driver: Safety Status'
  message: Cliff detected
  hardware_id: CREATE_2
  values:
  - key: Wheeldrop
    value: 'False'
  - key: Cliff
    value: 'True'
- level: "\x01"
  name: 'create_driver: Serial Status'
  message: Corrupt packets detected. If the number of corrupt packets is increasing, data may be unreliable
  hardware_id: CREATE_2
  values:
  - key: Corrupt packets
    value: '8'
  - key: Total packets
    value: '17167'
- level: "\x02"
  name: 'create_driver: Base Mode'
  message: No message was set
  hardware_id: CREATE_2
  values: []
- level: "\0"
  name: 'create_driver: Driver Status'
  message: Maintaining loop frequency
  hardware_id: CREATE_2
  values: []
---

I definitely appear to be getting corrupted packets... I can also try directly attaching my laptop to the Roomba's serial port, as you suggested, and running the create_driver from there.

[process1183]

Ok, so I connected the Roomba 690 to my laptop via a SparkFun Beefy 3 FTDI board and ran ros2 run create_driver create_driver. I got the same behavior as on the RPi- ... Unknown mode (4) detected. However this time I was not seeing any corrupted packets reported in the /diagnostics topic, even after letting it run for a few minutes:

header:
  stamp:
    sec: 1643695114
    nanosec: 364846280
  frame_id: ''
status:
- level: "\0"
  name: 'create_driver: Battery Status'
  message: Battery is OK
  hardware_id: CREATE_2
  values:
  - key: Charge (Ah)
    value: '2.008'
  - key: Capacity (Ah)
    value: '2.068'
  - key: Temperature (Celsius)
    value: "\x10"
  - key: Current (A)
    value: '-0.191'
  - key: Voltage (V)
    value: '15.888'
  - key: Charging state
    value: Not charging
- level: "\0"
  name: 'create_driver: Safety Status'
  message: No safety issues detected
  hardware_id: CREATE_2
  values:
  - key: Wheeldrop
    value: 'False'
  - key: Cliff
    value: 'False'
- level: "\0"
  name: 'create_driver: Serial Status'
  message: Serial connection is good
  hardware_id: CREATE_2
  values:
  - key: Corrupt packets
    value: '0'
  - key: Total packets
    value: '27234'
- level: "\x02"
  name: 'create_driver: Base Mode'
  message: No message was set
  hardware_id: CREATE_2
  values: []
- level: "\0"
  name: 'create_driver: Driver Status'
  message: Maintaining loop frequency
  hardware_id: CREATE_2
  values: []

I also modified a copy of the battery_level example from libcreate to just report the mode, and saw that it reported mode 2 at first, then began reporting mode 4... which is odd. Here's the console output from that experiment:

(ros)josh@tali:~/ws/build/libcreate$ ./mode 
Running driver for Create 2
Connected to robot
robot.getMode() ->  2
robot.setMode(create::MODE_FULL)
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  4
robot.getMode() ->  4
^Crobot.getMode() ->  4

And the modified example (mode.cpp):

#include "create/create.h"
#include <iostream>

int main() {
  // Select robot. Assume Create 2 unless argument says otherwise
  create::RobotModel model = create::RobotModel::CREATE_2;
  std::string port = "/dev/ttyUSB0";
  int baud = 115200;
  std::cout << "Running driver for Create 2" << std::endl;

  // Construct robot object
  create::Create robot(model);

  // Connect to robot
  if (robot.connect(port, baud))
    std::cout << "Connected to robot" << std::endl;
  else {
    std::cout << "Failed to connect to robot on port " << port.c_str() << std::endl;
    return 1;
  }

  std::cout << "robot.getMode() ->  " << robot.getMode() << std::endl;

  // Switch to Full mode
  robot.setMode(create::MODE_FULL);

  std::cout << "robot.setMode(create::MODE_FULL)\nrobot.getMode() ->  " << robot.getMode() << std::endl;

  while (true) {
    std::cout << "robot.getMode() ->  " << robot.getMode() << std::endl;
    usleep(1000000);
  }

  return 0;
}

[jacobperron]

My only other thought at the moment is to try reducing the number of packets being requested in the serial stream, e.g. by commenting out any unused data here:

https://github.com/AutonomyLab/libcreate/blob/1563e2b3e180e55baa5fcc4cef147cb333227a5c/src/data.cpp#L13-L45

Here was the most recent change that adding an additional packet for Create 2 era models (which you could also try reverting): https://github.com/AutonomyLab/libcreate/commit/850b011a55a04d87569d26f6a264b36a5857f33a#diff-009fc4b513f11ceea77f7c4c20a542fa5e707cf8936ace1fd8fdff68ef328915

[jacobperron]

@process1183 When you say you are using "v2.0.0" for libcreate, are you actually using the tag 2.0.0 or the head of master? I would be sure to try the tag and check if the issue persists.

[process1183]

@jacobperron I was using the head of master for libcreate, not the 2.0.0 tag- my apologies for the confusion. I switched to the 2.0.0 tag for libcreate and got some Boost errors during build. I temporarily resolved the Boost problem with:

diff --git a/src/serial.cpp b/src/serial.cpp
index ad9f7fc..63d62dc 100644
--- a/src/serial.cpp
+++ b/src/serial.cpp
@@ -1,5 +1,8 @@
 #include <iostream>

+#include <boost/bind/bind.hpp>
+using namespace boost::placeholders;
+
 #include "create/serial.h"
 #include "create/types.h"

diff --git a/src/serial_query.cpp b/src/serial_query.cpp
index 987cd26..bd54ebb 100644
--- a/src/serial_query.cpp
+++ b/src/serial_query.cpp
@@ -1,5 +1,8 @@
 #include <iostream>

+#include <boost/bind/bind.hpp>
+using namespace boost::placeholders;
+
 #include "create/serial_query.h"
 #include "create/types.h"

However, that lead to problems building the foxy branch of create_robot which I resolved with:

diff --git a/create_driver/src/create_driver.cpp b/create_driver/src/create_driver.cpp
index 545070a..588d94c 100644
--- a/create_driver/src/create_driver.cpp
+++ b/create_driver/src/create_driver.cpp
@@ -72,8 +72,7 @@ CreateDriver::CreateDriver()

   baud_ = declare_parameter<int>("baud", model_.getBaud());

-  // Disable signal handler; let rclcpp handle them
-  robot_ = new create::Create(model_, false);
+  robot_ = new create::Create(model_);

   if (!robot_->connect(dev_, baud_))
   {

I was able to get everything to build using the 2.0.0 tag of libcreate, but I am still seeing the same behavior as as before. I also tweaked the mode.cpp to set and report modes 1-3 (still on the 2.0.0 tag of libcreate.) After setting a mode, the mode reported by getMode() is off by one:

(ros)josh@tali:~/ws/build/libcreate$ ./mode 
Running driver for Create 2
Connected to robot
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.setMode(1)
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.getMode() ->  2
robot.setMode(2)
robot.getMode() ->  3
robot.getMode() ->  3
robot.getMode() ->  3
robot.getMode() ->  3
robot.getMode() ->  3
robot.setMode(3)
robot.getMode() ->  4
robot.getMode() ->  4
robot.getMode() ->  4
robot.getMode() ->  4
robot.getMode() ->  4

The new mode.cpp:

#include "create/create.h"
#include <iostream>

int main() {
  create::RobotModel model = create::RobotModel::CREATE_2;
  std::string port = "/dev/ttyUSB0";
  int baud = 115200;
  std::cout << "Running driver for Create 2" << std::endl;

  // Construct robot object
  create::Create robot(model);

  // Connect to robot
  if (robot.connect(port, baud))
    std::cout << "Connected to robot" << std::endl;
  else {
    std::cout << "Failed to connect to robot on port " << port.c_str() << std::endl;
    return 1;
  }

  for (int i = 0; i < 5; i++) {
    std::cout << "robot.getMode() ->  " << robot.getMode() << std::endl;
    usleep(1000000);
  }

  for (const auto mode : {create::MODE_PASSIVE, create::MODE_SAFE, create::MODE_FULL}) {
    std::cout << "robot.setMode(" << mode << ")" << std::endl;
    robot.setMode(mode);
    usleep(1000000);
    for (int i = 0; i < 5; i++) {
      std::cout << "robot.getMode() ->  " << robot.getMode() << std::endl;
      usleep(1000000);
    }
  }

  return 0;
}

I tried commenting out all but ID_OI_MODE, ID_LEFT_ENC, and ID_RIGHT_ENC in data.cpp and re-running mode.cpp, but still saw the same 'off by one' modes. The 850b011a55a04d87569d26f6a264b36a5857f33a commit is not present on this 2.0.0 tag, so I can't revert that :)

[process1183]

I've done some more digging and I don't think this is a problem with libcreate or create_driver. I attached a logic analyzer to the Roomba's serial port and re-ran the mode.cpp code. After sending opcode 132, the OI mode packet in the sensor stream shows 4. This appears to be a Roomba firmware bug, and is present in fw versions 3.2.47 and 3.5.62 (latest.)

Here's a screenshot of one of the sensor stream packets after sending opcode 132:

[jacobperron]

Do you think it's safe to ignore the bogus mode value? We could add an option to the driver to workaround the firmware bug by either fixing the off-by-one-error or not killing the program if an unexpected mode is received.

[vinnnyr]

I also wonder if we can get iRobot to look into this supposed firmware bug. Should I try to open a support ticket with them? (I can fully appreciate that this is not necc. a support use case :joy: )

[process1183]

@vinnnyr It probably wouldn't hurt to try to get iRobot to look into this possible bug. I have also opened a support ticket with them briefly explaining this issue and linking to this thread.

@jacobperron I think it's safe to add an option to libcreate and create_driver to enable the mode reporting workaround, since the OI Mode reported in the sensor stream is consistently off-by-one. I have added this option to the mode_report_workaround branch in my forks of libcreate and create_robot. ( See commits https://github.com/process1183/libcreate/commit/33066aa1d8f8b34d045d23b53cb9f686c246eaf5 and https://github.com/process1183/create_robot/commit/24b60d784f8073071dbc8540ee6192c7106c78a5 ). Depending on iRobot's response to the support ticket, we can either wait for them to fix the firmware, or I can open a pull request for my workaround option.

[process1183]

Apologies for the long follow-up delay. My initial OI bug ticket was passed to iRobot's Advanced Technical Support Team and one of the team members responded this morning saying, "Our team of developers got back to me informing me that at the moment we don't support the OI spec in the Wi-Fi robots." So the 6xx OI mode reporting bug is unlikely to be fixed.

[jacobperron]

I'm happy to review a pull request with a proposed workaround.