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.

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.

u-Blox ZED-F9P

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:

  1. L1 only systems can take a long time to get an RTK fix, and they can lose them in a heartbeat
  2. If you’re in the air with a quadcopter or fixed wing plane, an L1 system generally works well because there is no multipath
  3. 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.

img_4197
The test setup. The receiver on the left is the base, the on the right near the laptop is the rover. Yes, that is my neighbor’s two story houses in the background.

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:

img_4193
My backyard. The deck where the test was conducted is on 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Lithium Batteries

What would a composite lithium ion battery look like if we were to use one for the mower?

Untitled
What the performance of a hypothetical lithium ion battery could look like if we were to use one.

We need a nominal voltage of 24V, so if you string 7 18650 batteries with a nominal voltage of 3.6V you’d end up with 25.2V, which should work fine.

String 15 sets of those 7 rows of batteries connected in series together and you get a battery with 45Ah of charge. Not too shabby. This would be a 7s15p battery in lithium ion parlance, I think.

Two of those 7s15p batteries would fit in each of our two battery bays. You’d need a total of four to achieve the numbers shown above. They’d fit in our robot something like this:

Lithiums
How the lithium batteries would fit in the battery bays. Very compact. Very expensive.

The weight savings here are significant: 70lb. This is to be expected, but I’m surprised it’s this high. I don’t have a truck to haul this robot around in, so the lighter I can make it, the easier it will be to take it out for field testing. The reduced weight should also decrease the power consumption from the robot’s drive motors, making it more efficient, and possibly more agile.

The cost is still going to be over $1,000 though. Talking with some suppliers, I think the 18650 cells cost a little less than what Amazon will quote you, probably closer to $4.50 per cell. But you still need some fancy charging equipment, and there will be labor and material cost for building up the battery and coming up with a way to secure them in the battery bay.

I may start out using SLA batteries because the monetary risk is pretty low, about $300. They may perform better than I’m expecting. If they don’t, the lithium ion batteries appear to be a good plan B if we need more run time.

Power Consumption

I decided to make the autonomous lawn mower fully electric for one big reason: If a person has to walk out to the mower with a gas can and refill the tank, is it really autonomous?

Ideally, you want the mower to do it’s job without any human intervention. If you have a gas engine, no matter how you cut it fuel has to be delivered to the mower in some fashion. With an electric design, you can have the mower automatically dock with a charging station when the battery gets low. No human required.

So from the get-go I have been trying hard to make the mower electric. I am encouraged by some electric riding mowers out there that use SLA batteries as their power supply. I like SLA batteries because they contain a lot of energy and are fairly cheap. Minimizing battery weight and volume isn’t a huge constraint for this project, thankfully.

Because these electric riding mowers cut grass and carry a ~200lb person on the mower, I have been operating under the assumption that as long as our batteries are larger capacity than those on this riding mower, we should be okay. That Ryobi mower features a battery bank that consists of four 12V, 25Ah SLA batteries.

I am beginning to question that assumption…

Power Consumption

Sizing the batteries ultimately depends on how much power the mower needs. The deck motors take the lion’s share of power consumption. Previously I estimated the mower would require motors that can output at least 5ft-lbf of torque to cut through thick grass based on typical gas engine torque output.

Examining the torque curves for the E30-400 motor I selected for our design shows that at 5ft-lbf or 3.7N-m torque, the motor consumes 1400W of power. If you assume all three motors pull this level of power, the deck motors collectively consume 4200W.

The drive I’m using on the mower design are stolen from the wheel chair. I suspect they are rated for 500W but I am not sure. The gearbox on them ensures they will generally be operating in an efficient area of their torque curves, so I am going to consume both motors consume 250W, and collectively consume 500W between the two motors.

The control electronics are almost negligible compared to the power consumed by the motors, but I will budget 100W for all the other little things on the mower, just to be safe.

That brings the total estimated power the mower needs during operation to 4200W + 500W + 100W = 4800W.

Battery Capacity

The batteries I’ve selected are four 12V, 35Ah SLA batteries. If you assume we intend to discharge these batteries 100% (and that doing so was physically possible), you could obtain (4)(12V)(35Ah) = 1680Wh of energy. If we were to draw 4800W of energy from these batteries, we would drain them in (1680Wh)/(4800W) = 21 minutes. Yikes.

But it gets worse. Because we’re pulling so much power out of these batteries, it looks like you have to discount the total amount of energy you can get out of them. I’m not entirely sure what that calculation looks like, but from the SP12-35 datasheet, it looks like a 1hr discharge rate only allows you to get 21.8Ah of charge out of each battery. That’s only 60% of the 20hr rate of 35Ah. I could be wrong about this interpretation of the datasheet, please correct me if I am mistaken.

Some Thoughts

Do the motors really draw that much power? Holy moly I hope not. At their most efficient, the motors draw 500W of power. Running the calculations above with this number gives you a run time of 48 minutes. Still not great.

The reality is somewhere between those two extremes. Taking the average of the two gives 35 minutes of run time. I was hoping for something more in the neighborhood of 2 or 3 hours. Going up to some 12V, 50Ah batteries could give us some extra oomph, but I don’t think it will be 3 hours of oomph.

Please let me know if these numbers seem way off base, it’s my best swag at them I can come up with. The last thing I want is a mower that can only cut grass for 10 minutes.

 

Vehicle Kinematics

comparison-10-13-18-e1539411077256.png
Some different mower designs. From left to right, a one, two, and three mower blade design.

Picture yourself at your local grocery store. Our grocery store has two kinds of shopping carts: the big one that I grab for loading up 24 packs of Mountain Dew, and the small one I use when the Missus asks me to get a gallon of milk and some cans of soup. The small cart is half the length of the big one.

Which of these two carts is easier to navigate through the store? Or worded more technically, which one has a smaller turning radius? I think you can see where I’m going with this.

All else being equal, a smaller wheel base and foot print is going to be easier to control using our differential drive system. A longer mower is going to swing through a larger radius, and is going to be more difficult to control and position accurately. For a given amount of drive wheel rotation, you will get more angular travel at the front of the mower with a longer wheel base than a smaller one.

specs
Some high level measures for the three configurations. I didn’t design them in order of number of blades, that’s why the designations don’t match.

It turns out that there are other considerations that impact whether one cutting blade is the best choice for our mower design. A single blade mower allows for the most simple blade drive system. But as you can see from the table above, the single blade design is almost 9in longer than either of the other two designs.

The extra length tradeoff needs to be weighed against the simplicity gained by the cutting blade system. There is also a tradeoff between number of blades and cutting width. By going with a single blade design, you lose at least 5in of cutting width compared to a two or three blade design.

Long story short, of the three designs, the single blade is pretty inefficient by some measures. It is the longest of the three, has the smallest cutting width, and requires the most material to fabricate. If I’m going to be successful with the robot lawn mower build, these are serious considerations that need to be taken into account.