Dual port usage of RoboClaw
92 views
Skip to first unread message
Michael Wimble
Jun 20, 2022, 8:55:31 PM6/20/22
to hbrob...@googlegroups.com
My mid-size robot, Puck, uses a RoboClaw controller because of the richness of the API and ease of use, sort of.
My main processor talks to the RoboClaw using the USB interface. This allows adequately fast communication, though the vendor provided driver and the hardware itself, with a Linux system, often results in communication failure. To fix that, as I’ve mentioned in the past, I wrote my own driver, which is very similar to the vendor’s, but better handles the USB communication problems.
The big feature I rely on is a motor command that allows me to tell each motor the desired speed, the acceleration ramp, and the maximum distance allowed before automatically stopping the motors. This is one of the safety systems of the robot. The maximum distance allowed is computed from the commanded velocity and the expected number of motor commands per second. As you know, the normal way ROS works is the robot is expected to send cmd_vel requests many times a second. Say, at least 10 commands per second to achieve smoother motor movement. So, if anything in the software chain that computes where the robot show go should fail, the motor driver should shut down the motors after seeing, say, a tenth of a second with no new commands coming in, not just keep executing the last request over and over.
Likewise, when motors start up with high velocity or shut down quickly, huge EMF pulses happen in the motor windings which can damage the motor over time, and also huge power pulses can be sent out of the motors back to your hardware which can fry your components. So, having the ability to ramp up the velocity and ramp it back down does a lot of good for your robot, beyond minimizing the physical shock that all your robot components get from jerky movement.
A failure mode of the RoboClaw, though, shows up if the encoder signals are not delivered to the board as expected. This can happen when the connectors from the encoders simple work their way off from vibration on the robot. When the encoders don’t signal properly, the RoboClaw often goes into high speed motor spin. Since the RoboClaw doesn’t yet detect this condition and enter a safe mode, it’s up to me to detect this.
Since this is such a dangerous mode, I don’t want to rely on a single detection method if I can avoid it. Sure, the motor driver I wrote is constantly reading the encoder values sent via the RoboClaw in order to compute wheel odometry. But it’s possible that the USB connection fails. In fact, it happens all too often, which is why I wrote my own driver.
So I (want to) take advantage of the ability of the RoboClaw to have multiple communications going on at the same time. Specifically, while the USB port is talking to the main processor in my robot, receiving speed/distance/acceleration commands from the robot and sending back status like power supply voltages, motor currents and wheel encoder values, my custom processor board can simultaneously ask for RoboClaw status via a UART serial port. If the main processor detects runaway, it should send a stop command or an emergency stop signal. If the custom processor also detects runaway, it can send an emergency stop and, if that doesn’t fix the problem, it can actually disconnect the power to the RoboClaw.
There is a gotcha in all of this, if one of you wants to use this double-safety system. Whenever a command is sent to the RoboClaw (I’m omitting the few exceptions here), it usually aborts whatever command it was already working on. So if my main processor is sending motor movement commands and my custom processor ask for, say, the encoder values, the motor aborts the motor movement command begins to stop.
I’m still working out a method to make this two-port communication to work smoothly, but I’ve just started working on it.
My main processor talks to the RoboClaw using the USB interface. This allows adequately fast communication, though the vendor provided driver and the hardware itself, with a Linux system, often results in communication failure. To fix that, as I’ve mentioned in the past, I wrote my own driver, which is very similar to the vendor’s, but better handles the USB communication problems.
The big feature I rely on is a motor command that allows me to tell each motor the desired speed, the acceleration ramp, and the maximum distance allowed before automatically stopping the motors. This is one of the safety systems of the robot. The maximum distance allowed is computed from the commanded velocity and the expected number of motor commands per second. As you know, the normal way ROS works is the robot is expected to send cmd_vel requests many times a second. Say, at least 10 commands per second to achieve smoother motor movement. So, if anything in the software chain that computes where the robot show go should fail, the motor driver should shut down the motors after seeing, say, a tenth of a second with no new commands coming in, not just keep executing the last request over and over.
Likewise, when motors start up with high velocity or shut down quickly, huge EMF pulses happen in the motor windings which can damage the motor over time, and also huge power pulses can be sent out of the motors back to your hardware which can fry your components. So, having the ability to ramp up the velocity and ramp it back down does a lot of good for your robot, beyond minimizing the physical shock that all your robot components get from jerky movement.
A failure mode of the RoboClaw, though, shows up if the encoder signals are not delivered to the board as expected. This can happen when the connectors from the encoders simple work their way off from vibration on the robot. When the encoders don’t signal properly, the RoboClaw often goes into high speed motor spin. Since the RoboClaw doesn’t yet detect this condition and enter a safe mode, it’s up to me to detect this.
Since this is such a dangerous mode, I don’t want to rely on a single detection method if I can avoid it. Sure, the motor driver I wrote is constantly reading the encoder values sent via the RoboClaw in order to compute wheel odometry. But it’s possible that the USB connection fails. In fact, it happens all too often, which is why I wrote my own driver.
So I (want to) take advantage of the ability of the RoboClaw to have multiple communications going on at the same time. Specifically, while the USB port is talking to the main processor in my robot, receiving speed/distance/acceleration commands from the robot and sending back status like power supply voltages, motor currents and wheel encoder values, my custom processor board can simultaneously ask for RoboClaw status via a UART serial port. If the main processor detects runaway, it should send a stop command or an emergency stop signal. If the custom processor also detects runaway, it can send an emergency stop and, if that doesn’t fix the problem, it can actually disconnect the power to the RoboClaw.
There is a gotcha in all of this, if one of you wants to use this double-safety system. Whenever a command is sent to the RoboClaw (I’m omitting the few exceptions here), it usually aborts whatever command it was already working on. So if my main processor is sending motor movement commands and my custom processor ask for, say, the encoder values, the motor aborts the motor movement command begins to stop.
I’m still working out a method to make this two-port communication to work smoothly, but I’ve just started working on it.
Sergei Grichine
Jun 23, 2022, 9:45:17 AM6/23/22
to hbrob...@googlegroups.com
Wow, that's a lot of planning and good engineering; I'll make a note for my designs. Thanks for sharing!
The "runaway something (motors)" problem has two sides - how you detect the condition and how you deal with it. One can be as inventive with the detection as hardware and imagination permits, but as for dealing with it - it has to be as simple and reliable as possible. A "dead man's switch" on jet skies and lawnmowers shows brute force approach to it. I'd guess having a battery disconnect relay for all motors and an independently working "safety monitor" microcontroller (with its own power and self-test) would be a good approach.
On my lawn mower I tapped into the dead man's switch connector, replacing its seat part with a plastic tab. When the tab is pulled out, the mower's ignition circuitry is interrupted and the 22Hp engine stops, which in essence emulates "man falling" condition (well, the man is actually sitting at the laptop in the shade, watching the ground station screen). The tab is pulled by a 12V gear motor, connected to a 433MHz receiver relay, and to a 12V Lipo battery. There is a switch that allows me to test the radio with the motor wire switched to a LED. Whole safety system is completely independent from the robot system. The catch, of course, is how fast I can reach that little button on the transmitter... :-)
One more "safety feature" I use in my power servos (those which move lawn mower levers and gas engine throttle). If a servo doesn't reach its set point in 3 seconds, I command the H-bridge to "feather" the motor - cut off current and not try applying any force at all. The next change in the set point will resume the attempt. So far, that worked well and all my servo motors and H-bridges are good.
--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/0DB65DFE-E975-40C8-8DD6-39BB5FB8F62A%40gmail.com.
Best Regards,
-- Sergei
James H Phelan
Jun 23, 2022, 9:20:39 PM6/23/22
to hbrob...@googlegroups.com
I used something like this in the NASA/JPL Open Source Rover to cut off all power.
A better solution would be to just off just power to the motor/servo controllers
or to ground the e-stop pin of the RoboClaw motor controllers.
During early testing best to have a "Range Safety Officer" as
with NASA launches whose only job is to abort the mission in case
of dangerous malfunction.
James H Phelan "Nihil est sine ratione cur potius sit quam non sit" Leibniz "Here am I, the servent of the Lord; let it be with me, according to your Word" Luke 1:38
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVO5wG7dATnp%3DL8jeiHnk1utFpZt-p2TcrOQGXOsdWa0NA%40mail.gmail.com.
Michael Wimble
Jun 23, 2022, 10:38:26 PM6/23/22
to hbrob...@googlegroups.com
In my opinion, systems the can cause damage or harm should operate in a fail safe mode, which mine does not yet. The emergency stop should be wired so it is asserted until safety checks assert the robot is ready to run. Power to the motor controller should be be default disabled until safety checks assert that the motors are operating in a safe state.
Currently, my systems come up in a permissive role. Sometime soon I will fix that. I may have to add a relay shorting circuit (with appropriate diodes) so that if any of my (currently) three power supplies fail, the motors are removed from control of the motor controller and the windings are shorted with a low-resistance, high wattage resistor.
Ralph Gnauck
Jun 24, 2022, 1:04:50 PM6/24/22
to hbrob...@googlegroups.com
Mike,
I have found the runaway problem to be caused by using the built-in USB port on the roboclaws. I avoid this at all costs (ok for one time setup, but not for driving the robot).
I have always used a separate USB->Serial Adapter (FTDI etc) and use the serial IO pins on the roboclaw.
I think the internal USB driver in the robocall is buggy or susceptible to noise, so I don't use it.
I have always used a separate USB->Serial Adapter (FTDI etc) and use the serial IO pins on the roboclaw.
I think the internal USB driver in the robocall is buggy or susceptible to noise, so I don't use it.
Ralph
--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit
Chris Albertson
Jun 24, 2022, 1:18:46 PM6/24/22
to hbrob...@googlegroups.com
In the world of machine tools, like CNC milling machines, the emergency stop of "E-Stop" is disabled by a positive voltage on a wire grounding or cutting the wire removes the voltage and asserts e-stop and stops the machine. Typically the e-stop switch is closed in normal operation and hitting the big red switch opens the circuit.
Also, this way if the top wire comes loose or is cut the voltage drops to zero and the machine stops. NEVER use positive voltage to signal an emergency.
Of, course, most of our robots are too small to do any harm. The e-stop I have is on my milling machine.
--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/44C95EDE-2941-4F76-A950-C0052C8FF631%40gmail.com.
Chris Albertson
Redondo Beach, California
Michael Wimble
Jun 24, 2022, 1:40:25 PM6/24/22
to hbrob...@googlegroups.com
Thanks. At the moment that wouldn’t work for me since I’m using the UART port as a second monitor to the RoboClaw. I may run some experiments and, if I can duplicate the USB problem, will change my architecture to use only the serial port.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/1559161021.8432316.1656090284948%40mail.yahoo.com.
Sampsa Ranta
Jun 26, 2022, 4:09:45 PM6/26/22
to hbrob...@googlegroups.com
Remember the ground loops / noise with power controller stuff might not be fun.
Serial and USB can be isolated in case you suspect something like this. These have small internal isolated DC/DC converters.
Serial gadget example
USB gadget example
- Sampsa
Finland
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/96A4BAD2-568D-43A3-80A9-5E52555D2A2A%40gmail.com.
Michael Wimble
Jun 26, 2022, 6:51:02 PM6/26/22
to hbrob...@googlegroups.com
Thanks. I hadn’t really looked at ground loop possibilities.
Sampsa Ranta
Jun 26, 2022, 10:22:16 PM6/26/22
to hbrob...@googlegroups.com
As you mentioned back EMF.. This is usually proportional to motor speed. And it's usually fed back to power rails with diodes. Motor battery can take this, but communication references at 3.3/5v can take more local impact.
I don't say I am expert on the domain. But if 15 USD gadget in middle happens to solve the problem you might get decent payback instead of trying to debug that complex problem domain. And best is you can just keep the workaround there if you dont happen solve this. If it does not solve problem, you know the problem is somewhere else.
Also if you have more motor controllers, the spikes might accumulate.
Some MCU allow simple optical isolators on RX/TX, but the ones I mentioned were easy to use examples.
For further USB digging, try google "linux usbmon" if you suspect protocol level might give you something.
Just random thoughts, hope this helps any..
-Sampsa
--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/EBA1C8EF-AFDF-410D-B785-86D7608E1AA0%40gmail.com.
Reply all
Reply to author
Forward
0 new messages