6
$\begingroup$

We are having an issue where after toggling the create 2 from passive to active, then waiting a few seconds and toggling back to passive while on the charger, all serial communication fails a certain percentage of the time. (Links to images of current and serial communication down below illustrating it).

Detail

We are working to have the Create 2 power a NUC, auto-charge and stay alive for long (multi-month) periods of time.

Because we are taking power directly off of the battery (Need higher current), we found that we have to toggle the mode from passive to full and back so that it checks the voltage and goes back from trickle charge to full charging if it has been a few hours and the computer has discharged the battery. This is because the trickle charge algorithm does not check voltage as it assumes the load on the roomba is not high enough to discharge.

We started with it failing this way and have now verified that if we just plug a laptop into the create through the usb serial cable with nothing else plugged in and then toggle passive/full/wait/passive, a percent of the time we also get comm failures without any separate hardware.

Because the create 2 turns off after 5 minutes of no communication, we have tried toggling it every 4 minutes and see that reliably happening, so this is not an issue where the create 2 is just going into sleep mode.

Reproducibility

We are seeing a very repeatable issue where the serial communication (Using current generation USB serial cable from iRobot) loses serial communication with the robot some percentage of the time exactly at the point where it starts charging the robot again. After that, no packets come in from the robot for a long while. Some time later, when we have repeatedly tried to toggle from passive to full and back, communication re-appears.

We have verified this using the ROS stack (create_autonomy) and also by directly echoing characters on the command line echo -e "\x07" > /dev/ttyUSB0 to reset things.

When it is in this state, no software resets work, unplugging and replugging the serial cable does not work, etc. We have to take it off the charger physically (or wait for a long time until our system toggles it again and it does work.

We have verified that this occurs (When the create 2 is on its charger) on:

  • Mac only plugged in over the create cable with no power taken from the system.
  • NUC taking power directly off the battery through a dc/dc converter.
  • NUC taking power off an intermediate battery charging from the create.

Mitigating it

  • We have added ferrite beads on all the cables to mitigate any high frequency noise and that does not seem to solve it either.
  • We have also tried 3 different create cables w/ different serial/usb chips and even built our own from scratch and not fixed it.
  • We have tried separately powered usb hubs, unpowered ones and plugging directly in to the computer.
  • We have tried it on 3 separate create 2's.

I have attached links below with graphs of the output data when it fails. When there is a straight line on current/voltage, that is repeated data, showing that it was stuck and not updating. It always happens right when the system steps up the current to start charging again, so it seems to be linked to a current spike - but only breaks it 1 / 5 or 10 times - it just happens that once broken, it stays that way for a very long time.

Communication fails after multiple successful toggles

Detail showing exactly when communication fails

After many minutes, it is working again

When it has been broken, I have tried turning off our software and addressing the system by echoing data to it directly for OI to turn off, on, reset, etc and do not see communication resume correctly.

If we unplug the roomba from the charger by hand (pull it off), then many times it does work, but not always. If we then reset everything by holding down the buttons, it does seem to work 95% of the time and sometimes we have even had to pull the battery itself to make it work.

If someone has encountered this before, advice would be helpful. We had thought that it was ground loop issues, but given it is on so many different cables, roombas, power situations and compute devices, we are trying to figure out what is fundementally wrong with our setup.

Thanks!

$\endgroup$

3 Answers 3

4
$\begingroup$

There is a bug in the implementation of sleep/wakeup on Create 2 which was fixed in release-3.8.2 for robots with an older processor, or release-stm32-3.7.7 for robots with a newer processor. To receive a code update that will (hopefully) fix your issue, please e-mail [email protected], referencing this post.

Please note that while I'm an iRobot employee, the postings on this site are my own and don't necessarily represent iRobot's positions, strategies, or opinions.

$\endgroup$
3
  • $\begingroup$ Sorry for the trouble; trying to do the right thing and get the information out as efficiently as possible. Do you have a standard for which post to choose to make the "canonical" answer? I also plan to update with fix version numbering once we have a final release; is editing the canonical answer the best way to do that? Once you give me guidance, I will clean things up in the morning US Eastern time. $\endgroup$
    – Steve
    Commented Jul 18, 2018 at 4:20
  • $\begingroup$ I've read both pages and am choosing this post as the canonical answer. I have deleted answers from the other copies, and instead replaced them with a comment either linking to this answer or the one in 12846 . Per "how not to be a spammer," please note that I am an iRobot employee, but the postings on this site are my own and don't necessarily represent iRobot's positions, strategies, or opinions. $\endgroup$
    – Steve
    Commented Jul 18, 2018 at 13:16
  • 1
    $\begingroup$ Hi Mark. Thanks for both the gentle correction and for subsequent confirmation. I will continue to go through my old posts and mark my affiliation where appropriate. $\endgroup$
    – Steve
    Commented Jul 18, 2018 at 13:37
0
$\begingroup$

When the Create 2 gets into the state where you can't communicate with it, have you tried manually pressing the Clean button?

If that reliably works, have you considered adding a relay controlled by the NUC to close those contacts through a direct connection to the Clean button contacts.

An alternative is to add a NUC solenoid or servo with an arm to manually push the Clean button

Frank

$\endgroup$
3
  • $\begingroup$ That is a great thought! We have ordered 2 4 Relay boards and are going to try both disconnecting the battery from the main PCB and the charging contacts from the PCB and see if those successfully trigger it. It looks like the system goes to sleep rather than crashing, and we can reliable turn it on for a second using the BRC pin, but it won't drive off the charger itself. More updates once we have that done! $\endgroup$
    – hcl337
    Commented Apr 20, 2018 at 22:09
  • $\begingroup$ I have also experienced the "one minute windows" when pulsing the BRC where it can accept any command, EXCEPT movement commands. However, during that 1 minute windows, if I send a Reset (7) command, I then have a 5 minute windows to send movement commands and back it off the dock $\endgroup$
    – Faengelm
    Commented Apr 20, 2018 at 23:33
  • $\begingroup$ Even better IMHO is using the relay to toggle the dock charger, which avoids both disassembling the robot and purchasing remotes. All credit goes to raspibo.org/wiki/index.php?title=Roomba_scheduler $\endgroup$ Commented Oct 6, 2021 at 13:08
0
$\begingroup$

I have one more suggestion for you as disassembling the Create 2 to access the Clean button contacts is quite a bit of work.

I purchased a standard Roomba IR Remote and added a relay that the EZB controller can activate. I can happily report that it DOES indeed wake a sleeping trickle charging Roomba on its dock. In fact, it does acts very similar to pushing the Clean button.

By using this technique, you would NOT have to disassemble the Roomba to add a relay across the Clean button contacts. You could clean up this mod by replacing the IR remote with an Arduino board with a IR LED and software.

However, I need to warn you about a couple of non-show stopping issues. The IR remote acts similar to the Clean button but not exactly the same. A short press on the Clean button turns on the green LED and a second short press starts the cleaning cycle. A long press has no effect. Short presses can be used to interrupt and restart the cleaning cycle

On the IR remote, a short pulse (500ms) will do nothing while docked, but a single long pulse (> 1500ms) will start the cleaning cycle. You can interrupt the cleaning cycle and restart the cleaning cycle with short pulses. Long pulses just seem to toggle the green LED.

One more thing… If you choose to stop the cleaning cycle using the OI movement commands from the controller, which is what we really want to do for a telepresence robot, the IR pulses will no longer be able to control the Roomba. If you wish to regain control via IR, you must send a Stop (173) command

You can find some additional details here. http://www.ez-robot.com/Community/Forum/posts.aspx?threadId=10953&page=11

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.