I was able to test the wheel encoders on the wheelchair robot the other night. I had mixed success. The rpm1 and rpm2 status values in mission planner were all over the place. But they were consistently the same magnitude positive or negative:
So something is not right. Talking with the folks on the Ardupilot forum it sounds like I selected an encoder that has too much resolution for the speeds I’m running the motors at.
So to make sure I’ve selected the correct encoders (or to determine which encoders I should have selected) I need to do some math. The encoder I purchased is an E5-900-394-NE-S-H-T-3. It’s rated for 900 counts per revolution of the encoder (CPR).
Maximum Encoder RPM
Encoders have a maximum speed at which they can spin and still accurately measure angular rotation. Per page 4 of the E5 datasheet, an E5 encoder rated for 900CPR can spin at a maximum speed of 20,000RPM.
The encoder is attached to the motor armature shaft, which is in turn connected to a 32:1 gear box. So based on this maximum encoder speed and gear ratio, the fastest corresponding tire rotation speed is:
Connected to a small 12V battery, the tire rotation speed was about 60RPM. Doubling that on the wheel chair robot (it has a 24V power supply) is still well below this maximum speed.
So I am confident the encoder can report rotation measurements accurately. Now whether or not the Pixhawk can read them at the speed it reports them is another story altogether…
Frequency of Pulses
How fast is the encoder sending pulses? Let’s say that the tire on the gear motor rotates at 150RPM. Because it’s a quadrature encoder, you get four pulses for every count. The frequency of pulses is then:
That’s a lot. It’s one every 3.47 microseconds. Can the Pixhawk handle that? I’m not sure.
What distance does the robot travel per encoder count? The diameter of the tire is 10in:
That’s a ton of resolution. Way more than we realistically need. Something in the neighborhood of 0.03in/count is more reasonable.
Pull Up Resistor
Another tip I got from the Ardupilot forum was to use two 10kΩ pull up resistors between the A and B signal pins and the Vcc pin on the encoder. I tried that last night without much success. I also tried to pull the A and B signal pins down to ground, but that didn’t work either. I tried it on the left encoder but not the right to see what the difference would be. The numbers were still all over the place, but they were now slightly different. So there’s that.
I am going to purchase an encoder with 32CPR, which results in 1024 counts per tire revolution, and a resolution of 0.031in/count. Hopefully this will be compatible with the Pixhawk. If the 32CPR encoder still doesn’t work, at least I’ll know the issue is something else.
The rotary encoders arrived today. To familiarize myself with them, I decided to use them to try and determine the gear ratio of my wheelchair gearmotors. The idea is that I can rotate the tire a fixed number of times, read the encoder output and then do some math to figure the gear ratio. I’ll need this number for using the wheel encoders with the Ardupilot software.
Installing this guy was very easy. Peel the cover strip off the adhesive on the back of the encoder and use the conical centering tool to align the base to the shaft. Press it down so it sticks, and then screw everything else into place. Very nice.
The more difficult part is reading the encoder output. To do this I used my old Arduino Uno and did some googling for a sketch that looked close to what I needed (remember I’m a mechanical engineer, not a computer guru). No need to re-invent the wheel, right?
And lo and behold, I found this webpage. And the sketch was pretty much plug and play, short of playing with the baud rates. Not bad for 15 minutes of work!
The encoder I purchased is rated for 900 pulses per revolution. I could have tweaked the sketch so that it measured actual rotations, but I figured I’d just do the math outside of the sketch.
So I taped a pencil to the wheel, hooked it up to a battery and started measuring tire revolutions. After 152 revolutions (measured by aligning the pencil with the motor), the Arduino sketch read 17401196. Dividing that large number by 152 and also by 3600 (it’s a quadrature encoder, so 900 PPR times 4) should give the gear ratio.
The magic number appears to be 31.8. I’m told that gearbox manufacturers like to use strange ratios so that a tooth on one gear doesn’t always contact the same tooth on another gear every revolution. This helps the teeth wear evenly. That’s the only explanation I can think of for this funky number.
I might hook the other encoder up to the output shaft and to get some additional resolution…
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.
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.
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.
As Roby over at Deep South Robotics can tell you, there is a lot of snake oil being peddled in the RTK GPS space. I’ve been a quiet spectator in this area for as long as I’ve been working on the mower project, and I’ve seen a lot of systems come and go.
Two modules that I had my eye on for a long time were SwiftNav’s Piksi V1 and Emlid’s Reach. Both were L1 only systems. I religiously visited their forums and poured over commenter’s experiences with both modules. In a nutshell, here’s what I learned:
L1 only systems can take a long time to get an RTK fix, and they can lose them in a heartbeat
If you’re in the air with a quadcopter or fixed wing plane, an L1 system generally works well because there is no multipath
If you have any kind of multipath that you are contending with, you are absolutely screwed with an L1 system
On top of that, integrating these systems require that master’s degree in computer engineering I talked about earlier (remember, I am a lowly mechanical engineer, wires aren’t really my thing). Neither system is truly plug and play, from what I can tell. A lot of the integration has to do with injecting GPS corrections through telemetry over MAVLink, as I understand it.
Then last year I discovered that u-Blox was coming out with their own L1 system, the NEO-M8P. I watched a very thorough introduction to the module and was almost going to buy one when I noticed that u-Blox was coming out with a multi-band, multi-constellation RTK GNSS receiver, the ZED-F9P.
I contacted the folks out at u-Blox and they said that an evaluation board would be available in Q1 of 2019, but in my research I stumbled across the folks at Ardusimple. These guys are making a similar evaluation board for the ZED-F9P module that includes a Pixhawk GPS port. Talk about simple.
Is this the holy grail of RTK GNSS? From my experience with this board so far, the answer is yes.
A Simple Test
I conducted a test similar to the one in the video I linked to above. I took reported baseline measurements from u-Blox’s u-Center software, converted the NED components to a net distance and then compared the value with a tape measure.
I intentionally placed the receivers in a really crappy area of my yard to see what these modules are capable of. My neighborhood has lots of two story houses, and many fully grown trees, although they are without leaves this time of year which certainly helps. Here’s a panoramic shot of the backyard, with my house to the right:
Bottom line is that this was a pretty challenging multipath environment. I would estimate 50% of the horizon was occluded by my and my neighbor’s house. The remaining areas were pretty well covered up to about 20° if you exclude bare trees. How well did the modules perform?
It’s tough to see in the picture but the NED measures in meters are:
N = -2.1990 E = 0.1063 D = -0.0006
Using the 3D distance formula on these components and converting to inches gives a baseline distance of 86.6759in. You can see in the picture above that the rover antenna is sitting right at 87in. Holy geography Batman indeed!
Some Other Observations
A few other things I noticed in my brief time working with these modules:
The Ardusimple boards have the LED status “backward” from what you’d expect. No corrections means solid blue light, receiving corrections but no fix is blinking blue, and RTK fix is no light. Counter intuitive, but their documentation does mention this.
Just for fun I covered the antenna and waited for the light to turn on, indicating the RTK fix was lost. When I removed my hand, the light would turn back off consistently after less than a second. It appears that if you lose your fix with these modules, you can get it back very quickly, even in a challenging environment.
I kept moving the boards toward the alley between my house and my neighbor’s house, just to see what it would take to force the modules to lose the RTK fix and I was able to get as far as 227in from the base point in the picture above, which was about 3 feet away from my covered patio area before I lost my RTK fix.
Even after I lost the RTK fix, the baseline error was only 12in in 3D float mode. Still really good. Keep in mind during most of this test, I am standing at the laptop taking pictures and fiddling with u-Center. So my body is blocking some signals, too, I’d imagine.
So far these boards are looking awesome! Next step is to hook things up to the Pixhawk.
As I mentioned previously, I need to find a motor manufacturer that posts more than a picture of their product on an electric bike. I need torque curves and CAD models. I am surprised at how few of these manufacturers exist, or at least have websites that I can find. Maybe I just don’t know how to search for them.
Part of the problem is that I’m looking for a motor that has power output on the level of a small riding lawn mower. Finding smaller BLDC motors has been pretty easy, but finding something that operates efficiently at lawn mower speeds while still outputting decent torque has been challenging. Also, it has to cost no more than a few hundred dollars, because I’m cheap and I need some money left over for an RTK GPS module down the road.
So I’m starting out from behind the 8-ball to begin with. I wasn’t sure such a motor existed until I found the folks at Golden Motor. These guys are a little sketchy, and they need to hire a web designer from the 21st century. But they appear to have a wide selection of motors in some pretty epic sizes, with fairly comprehensive performance data, too.
But before we go looking at individual motors, let’s review our requirements.
At the moment I am leaning toward a single mower blade design. I’ve learned the hard way that complexity is not your friend, and simple designs are generally more robust.
To maximize the deck width, I am considering a 30in long blade. A 30in blade needs to rotate no faster than 2400RPM to be safe. Riding mowers with one single 30in cutting blade are equipped with engines that output about 10ft-lbf of torque.
The plan currently is to have four 12V 35Ah sealed lead acid batteries wired in series to power the motor. So it must be rated for 48V.
Evaluating the BLDC-108 Motor
This is a 1500W motor that Golden Motor makes. It’s also the only one that doesn’t have a nice chart for all the relevant performance parameters, but they did give an excel spreadsheet with several data points. I graphed the data and here’s what it looks like.
The efficiency of the motor is greater than 85% between 1 to 3.5ft-lbf torque with a maximum efficiency of 88% at 3325RPM and 2.6ft-lbf torque. The motor consumes about 40A of current at the torque shown on the chart.
To achieve the maximum safe blade rotation speed of 2400RPM, we need to use two pulleys of different diameters on the motor shaft and the blade spindle. Taking the maximum speed the motor operates at of 4072RPM and dividing it by 2400RPM gives us the pulley ratio we’ll need, which in this case is 1.7.
If we use the motor with a pulley ratio of 1.7, we could obtain 5.9ft-lbf of torque at 1800RPM. Reducing the speed increases the torque.
I like that the current draw is only 40A. With four 35Ah batteries, you could in theory get 3.5 hours of operating time, neglecting current consumption from other electronics and motors. I like that number.
The picture on the website is nothing like the CAD model you can download. So that’s something I’ll need to investigate if this is the motor I choose.
The motor is priced at $142 with $60 for shipping. BLDC motors require a separate motor controller, so that will be another $95 with $30 for shipping. So a system built around this motor will cost a total of $327. Not horrible. I wish I knew why the shipping was so high…
This weekend I had some time to install my emergency stop switch. At first I thought I would keep things simple and just mount the emergency stop switch on top of the control enclosure and route one of the battery wires straight through the safety switch. Sounds simple, right? This method, however, presents two big issues:
Hitting the emergency stop switch shuts power off to the entire rover.
A high current carrying wire has to run through the control enclosure.
The first item above is an issue because we want to be able to communicate an emergency shut down state to the ground control laptop. If all the power is shut off to the rover, a power failure and an emergency shut down will appear identical from the ground control’s perspective.
The second item is an issue because it defeats the purpose of separating the power and control electronics. The constraint here is that the emergency stop switch has to be mounted on top of the control enclosure so it is visible, accessible, and in a safe location, but we can’t have a high power wire running through it. We want to keep those noisy high current wires away from sensitive electronics.
The solution? A relay! Or more specifically, a set of relays. We’ll have the emergency switch trigger a relay that cuts power to the drive motors only in an emergency state. We’ll also keep all the high current wires contained to the power enclosure.
The FIT0156 emergency stop switch has two integral switches triggered by the big red button. One is NC and the other is NO. Our system uses the NC switch. When the button is pressed, the switch opens and prevents 5V from flowing to the CH1 and CH2 pins on the relay module. This opens the motor circuit, immobilizing the rover.
The IM120525001 2 channel relay was only $3, but I wasn’t sure if it would be large enough to conduct the current needed by the motors. I decided to take a gamble, and I’m glad I did. The module works very well. The spec sheets say it can conduct up to 30A at 24VDC. The only drawback is that the screw terminals on the module aren’t big enough for 14 gage wire. I had to use 16 gage wire instead.
I measured current flow between the 5V output on the Mauch BEC and VCC on the IM120525001 module and my ammeter said it consumes 170mA, a little bit high for my liking, but manageable. The Mauch BEC is rated for 3A, so it shouldn’t be a big issue.
I oversized both enclosures knowing there would be additional things I add later, and I am glad that I did. The emergency stop switch and relay module both fit nicely in my enclosures.
I used one of my remaining 8 pins on the DB15 breakout board to route the emergency stop switch down to the power box. This wire goes to both the CH1 and Ch2 pins on the relay module. When you hit the button both motor circuits are opened.
So the total cost of our emergency system:
Emergency stop switch, $6
Relay module, $3
Emergency stop sticker, $2
Miscellaneous wire, $1
Tack on a few dollars for shipping and sales tax for those items and you’re still easily under $20. Not too shabby.
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
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:
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.
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 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.