Open rwayong opened 4 years ago
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!).
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
@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?
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?
+1, same "unknown mode detected" error on 675, running melodic on jetson nano
+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.
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 :/
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
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?
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: @.***>
@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.
Note, the issue is likely coming from libcreate
, so playing around with the version of that package might be good to try.
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!
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
.
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
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.
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;
}
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:
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
@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.
@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 :)
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
:
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.
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: )
@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.
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.
I'm happy to review a pull request with a proposed workaround.
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 runroslaunch ca_driver create_2.launch
, it gives me an error as below and my roomba freezes. I'm running create_autonomy on ROS kinetic.I really hope you can help me with this error. Thanks!