Unknown mode detected #64
Comments
|
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 |
|
+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
<#64 (comment)>,
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 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 |
|
Hi. I have also encountered this issue on a 690 using a RPi ZW and ROS2 Foxy. I am using the I was not able to test |
|
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 |
|
Or if you can't run a graphical application, you might be able to get something useful from echoing the diagnostics topic: |
|
Right, I also didn't think mode 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 |
|
Ok, so I connected the Roomba 690 to my laptop via a SparkFun Beefy 3 FTDI board and ran I also modified a copy of the And the modified example ( #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): AutonomyLab/libcreate@850b011#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 |
|
@jacobperron I was using the head of 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 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 The new #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 |
|
I've done some more digging and I don't think this is a problem with Here's a screenshot of one of the sensor stream packets after sending opcode |
|
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 😂 ) |
|
@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 |
|
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. |
* Add option for OI mode reporting bug workaround AutonomyLab/create_robot#64 * Update README.md * Add note about 600 series OI mode reporting bug to Known Issues section and include details of API workaround option. * Add myself to contributors list
* Add parameter to enable the OI mode reporting bug workaround #64 * Add myself to contributors list
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 detectedbut 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!
The text was updated successfully, but these errors were encountered: