hits counter

Robomower part 11 - On motors and their control...

Something awful has happened to the Robomower! In an attempt to start getting my side yard under control for an upcoming patio project, the bot got high-centered on a dirt bump. The wheels were spinning frantically in a valiant attempt to un-stick themselves, but succeeded only in churning up a gigantic cloud of dust. Naturally, I stopped everything and walked over to manually free the poor thing. When I tried to send it off on a more reasonable task, I discovered, to my horror, that something was terribly, horribly wrong. One motor would spin, but only backward. the other motor was controllable as normal, but ONLY if the first motor was running in full reverse! Needless to say, this wasn’t what I was after.

The first step was to narrow down exactly what component or components had failed. By switching around the leads from the BR6000, I was able to quickly determine that it was the Sabertooth that had failed. (as an aside, I also discovered a neat little undocumented feature of the DX5e transmitter: the spring-loaded trainer switch on the top left will actually drive a sixth channel! Pretty cool, huh?)

I sent an email to Dimension Engineering, the manufacturer of the Sabertooth, and included a detailed description of what had happened, and what steps I had taken to troubleshoot. The reply, which came VERY quickly was that, based on my description the controller had “popped a channel”. The tech support guy also said that I should send the unit back for repair or replacement at no charge, other than the cost of shipping it to them. That was more than I was expecting, and I am impressed!

The controller was shipped off shortly thereafter, and now I am left with a robot with no motor controller. This means that I am basically in possession of a pile of non-moving parts roughly shaped like the Robomower. Bummer. Meanwhile, I have had a brief on-line conversation with none other than J.D. Warren, author of the original Instructable and Make Magazine article that inspired this whole project. As the gentle reader may recall from an earlier post in this series, J.D. is using a motor controller board of his own design. I looked at that part of the project, and ended up deciding that getting spun up on making my own PC boards was more than I was interested in tackling at that time. Well, it’s later now, and I’m feeling braver, and although it was really nice of Dimension Engineering to stand behind their product, I’m still out a controller until such time as they send it back to me. I can’t help but think that it would be a lot quicker for me to fix something that I built, even if it involves waiting for more parts to arrive. I have also found what looks initially like a workaround for one of the two major stumbling blocks that I found with the current process of home-brewing PC boards: My complete lack of a laser printer. Turns out the UPS store 2 locks from my house can make photocopies, and on Saturdays they’re only 5 cents apiece. The photocopier uses the same (or nearly the same) toner that a laser printer would, so I can print my design out on my inkjet, then just make a copy for toner transfer. I think I’ll be testing this for viability real soon now, so watch for some posts on that topic!

Also, with the Sabertooth down for the count at the moment, I’ve had a chance to do some more thinking about just how I want this thing to be controlled. The tank steering as it is currently implemented is a little “squirrelly”, especially when doing things like mowing near raised garden beds, and around trees. The solution, as I see it, is to run the RC signal through the Arduino, and see if a small level of processing can actually help smooth things out. I’m currently envisioning reducing the sensitivity around the middle of the stick travel on both channels, or possibly even doing some minor mixing of the steering signals, just to keep things under control. This also means that I will have to seriously revamp the current Arduino sketch: right now I am using a simple pulsein() function, which is fine if I am only using the Arduino to process a single input. To go beyond that, I’ll need to use interrupts. The version of the Arduino that I am using has two hardware interrupts, which are very well supported by the Arduino IDE. For anything more than the two channels, though, I’ll need to look into using pin change interrupts (PCI), which have a much less clear path to usefulness, as well as being potentially more susceptible to noise and lost signal pulses. Of course, if I use them for something with less critical timing demands, such as the mower attachment, or a rotating beacon, or even a nylon line-based trimmer, then I’ll probably be fine.

There is a lot of good code and support out there for this kind of project, so I’m making it a goal to at least get the Arduino inserted between the RC receiver and the motor controller when it comes back.

2 comments to Robomower part 11 – On motors and their control…

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>