Encoder Math

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:

RPM1 and RPM2
Reported RPM values for the left and right motors.

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:

max tire speed
The maximum rotation speed of the tire on the gear motor for a given maximum encoder rotation speed.

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:

pulses at 150rpm
The number of pulses in one second if the tire on the gear motor rotates at 150RPM.

That’s a lot. It’s one every 3.47 microseconds. Can the Pixhawk handle that? I’m not sure.

Resolution

What distance does the robot travel per encoder count? The diameter of the tire is 10in:

travel per count
The distance the tire travels after one encoder count.

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.

Going Forward

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.

Correction: The Magic Number is Exactly 32

Because the ratio I measured a few days ago was a strange non-integer ratio, I decided to open up the gearbox and count teeth. It was frustratingly messy, to say the least.

IMG_4381
Inside the wheelchair motor gear box. Lots of grease! This was after I had taken out about 80% of all the grease.

I was hoping to be able to count the number of teeth on each gear without taking the whole thing apart, but this proved quite difficult. There’s not really a good way to mark a tooth when the whole thing is swimming in grease.

After a while, I decided to sit down and do some math. It was a flashback to my old engineering school days. I was able to count the teeth on some of the gears (with a fair degree of confidence) and using this information, the problem statement became:

A gearbox has a gear ratio of 31.8. There are four gears in the box. The output gear has 32 teeth. The gear connected to the output gear has 11 teeth. A second gear with an unknown amount of teeth is rigidly attached to the same shaft as the gear with 11 teeth. This gear is then driven by a worm gear connected to the motor. How many teeth are on the second gear?

With most word problems, I find myself drawing pictures to make things more clear. I made a simple CAD model of this setup to try and get a better grip on how the gears worked together.

gear model
A simple model of the gears in the gear box. The left gear has the output shaft with the tire on it, and the lower right cylinder represents the worm gear attached to the motor.

Assign a letter to each gear in the system. The gear on the output shaft is A, the gear meshing with it is B, the gear on the same shaft is C, and the worm gear in the lower right is D.

The total ratio is the ratio between A and B times the ratio between B and C times C. Remember, one revolution of a worm gear will advance the corresponding spur gear one tooth, or 1 divided by the number of teeth on the gear. Putting it all together:

Untitled
The composite gear ratio for the wheelchair gearbox.

Wait a minute… that’s just a fancy way of saying the gear ratio is A, or the number of teeth on the output shaft gear. That can’t be right. Or can it?

Remember we measured the gear ratio at 31.8. I did some more estimating and came up with a number closer to 31.9 by counting more tire revolutions (320, or so I thought), but because I can’t exactly line the tire up in the same spot it started from, there was always going to be a little error in the calculation.

And come to think of it, the more tire rotations I counted, the closer my estimation came to 32 exactly. To come up with the 31.8 number I counted 159 revolutions. I was off by one tire rotation. And to come up with the 31.93 number I counted 639 rotations, which meant I was off by about 1.25 tire rotations. Turns out I’m not very good at counting.

At this point you might be wondering why I didn’t use the other encoder to measure the gear ratio with much higher precision (and without all the mess). The output shaft on the gearbox is 17mm diameter, but I mistakenly thought it was 8.5mm. I misread the radius measure in my CAD program and thought it was a diameter measure instead. You can jury rig a 10m ID encoder to fit on an 8.5mm shaft, but not a 17mm shaft. 

Long story short, I like to do things the hard way, and the magic number is actually 32. Exactly 32.

The Magic Number is 31.8

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.

IMG_4373
The rotary encoder mounted to the wheelchair motor.

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.

IMG_4374
The setup for measuring the wheelchair gearmotor gear ratio. The encoder and Arduino are measuring input shaft revolutions and I’m measuring tire revolutions with my eyes.

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…

Spring is Here!

It’s been a while since I’ve posted, but that doesn’t mean I haven’t been busy. The back yard is starting to really green up and I think the worst of the cold is finally behind us here in Kansas.

IMG_4337
The backyard on this fine spring morning. Winter is finally over!

I purchased a replacement relay board for the one that went bad several of weeks ago. Unfortunately, I didn’t read the fine print and the new relay board requires you to ground the appropriate pin instead of applying 5V to it in order to trigger the relay.

Since I’m now using a high current relay to switch the Sabertooth, I decided to resolder the damaged terminals on the relay board and put it back in the enclosure to switch the high current relay. I’ve taken the wheel chair robot out and tested it, and it is working quite well.

The RTK GPS system is working great, but unfortunately my backyard is still a very challenging environment to work in. Maintaining an RTK fix for 50% of the time is about all I can do. Because of this, I am exploring two different improvements to the wheel chair robot.

Optical Flow

For the uninitiated, optical flow is the concept that modern computer mice use to measure the motion of the mouse. An integrated circuit with a built in “camera” takes rapid (500Hz-ish) pictures. The pictures are very low resolution, 16 bit grayscale or thereabouts, and really small, like 32 pixels square. Using math, the vector difference between each frame is computed, and if you know how far above the surface you are you can then estimate your translation.

The same concept can be applied to our robot wheelchair. Take a camera, point it at the ground, measure how far the camera is above the ground and voilà! With some creative coding, you can estimate your robot’s translation. Optical flow is great because it measures your vehicle’s absolution translation, not some intermediate measure like wheel turns or integrating accelerations to back into your position.

What’s really cool is the Ardupilot code already features optical flow! There’s only one catch… it’s currently only implemented for copter. So for the time being, I’m going to have to either bribe a genius on the internet to port the code to Ardurover, or I’ll have to do it myself. I’ve started playing with the Ardupilot code, but let’s be real. I have no clue what I’m doing.

Wheel Encoders

This is a feature that is already implemented in the Ardurover code. I’m thinking about buying some rotary optical encoders to leverage this feature. For ~$140 I can get two encoders and pretty much plug and play them into my motors.

encoder on motor
The wheel encoders mounted where the brake used to be on the motor. Fits like a mitten!

To properly implement them, I need to figure out the gear ratio on the gear box. I measured it by counting turns of the back shaft on the motor per one wheel rotation and came up with a ratio of  32:1. I thought this was an odd ratio (I was expecting 30:1 or 60:1) so I did some digging and it turns out there’s a little bit more going on in that box than I initially suspected.

To measure the gear ratio, I could just use the encoders and hook them up to an Arduino, measure several wheel rotations and then see how many pulses I get out of the encoder, so I’m not going to bust open the gearbox and start counting teeth. In theory though, this would be the correct way to determine the exact gear ratio.

Some things I’m not sure about:

  1. How much wheel slip is acceptable before the encoders actually start degrading position estimation instead of improving it? Wet grass isn’t nearly as friendly as concrete.
  2. How many pulses per revolution (PPR) do I realistically need? Not much is my guess, but if the Pixhawk can read them, the more the merrier. Where’s the sweet spot?
  3. The wheel encoders help if you can continue to get good absolute positioning information from the RTK GPS. But they’re only as good as your initial position, and you’ll quickly start experiencing drift once you lose your RTK fix. How long can the wheel encoders tide you over between RTK fixes?

For ~$140, I think I’ll take the risk and see how well they work.

The Culprit

IMG_4307
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.

IMG_4308
The bottom of damaged relay board.

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:

  1. The Sabertooth motor controller is fried, but only halfway fried.
  2. 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.

Weather

Weather in Kansas during February can be pretty awful, and this year is no exception. We’ve had a lot of snow lately, and the temperatures have been 30’s or lower on the days that I could take the robot wheelchair out for some more testing.

A few months ago I listed some goals I had for the robot mower prototype. I’ve made progress toward some, and overall I feel pretty good about where I’m at for now. Here’s an update of the progress.

Prototype Robot Mower Design

robot-mower-03-03-19.png
The robot mower design as of this evening.

The robot mower design is about 70% finished. I am working on getting the wires modeled in my CAD software currently, and this has been time consuming but I know it will pay off down the road.

I need to revisit how I’m attaching the mower blade to the motor shaft. I had considered using some cheap QD pulley bushings because they have a nice keyway in them that matches the motor shaft and holes that would mount easily to the blade, but I’m not sure this is the best way to do things.

I wish I could find these bushings without the split in them. I’m not sure they make them that way. The split makes me worry that it will be difficult to get good clamping force around the shaft. Also, nothing but a set screw keeps the key and bushing clamped up against the shaft. Because the motor is mounted vertically, all heck could break loose if the set screw loosens up. The bushing could conceivably slide off the shaft while spinning at stupid high RPMs. Not good.

At any rate, CAD work is about the only thing I can work on when there’s 4 inches of snow on the ground outside.

Sourcing Weldments

I’ve been very disappointed with some of the local weld shops I’ve sent drawings to for quote. I live in an industrial town and there are lots of mom and pop shops that I figured would jump at the chance to pick up a small job like mine. I’ve received 5 no bid quotes so far, and haven’t heard back from 3 other shops. Very frustrating.

I tried one of those online weld shops and they quoted the mower deck at $4,500. That’s definitely not in the budget, and I know this weldment is worth no more than several hundred dollars. If you can weld 0.125in thick aluminum sheet metal, leave a comment and I’ll send you over some drawings and maybe we can make a deal.

Purchased Parts

I’ve purchased one of the E30-400 motors to evaluate, but haven’t had time to play with it yet. It’s a lot smaller than I expected. I hope to do a write up on it here in the next few weeks.

I also purchased some high current automotive relays for switching power to the deck motors. The wheelchair design has all of the current running through a 20A switch which in hindsight is a really crappy design. It works for the wheel chair, but to power three 50A motors requires a better solution.

RTK GPS Integration

The Ardusimple RTK GPS boards are working far better than I expected. There’s really very little integration left to do. I will try to take the wheelchair robot out to a large parking lot here when the weather warms up to get a better idea of it’s performance in a decent GPS environment. I’m very excited to see how it does without a ton of trees and buildings around. Its performance so far has been pretty awesome.

Rebuilding the Wheel Chair Robot

I haven’t rebuilt the wheel chair robot yet in light of our crash a few weeks ago. This is also on my to do list. Hopefully we’ll have a chance to do that this next weekend. It’s really hard to get motivated work on a lawn mower robot when it’s 20 degrees outside and there’s snow on the ground.

New Goals

Because RTK GPS integration isn’t going to take nearly as long as I anticipated, I need to spend more effort on getting the robot constructed, under budget and by May if possible. I may try some weld shops in surrounding towns, or possibly the old Craigslist method where I just post drawings and see who replies.

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.

IMG_3854
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:

  1. I made sure the motor still works. I connected the motor wires to the battery terminals and it spooled up just fine. No problem.
  2. I checked continuity across the motor wires to the relays and Sabertooth motor controller. Everything is connected. No problem.
  3. I checked the relays to make sure they weren’t broken, they function as desired. No problem.
  4. I checked the fuses on the motors. Not blown. No problem.
  5. 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.
  6. 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.
  7. 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.

IMG_4264
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.