Skip to content

Unknown mode detected #64

Open
Open
Unknown mode detected#64
Labels
bugquestion

Description

@rwayong
rwayong
opened on Jan 7, 2020

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!

Activity

  1. jacobperron commented on Feb 10, 2021

    @jacobperron
    jacobperron
    on Feb 10, 2021
    Member

    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!).

  2. jacobperron
    closed this as completedon Feb 10, 2021

  3. GrobaxGrappleBlast commented on Mar 16, 2021

    @GrobaxGrappleBlast
    GrobaxGrappleBlast
    on Mar 16, 2021

    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

  4. jacobperron commented on Mar 16, 2021

    @jacobperron
    jacobperron
    on Mar 16, 2021
    Member

    @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?

  5. jacobperron
    reopened this on Mar 16, 2021
  6. jacobperron
    changed the title [-]Destruct sequence initiated[/-] [+]Unknown mode detected[/+] on Mar 16, 2021

  7. vinnnyr commented on May 22, 2021

    @vinnnyr
    vinnnyr
    on May 22, 2021
    Contributor

    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?

  8. jacobperron
    added
    bug
    question
    on Sep 29, 2021

  9. hypertechnic commented on Oct 14, 2021

    @hypertechnic
    hypertechnic
    on Oct 14, 2021

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

  10. blaine141 commented on Nov 12, 2021

    @blaine141
    blaine141
    on Nov 12, 2021

    +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.

  11. eddiem3 commented on Jan 15, 2022

    @eddiem3
    eddiem3
    on Jan 15, 2022

    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 :/

  12. blaine141 commented on Jan 15, 2022

    @blaine141
    blaine141
    on Jan 15, 2022

    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

  13. eddiem3 commented on Jan 15, 2022

    @eddiem3
    eddiem3
    on Jan 15, 2022

    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?

  14. blaine141 commented on Jan 15, 2022

    @blaine141
    blaine141
    on Jan 15, 2022 via email

  15. 5 remaining items

  16. process1183 commented on Feb 1, 2022

    @process1183
    process1183
    on Feb 1, 2022
    Contributor

    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.

  17. process1183 commented on Feb 1, 2022

    @process1183
    process1183
    on Feb 1, 2022
    Contributor

    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;
}

  18. jacobperron commented on Feb 1, 2022

    @jacobperron
    jacobperron
    on Feb 1, 2022
    Member

    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): AutonomyLab/libcreate@850b011#diff-009fc4b513f11ceea77f7c4c20a542fa5e707cf8936ace1fd8fdff68ef328915

  19. jacobperron commented on Feb 1, 2022

    @jacobperron
    jacobperron
    on Feb 1, 2022
    Member

    @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.

  20. process1183 commented on Feb 2, 2022

    @process1183
    process1183
    on Feb 2, 2022
    Contributor

    @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 :)

  21. process1183 commented on Feb 6, 2022

    @process1183
    process1183
    on Feb 6, 2022
    Contributor

    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:
    roomba_690_uart_cap

  22. jacobperron commented on Feb 15, 2022

    @jacobperron
    jacobperron
    on Feb 15, 2022
    Member

    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.

  23. vinnnyr commented on Feb 16, 2022

    @vinnnyr
    vinnnyr
    on Feb 16, 2022
    Contributor

    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 😂 )

  24. process1183
    added 2 commits that reference this issue on Feb 17, 2022

    Add option for OI mode reporting bug workaround

    33066aa

    Add parameter to enable the OI mode reporting bug workaround

    24b60d7

  25. process1183 commented on Feb 17, 2022

    @process1183
    process1183
    on Feb 17, 2022
    Contributor

    @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 process1183/libcreate@33066aa and process1183@24b60d7 ). 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.

  26. process1183 commented on Mar 29, 2022

    @process1183
    process1183
    on Mar 29, 2022
    Contributor

    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.

  27. jacobperron commented on Apr 1, 2022

    @jacobperron
    jacobperron
    on Apr 1, 2022
    Member

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

  28. jacobperron
    added a commit that references this issue on Apr 7, 2022

    Mode report workaround (#67)

    e99939c
  29. jacobperron
    added a commit that references this issue on Apr 26, 2022

    Add parameter to enable the OI mode reporting bug workaround (#95)

    0f4e957
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugquestion

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions