Vibration Issues

Before using the robot mower, I always power the blade motors on in my garage for a few minutes to make sure everything is working right. I pulled our vehicles out of the garage, told the missus to expect some loud noises, and made sure that Mr. Mower Jr. was safe inside the house.

The nice thing about the new motor controller I’m using on the blade motors is that I can vary the rotation speed of the blades. So instead of commanding full throttle from the get-go like I had been doing with a relay, I decided to slowly ramp up the speed. It’s pretty incredible listening to the crescendo of the blades as they spool up.

About halfway to full throttle, I started to get a ridiculous amount of vibration. It was extraordinarily loud. The vibration was so intense that it peeled open the eye of one of my deck support eyebolts.

The eyebolt on the turnbuckle supporting the mower deck. The vibration was so intense it peeled it open.

At first, I thought this was just a fluke, or that perhaps the eyebolt was already close to failure, so I replaced it with a spare and repeated the process. I’m not very smart. The result was identical.

When I was in engineering school, I had a choice to take Design of Heat Exchangers or Vibrations and Acoustics for technical electives. As you can probably guess by looking at my mower deck design, I chose Design of Heat Exchangers. It was a fun class, but pretty useless for anything mower related.

So to work through this issue, I’ve had to do some homework. Lucky for me, I managed to stumble upon a copy of Timoshenko’s Vibration Problems in Engineering at the Goodwill a few years ago, which has proven a valuable resource in my vibrations education.

Timoshenko says it better than I can, so I will quote him directly:

By an impulse or sudden application and removal of an external force, vibrations of the [spring mass] system can be produced. Such vibrations are maintained by the elastic force in the spring alone and are called free or natural vibrations.
Vibration Problems in Engineering, page 1

The mower deck is a kind of spring mass system, though geometrically more complex. There is a frequency at which it will vibrate if you were hit it with a hammer, just like a tuning fork will vibrate at 440Hz if you strike it against a hard surface. That unique frequency is called the system’s natural frequency, or frequency of free vibration.

Unfortunately, we’re not just hitting the mower deck with a hammer once. We’re hitting it with a hammer 4800 times per second. That oscillating force does not allow the mower deck to vibrate freely. That’s not free vibration. It’s forced vibration.

In the case of the mower deck, the frequency of that forced vibration is whatever speed the motors are spinning at. Because the motors go from zero to 4800RPM, the mower deck experiences vibration at every frequency along the way. Chances are good that the motors will create forced vibration at the natural frequency of the mower deck at some point as they spool up to operating speed.

A very curious thing happens when you force a structure to vibrate at it’s natural frequency. You get resonance. And the amplitude of vibration becomes very large at resonance. Absent damping it will become infinite. Timoshenko includes a chart that illustrates this phenomenon very well.

Resonance, and the Magnification Factor, from Timoshenko’s Vibration Problems in Engineering, page 42.

When I was spooling up the mower deck motors, I consciously decided to do it slowly to minimize electrical current spikes. This created a problem that didn’t previously exist with the relay, where we rapidly turned on the motors. Timoshenko explains:

The amplitude of vibration [at resonance] increases indefinitely with time… This shows that, while we theoretically obtain infinite amplitude of forced vibration at resonance in the absence of damping, it also takes time to build up these large amplitudes.
Vibration Problems in Engineering, page 48

In other words, if we maintain forced vibration at the natural frequency of a structure, the amplitude of vibration will increase continuously to the extent allowed by any damping present in the system.

By slowly increasing the speed of the motors, I was allowing the mower deck to experience resonance and the accompanying large vibration amplitudes for a period of time long enough to damage the turnbuckle eyes. Who’d have thought?

Something else I noticed was that I had trouble getting the motors to speed up once they were at speeds close to the mower deck’s natural frequency, when it started vibrating really bad. Timoshenko has something interesting to say about that, too:

Experiments show that if any vibrating system is once allowed to reach a steady state just below resonance, it then becomes difficult to accelerate the machine through the resonance condition. Additional power supplied for this purpose is simply used up in increasing the amplitude of vibration rather than the running speed of the machine.
Vibration Problems in Engineering, page 48

I think I have a good grip on what the problem is. Next post I’ll discuss some things that can be done to mitigate this surprising issue.

How Not to Wire Up a Robot

What could have been the ignition source for a Kansas grass fire.

If you look closely at the charts in the previous post, you’ll notice they end quite abruptly. The picture above shows why.

I have the robot mower configured so the blades only turn on when you hold the rudder stick to the right. The stick is spring loaded, so letting go of it returns it to center, deactivating the blades.

A typical shrub out in the field. Most were about 18in tall.

The field I was testing in had several large shrubs in it. One of my goals in the field was to push the envelope on what the mower was capable of cutting through, so I let it mow over several of them in autonomous mode. However, there was a particularly large shrub in the robot’s path, and so I decided to turn the mower blades off by releasing the rudder stick.

As expected, the blades stopped. But the robot stopped moving, too. This was curious: the robot should have continued driving. So I pressed the emergency stop button on the robot to immobilize it, and walked over to the truck where I had Mission Planner running on my laptop.

*A screenshot of Mission Planner telemetry log after I returned to the truck. The reported voltage is 12.50V.*

The Mission Planner screen was frozen as if it wasn’t receiving telemetry from the robot. It took me a few minutes to realize that the issue wasn’t Mission Planner or my laptop radio: it was that the robot wasn’t sending telemetry. And even more curiously, the voltage reading on my SLA batteries said 12.50V. I was worried that I’d really fried my batteries, so I walked back over to the robot to investigate.

Opening the battery bay I found a slight amount of smoke and that awful burnt plastic smell from melted wire insulation. But other than that everything seemed fine. There wasn’t a smoldering fire inside the robot. The batteries weren’t hot to the touch.

At first I chalked it up to too much current running through the wires. The robot uses 120A at peak current, and at those levels even a small amount of resistance could cause the wires to heat up a lot. Perhaps the wires just got hot enough to melt the insulation and came into contact right at the moment I decided to shut the mower blades off?

One of the melted wires. The yellow blob on the end is a portion of a Posi-Lock.

This just so story didn’t sit well with me. What an awful coincidence that the wires failed at exactly the same moment I was shutting off the motors, especially after the robot ran fine for five minutes prior. Why didn’t they fail earlier?

Additionally, why didn’t the exposed wire conductors fuse together after they came into contact? I’ve heard of people using SLA batteries smaller than mine to spot weld 18650 battery tabs together. The wires were really close together, but weren’t touching when I opened the battery bay. And the wire strands don’t seem to be melted judging from the picture above. Which was extraordinarily lucky, given how bad that could have been.

I did have enough sense to put a 100A fuse on my batteries. It seemed logical that the fuse was what saved my bacon. But using the multimeter to test the fuse revealed that it was not, in fact, blown. At this point I was completely bewildered. I thanked the good Lord that the robot hadn’t turned into a massive lead acid fireball, made sure all my batteries were all disconnected, packed up, and went home.

I’m sure readers are ready to scold me for all of the janky things going on in my battery bay, and I certainly deserve that criticism. My mantra is make it robust, and I definitely did not live up to that standard with my wiring. Below is a full picture of the battery bay.

The robot mower battery bay. How many janky things can you spot?

I have my own list of janky things in here that I intend to fix. What do you see that is janky? Feel free to comment below!

In the next post, I’ll explain what I think went wrong, and the improvements I’m going to make to mitigate the problem and eliminate all the redneck wiring I’ve got going on.

Rotary Encoder Troubleshooting

I’ve managed to fry three rotary encoders on the left motor now. The first one was when I discovered the issue. The second one was when I switched the left and right encoders to try and see if the issue was specific the encoder or something else. And the third one was a spare 900CPR encoder I plugged in just to see if it would work.

When I write computer code, I’m pretty cavalier about testing it. If I get an error, I just go back to the code and tweak it. The computer typically doesn’t go up in smoke if I forget a parenthesis or colon.

On the robot lawn mower, however, there are consequences for this kind risk taking. Installing a new encoder in a scenario where I’ve just watched one get fried is, well, pretty stupid. The results are predictable.

Because they’re not particularly cheap, I decided it would be best to sit down and figure out exactly why the encoders keep breaking. To summarize the symptoms:

Only the encoder on the left motor breaks. The encoder on the right motor works fine.
After installing a new encoder on the left motor, it will work fine for a while, but eventually stops working.
When an encoder fails, it will oscillate around the zero point by a few counts. It still outputs data, it’s just really crappy data.

After installing the encoders and building the drive motor assemblies, I bench tested the encoders. I wanted to make sure I caught any issues before I installed them on the mower. They worked great at the time, but I only applied 12V to the motors. They receive 24V the way they’re wired in the robot lawn mower.

So my initial hypothesis was that perhaps the current sent through the motor wires was inducing current in the adjacent encoder wires. Maybe at 12V it’s not enough to matter, but with 24V, it causes an issue. The maximum current rating for the E5 encoders I’m using is 85mA, not much. But if this were the case, you would think the same issue would present itself on the right motor. They’re wired identically, but the right motor works just fine. So that can’t be the problem.

After tracing my wire runs and verifying everything worked, I was at a loss as to what was causing the issue. So I took apart the motor to see if something weird was going on inside.

Encoder signal sires inside the cap of the motor housing. No wonder I kept frying encoders. The purple wire was to the A input of the encoder.

Well, a nicked signal wire could definitely cause an issue.

The two brass extrusions on the left and right side of the picture are for seating the motor brushes. With all the exposed, energized metal in this area it wouldn’t surprise me if the wire made contact with something and fried the encoder.

I’m guessing I pinched the wire when I installed the cap. It’s pretty tight in there and you kind of have to hammer it into place. You’d have no idea something got pinched until, well, the encoders stopped working.

After replacing the encoder wires and rebuilding the motor, I used the 900CPR encoder to make sure things were working. So far so good. Hopefully I’m done buying rotary encoders for a while.

The Prototype Robot Lawn Mower

I was able to take the prototype robot lawn mower out for a drive this week. Watching the design drive off the computer screen and into my backyard has been immensely satisfying. Below are my notes from a day spent becoming better acquainted with the robot mower.

Vehicle Handling

Initially I wired the RC receiver straight into the Sabertooth so I could take it out for a drive. I’d forgotten how much smoothing the Ardupilot software adds to the control output. The robot was almost too responsive without it.

But overall, it handled wonderfully. I was almost able to drive up the curb from my street into my yard, but there wasn’t enough traction to get the back wheels up the curb. So far, so good!

However…

A scenario I hadn’t considered when I designed the robot mower.

After I got the Pixhawk wired up (more on that below) I ran a few autonomous missions and started tuning the steering and throttle PID values. At lower steering turn rates, I noticed the swivel caster wheels sometimes catch on the grass instead of swiveling, and the whole setup actually rotates about the center pin. The scenario in the picture above only occurred once, but I noticed the wheels getting hung up more than once.

When I was putting the robot together, I noticed the casters weren’t fabricated per my print. I had designed them with more offset between the wheel axle and the swivel axis. If this continues to be a problem, I’ll have them remade with a little extra offset so they swivel easier.

Wires

Getting the robot wired correctly was nerve wracking. I made a wiring diagram for the power enclosure and modeled up all the components and connections to make sure they fit, but I skipped this planning step for the Pixhawk enclosure. The amount of wires I had to route to the Pixhawk multiplied quickly:

5 wires from the drive wheel rotary encoders, a total of 10 for both motors.
4 Sabertooth control wires.
4 relay control wires.
6 wires for the Pixhawk power port.
2 emergency stop wires.
2 additional wires to power the servo rail on the Pixhawk.

I wasn’t expecting 23 wires needing to be routed to the Pixhawk enclosure, and making sure I didn’t get something wired incorrectly was nerve wracking.

And ultimately, I did wire something incorrectly. When I first powered the robot on, nothing happened, other than the Mauch BEC getting hot. And that’s never a good sign.

Turns out I had incorrectly wired the servo rail by swapping the + and – wires. Yikes. I eventually discovered the issue and fixed it, but not before learning a lot about the LM2576 voltage regulator I incorrectly thought was the issue.

Wheel Encoders

After I fixed the wiring, everything seemed to work, until I started running autonomous missions and had trouble getting the MAVLink Inspector within Mission Planner to show wheel encoder data. Initially I couldn’t even find the wheel encoder message. But after a few reboots it magically appeared. Not sure why it wasn’t visible from the start.

From the get-go, only the right wheel encoder was working. Below is WENC.Dist0 for the encoder on the left motor and WENC.Dist1 for the encoder on the right motor.

kind of bad encoder — Wheel encoder total distance traveled as measured from the right and left wheel encoders. Note that WENC.Dist1 is 0.

And below is what the graph for the right encoder by itself, WENC.Dist1 versus time, looks like.

bad left encoder — The right encoder odometry data. Having watched the robot move around my backyard, I know this can’t be correct.

So to troubleshoot, I swapped the encoders. The idea is that WENC.Dist0 should look like the graph above and WENC.Dist1 should look like more like the first graph, with values much greater than 10E-6 and gradually increasing. This would isolate the issue to the encoder and not a settings, wiring, or Pixhawk error.

As an aside, having posted that graph I’m now wondering if the negative value means I have the A and B wires swapped. I was driving the robot forward mostly, so I would expect the values to be increasing, not decreasing. Regardless, at least the left encoder is obviously outputting some kind of useful data.

After swapping the encoders…

bad encoder — The WENC.Dist0 and WENC.Dist1 values after swapping the encoders.

Great, now they’re both broken!

I decided to call it quits after this because the sun was going down. I took the robot back into the garage and got the Arduino out to see what it said about the encoder output. Unfortunately it confirmed that the left encoder at a minimum was broken. The Arduino sketch counted pulses and only got up to 1 or 2 regardless of how much the wheel was rotating.

I remembered I had some 900CPR encoders I had purchased a while back and decided to see if I could get them to work with the Pixhawk. So I swapped the 32 CPR encoder with the 900 CPR encoder, and lo and behold, it started to work again.

All I can gather is that I must have fried one or both of the encoders with my wiring shenanigans. But it concerns me that one of the encoders was working at the start of the day and stopped working by the end of the day.

More to come once I get the mower deck assembled and installed. You can find a brief video of the rover doing an autonomous mission in my backyard here.

It’s the Wires, Dummy

After doing some reading this week, I discovered a few additional ways to check if the encoders are working properly:

Use the Analog Input pins on the Arduino to see what voltage the encoder outputs on high and low signals. It will give an idea of what the voltage is across a range of rotation speeds.
Use a potentiometer as a pullup or pulldown resistor to bring the high signal higher or the low signal lower if they end up not being high enough. This lets you determine a good resistance value to use.

Checking the encoder signal voltage with the Arduino revealed that the low signal was 0.00V, and the high signal was in the neighborhood of 4.38 to 4.71V depending on the speed the encoder rotates at. I would expect this out of two $60 encoders, and it’s in line with the datasheet, although a little lower than the advertised 4.5V. So I don’t see any need to use pullup resistors to differentiate between the high and low outputs.

So taking a step back, the encoder symptoms are:

When both left and right wheels rotate in the same direction at a static speed of ~90RPM, the rpm1 and rpm2 values in Mission Planner randomly oscillate between positive and negative numbers, but roughly equal in magnitude.
Rotating one wheel by itself causes both rpm1 and rpm2 values to oscillate around zero RPM.
Both encoders function normally when plugged into the Arduino.

Come to think about it, if the A and B signals are cross wired, that would cause the behavior described above. You’d be sending the A signal from two separate encoders into the A and B inputs on the Pixhawk, which would explain the random positive and negative switches, and the otherwise random magnitude RPM values I was seeing. Quadrature encoders work by measuring a predictable state change in the A and B channels, and cross wiring the A signal output on encoder 1 with the B signal input would cause chaos.

But I always wire everything right the first time, so it can’t be that. No sir. Gotta be some really obscure with the hardware issue, or a problem with the Ardupilot code. Sarcasm, in case that wasn’t apparent.

Well after checking both of those issues, it turns out there was a wiring issue. I had the encoders wired through the power enclosure and then up into the control enclosure through the DB15 cable into the Pixhawk. Lots of places that wiring can be done incorrectly. And I had the A wire on encoder 1 cross wired into the B input for encoder 2. I need to start taking my own advice about troubleshooting.

After swapping wires, things worked wonderfully. In fact, after doing some brief autonomous testing in my backyard I decided to take the wheelchair robot up to the parking lot for some more thorough testing. I’ll have a writeup on that soon.

The Culprit

The dual channel relay module. The module features two 30VDC, 10A relays soldered to the board. Each relay can be triggered independently with 5V applied to the appropriate header.

It appears the root cause of the right motor not responding at all to RC input was actually a lot simpler than I imagined. I should have caught it early, and the fact I didn’t is a little embarrassing.

Mission planner usually says that the motors are drawing approximately 5A to 7A so I generally assumed the motors weren’t under that much load. I am now questioning those readings given the damage to the board, shown below.

I remember checking the relay board after one of the motors stopped working, but I was relying on the LEDs to confirm the relay was triggering properly. This was the wrong way to check the board, because the LEDs light up when 5V is applied to the header pins, not when the relay actually closes.

I also seem to recall hearing the relay “click” when triggered, but because the wire trace in the board was burnt up, no current could flow through the board, whether the relay was engaged or not. Because the back of the board was hidden and I couldn’t see the burnt up wire trace, I assumed the relays were good and moved on. I’ll check the module later, but the relays probably still work fine.

Lessons Learned

My Mission Planner current readings are probably wrong.

I don’t think I have the current sensor calibrated or configured properly. Either that, or mission planner does some kind of smoothing of current measurements that doesn’t reveal maximum current flow, only the average over the measurement period. The Mission planner output is total current consumed by the robot, meaning 7A is used for everything. This shouldn’t have caused a problem, in theory. Obviously, there is a disconnect between reality and theory somewhere.

You get what you pay for.

This relay board was $3 plus shipping. The header pins were a nice setup, and the fact that the relays could be triggered with 5V is the main reason I bought them. I had a convenient 5V source to switch them with, so I tried to keep things simple. Unfortunately the board was undersized for the task, as you can even see heat damage to the conductor that isn’t completely split. I should have known there was a problem when I couldn’t fit 12ga wire into the screw terminals on the board and had to use 16ga wire instead. Not good.

Fuses are critical for protecting components and preventing fire.

I’ve been skeptical of going to the trouble of putting fuses in my robot, partly from a cost perspective but mostly from an “ain’t nobody got time fo dat” mentality. This failure could have been a more critical component. If the relay board hadn’t failed, I could have fried the Sabertooth, or worse, started a fire in the enclosure. While I’ve focused my safety efforts on the spinning blades, this is an equally important area to get right.

Remember Occam’s Razor when troubleshooting.

When one motor spins but the other one doesn’t, which is more likely:

The Sabertooth motor controller is fried, but only halfway fried.
There’s a connectivity problem to the motor that doesn’t turn.

Taking a step back to asses the problem can save a lot of useless troubleshooting, like tearing the Sabertooth out and testing it. Use common sense. Start checking the simplest failure modes first, moving to more complicated failure modes until the root cause is found.

Going Forward

To switch current to the motor controller I am going to add a much larger 50A relay to this system. I’ll then use one of these smaller boards to switch the 50A relay. The coil current consumed by the 50A relay should be much lower than the current consumed by the drive motors on the robot.

Setbacks

Running the wheelchair robot in autonomous mode has been a lot of fun. Seeing it come back to waypoints pretty much dead nuts to the same spot is very satisfying. So I’ve become a little complacent with keeping my hand on the “manual mode” button in mission planner in case the robot veers off toward something it shouldn’t.

And boy did I pay for it today. Remember that sprinkler well in my backyard? Well the robot seemed to remember it too, and I may be buying a new power switch for it this spring. I took my eyes off the robot for just a few seconds and boom, collision.

The rover V2 running to waypoints autonomously.

Normally this wouldn’t be too frustrating except for the fact that now the left motor doesn’t rotate at all. The right motor though still runs perfectly.

So I start to troubleshoot the problem using the following process:

I made sure the motor still works. I connected the motor wires to the battery terminals and it spooled up just fine. No problem.
I checked continuity across the motor wires to the relays and Sabertooth motor controller. Everything is connected. No problem.
I checked the relays to make sure they weren’t broken, they function as desired. No problem.
I checked the fuses on the motors. Not blown. No problem.
I swap the S1 and S2 wires on the Sabertooth, thinking this would eliminate the Sabertooth as the issue if the left motor suddenly worked and the right motor didn’t. No change, the right motor still responds to RC input, although in a funky way because S1 and S2 are switched. The left motor is still unresponsive. Might be the Sabertooth.
I removed the Pixhawk from the equation by hooking the Sabertooth up to RC input from the receiver directly. Same results, left motor still unresponsive, right motor works.
I also checked continuity across the DB15 cable between enclosures. Everything seems to be connected. No problem.

So from my cursory testing, the Sabertooth seems to have been bricked, at least on the left motor side. So I pull it from the enclosure and take it inside for bench testing.

The bench setup for checking the Sabertooth. The battery and motor come from an old cordless weed eater. Very handy for this sort of thing.

But after some simple testing, both left and right motor outputs work when hooked up! So what could the issue be?

I’m thinking something got knocked loose during the collision. Nothing else makes sense. I’ll take everything apart and rebuild it just to make sure, but the lack of a smoking gun is somewhat worrisome.

Field Testing

I had several objectives during field testing:

Get the rover tuned properly, and see if there is any strange autonomous behavior like weaving, jerking, etc.
Familiarize myself with planning autonomous missions in Mission Planner. I was specifically interested in seeing how to autogenerate waypoints.
See how well the GPS blending reports position. I was interested in both absolute and relative accuracy, but really just wanted to get a feel for things at this point.

To start, I took the rover V2 out in my backyard and got it to run autonomously, but my backyard isn’t very big. I have lots of tall trees in my neighborhood, too, so GPS signal reception wasn’t great either.

The rover V2 running to waypoints autonomously. I managed to avoid crashing into my sprinkler well the whole afternoon!

I would estimate position accuracy relative to the satellite map data was +/-3m. Not horrible, but not great, either. Throughout the afternoon position would drift slightly, I would estimate +/-1m.

I had the rover run an autonomous mission of 20 waypoints positioned in a circle several times to test repeatability. I did this close to 10 times over the course of an hour, and each time the rover took a slightly different path, as evidenced by the track marks in the grass. Sometimes the rover would go on the left side of my sprinkler well, other times to the right. Not very repeatable, but this was a somewhat challenging GPS environment.

So knowing that things were at least configured somewhat correctly I decided to take the rover V2 out to a large parking lot with a good view of the sky. In Kansas, those aren’t too hard to find. I chose a parking lot way out of town, with newly painted stripes that showed up on the satellite imagery so that I could have a good measure of relative accuracy.

The rover weighs something close to 100lb, so I had to take the batteries off of the chassis and remove both of the control boxes. I brought my tool box with me to help reassemble the rover and I also made sure my laptop was charged, but I forgot to bring a few things. If you’re ever out field testing, a checklist is a really good idea. Here’s mine for the next time I go out:

Cell phone with cellular data
AA batteries for the RC transmitter
Make sure rover batteries are sufficiently charged
The toolbox with hex wrenches, adjustable wrench, and screwdrivers
Multimeter
Laptop with a good battery charge
Telemetry radio for the laptop
SD card, installed in the Pixhawk

I asked my very supportive wife to go with me, thinking she would bring her phone and that I could use it as a wireless hotspot to download Mission Planner map data. I forgot to explicitly ask her to bring it, which was a huge mistake because this was the one time she decided to leave her phone at home. And I’m too cheap to have a data plan, so I was depending on her. We had a good laugh about it when we realized she’d left it at home.

So while I was able to do some autonomous missions, I was unable to compare the position data to the parking stripes on the satellite map. I could zoom in, but the ~300 car parking lot was reduced to 6 pixels in Mission Planner.

So without any good imagery, I took the rover manually around the parking lot perimeter to demarcate the edges and then planned some missions. The first ones were circular, and then I did some square ones, and some random ones.

IMG_3862_Moment — The rover V2 in the parking lot.

Overall, I felt like the rover was tuned perfectly. I had a few odd shimmies here and there, but I didn’t spend too much time trying to find the cause. They weren’t debilitating, just noticeable. Seeing the rover run autonomously without toilet bowling was very satisfying given my rover V1 experience.

So field testing was only a partial success. I felt like the rover was tuned really well with just the default settings, so that was a win. But I wasn’t able to get a good feel for GPS positioning accuracy or repeatability. I did get to spend some time familiarizing myself with Mission Planner.

An observation about field testing that may be specific to Kansas: Wind stinks. The laptop almost blew off the hood of my car while I was in the parking lot. I set up shop in the trunk of my car where I was sheltered from the wind a little, but I noticed this affected my radio range somewhat. I had the rover more than 500ft from my car at some points, and much past that things got spotty. In the future I’ll choose a calmer day for field testing.

Another observation: Kansas is flat. Very flat. When the rover got more than 200ft or so away from me distance to obstacles becomes very difficult to judge (especially with no satellite map). I hopped a few curbs in manual mode, but the rover V2 handled it like a champ.

Overall I’d say it was a 1.5 out of 3. We’ll bring a good cell phone and choose a calmer day next time.

Getting the Wheels to Turn the Right Way

One of the painful experiences I had on rover V1 was getting the motors to turn the correct way. It sounds simple enough, but there are several different variables that control motor rotation direction and behavior:

Motor wiring polarity. How you connect the two wire leads on the motor into the Sabertooth motor controller affects rotation direction.
DIP switches on the Sabertooth motor controller. There are 6 on-off switches on the Sabertooth that determines how it interprets RC input from the Pixhawk.
Servo output from the Pixhawk. There are 8 servo outputs on the Pixhawk. These must be assigned to the correct output function.
PPM encoder wiring. My RC receiver has 6 RC outputs, but there is only one RC input on the Pixhawk. I use a PPM encoder to mix the six channels into one. Depending on the wiring configuration into the PPM encoder affects which RC channel gets associated with yaw, roll, pitch, etc.
Mission Planner servo reversing. You can reverse the RC input in Mission Planner.
Skid Steer settings. This rover turns by varying the rotation speed of the left and right motors relative to each other. There are a settings related to this behavior.
RC mapping. Which stick on the RC transmitter should control throttle or steering? There’s settings for that, too.

Pretty straightforward, right? This post is for my own personal recollection of this process in case I lose my settings or have to rebuild the rover for some reason. But hopefully I can also shed some light on how to wade through this mess of options and get your rover behaving as desired.

Step 1: Put your rover up on chocks

Seriously, get those wheels off the ground. We’re doing this exercise because the wheels don’t turn the right way. In the wise words of Robby, “your shins will thank you“.

Step 2: Preliminary Wiring

You gotta start somewhere, so don’t worry too much about getting all the wires set up correctly on the first try. Something is going to be backwards or configured incorrectly in Mission Planner. Here’s my checklist for preliminary wiring:

RC receiver is plugged into the RC slot of the Pixhawk servo rail.
Channels 1 and 3 of the Pixhawk output have servo wire running to the RC input terminal block on the Sabertooth (these are the defaults in Mission Planner).
Motors are wired into the motor output terminals on the Sabertooth.
Batteries and BEC are all wired appropriately.

Double check your wiring to make sure your battery or BEC is wired properly and with the rover on chocks, turn on the power.

Step 3: Sabertooth DIP switches

Dimension Engineering has an excellent wizard to help you get your DIP switches configured properly. You’ll obviously need to select what’s appropriate for your situation, but for mine I selected the following:

Lead acid battery chemistry
Simulated RC signal
Independent mode
Exponential control

Regarding (4), you could probably do linear control too, this is a preferential thing I think. The rest of these settings are mandatory as far as I can tell.

The bottom line here is that we want the Pixhawk to mix the steering and throttle signals for skid steering, not the Sabertooth. I’m pretty sure this is why (3) above is set to independent mode. If it wasn’t, you’d have the Pixhawk mixing the signals, and then the Sabertooth mixing them again. Quite the mess, I’d imagine. Probably one of the many things that went wrong on rover V1.

This should result in the following DIP switch configuration:

Sabertooth DIP Switch Settings — The DIP switch settings I used on the Sabertooth 2X60. Switches 2 and 3 are on, the rest are off.

Step 4: Ensure Your Motors Are Responsive

Flip on the RC transmitter, arm the Pixhawk with the push button switch, and move the sticks around. The motors should at least respond to RC input on the transmitter, even if it seems completely jacked up. If not, go back to step 2 and check your wiring. Motors kicking straight into high gear with the sticks in the neutral position shouldn’t be unexpected at this point. This is also why step 1 is very important.

Step 5: Tweak Some Mission Planner Settings

According to the Ardurover documentation, you’ll want to set the following parameters in Mission Planner:

SERVO1_FUNCTION = 73 (This sets servo 1 output to left motor throttle)
SERVO3_FUNCTION = 74 (This sets servo 3 output to right motor throttle)

In recent versions of Ardurover I think this is all you need to do to enable skid steering. As always, refer to the most recent documentation.

Step 6: Get your RC transmitter mapped correctly

Decide how you want your RC transmitter to control your rover. I have an airplane style transmitter and so I wanted steering and throttle both on the right hand stick. There were a few reasons for this:

When you release the stick it returns to the center neutral position, which will stop the rover.
You can go forward and reverse on this stick. The left stick zero position is all the way down as it’s supposed to be throttle for an airplane, so there’s no way to go in reverse if you assign throttle to this stick.
I can control the rover with one hand and use my left hand for something else.

You’ll want to assign throttle and steering to your desired stick motions in Mission Planner using the RC mapping parameters. In my case you’d go with the Ardurover default:

RCMAP_ROLL = 1
RCMAP_PITCH = 3

This sets your roll and pitch transmitter signals to your the appropriate Pixhawk output.

Step 7: For PPM Encoder Users…

So you cheaped out when buying your RC transmitter? You’re among good company. Your setup will probably look something like this:

ppm — The RC receiver is at the bottom. The PPM encoder as at the top.

PPM encoder users have another layer where they can improperly assign RC channels. Roll might be channel 1 on the transmitter and properly assigned on the servo output of the Pixhawk, but PPM encoder users will need to make sure that Mission Planner shows the Pixhawk as interpreting roll as channel 1.

Pull up the radio RC transmitter configuration page under Initial Setup in Mission Planner and verify that the RC mapping is correct. If it isn’t, you’ll need to fiddle with the way the PPM encoder is wired so that the channels map across.

Step 8: Play With Settings

Now you’ll want to watch the motors as you move the RC transmitter sticks. Forward should obviously cause both motors to rotate in the same direction. Right should cause the motors to counter rotate; same thing with moving the stick to the left. Make sure you check all stick positions so that there’s no funky-ness with the full range of motion.

Are the motors still doing something strange? Now is when you can adjust the motor wire lead polarity. Hopefully you can identify one motor that is behaving opposite how it should. If this is the case, flip the motor wires on that motor and see how this affects things.

Step 9: Document Everything

Did you get it working? Save those parameters. And take pictures of everything, the Sabertooth DIP switch settings, the wire runs, the PPM wiring. Everything. Better yet, take a video of it while you explain verbally what you did to get it to work. You’ll thank yourself later.

Still having trouble? Did you reverse any servos? I thought that servo reversing would be a good idea to get things to work, but I really advise against it. You might get things configured to where your rover does run correctly in manual mode, but when it comes time to throw it in auto, that servo reversing can make things very weird. best to switch wires around instead in my opinion. Get everything configured in the hardware and leave the software at the default settings.

One last word about Mission Planner settings: don’t push buttons. Normally I like to push buttons until something works, but Ardupilot is one of those situations where it really doesn’t help and usually makes things worse.

There are literally hundreds of parameters to play with, and even if all of the settings I’ve described here are correct, there could be a phantom parameter somewhere you tweaked that is messing with your setup. If you didn’t heed this advice you may be better off resetting the parameters to their default.

Step 10: Field Testing!

But that’s for another post. Stay tuned!