Wiring Improvements

I’ve spent most of this winter re-wiring the robot mower. In hindsight, I should have spent a lot more time planning the wire runs. I made a lot of design choices about how the chassis should look and where enclosures should be located that are inappropriate given my more complete understanding of how the wires need to be connected between components.

At some point you have to build something that’s not perfect and work through the bugs later. It’s against my nature to operate that way, but if I hadn’t started building the robot mower in reality at some point, it would still be a picture in my CAD program.

In the rest of this post, I’ll describe some wiring related improvements I’ve been making to the robot mower.

The original power enclosure. The phrase “rat’s nest” comes to mind.

The picture above is how the power enclosure used to look. It used to contain the Sabertooth 2X60, the voltage/current sensor, the BEC, a positive and negative terminal stud, a small 5V relay board to trigger two larger 50A relays, a power switch and an XLR charging port. It was a mess, to say the least.

The reorganized power enclosure. No relays or terminal studs, just two motor controllers and a BEC.

The reorganized enclosure contains the Sabertooth 2X60, the BEC, power switch, XLR charger port, and a motor controller for the deck motors exclusively.

The reason I tried to pack so many components into the power enclosure was so I didn’t have to put anything other than wires in the battery bay. It is a battery bay, after all. I was hoping to make an entirely modular power enclosure I could build up separately from the robot and then basically bolt on.

While that’s nice in the CAD software, in reality it didn’t work. If I’d selected a larger enclosure it might have been possible. But an unintended side effect of putting everything in one enclosure is that you have to run 24V and ground into the enclosure, but you then turn right around and run a ton of wires right back out of the enclosure.

As I have learned, relays are not a great way to control motors, especially if they’re using a lot of power. And on top of that, those “200A” relays were kind of a scam. They terminals are only rated for 50A, and I’m pretty sure I managed to fry one out in the field. I decided to replace them with a single channel motor controller that can supply up to 200A of current.

The nice thing about having a motor controller driving the deck motors is that I can dial back the blade speed if the mower is cutting the grass just fine. There’s no sense in running at 4800RPM when 3600RPM will do the job. I’m hoping this will allow the robot mower to run for a longer period of time.

I was using wire nuts to connect all of the deck motor wires together originally. I wanted to make things a little more professional than that, so I decided to replace the wire nuts with a fuse block.

In theory, the deck motors should only use about ~30A each at steady state, and with the new motor controller, I think I can spool them up slow enough to where a fuse doesn’t blow. We’ll see how good this assumption is soon.

One thing I like about the fuse block is it allows me to easily disconnect power from the deck motors: just pull the fuses. This makes safe troubleshooting easier. The fuses will also provide a layer of protection for the motor controller. But at the same time, a blown fuse creates exactly the situation that caused my wire failure. I intend to also have a Zener diode between the supply terminal and ground to hopefully protect against this situation, too.

Components relocate into the battery bay. From left to right, there’s an RC controlled relay board, a solenoid, the voltage/current sensor, and a master fuse block.

All of the power in the robot now runs through a MEGA fuse, and from there it runs through the voltage/current sensor. After that, it runs through a solenoid, which supplies power to the drive and deck motor controllers. The solenoid can only be powered if the E-stop switch and RC relay board are in safe states.

I also put rubber boots on every exposed terminal, including the batteries. They look a little ridiculous on that solenoid, but they are adequately insulated.

The RC relay board is controlled by a switch on the RC transmitter. If the RC relay board doesn’t detect a valid RC signal, it will open the relay. This allows me to have a remote E-stop switch.

One thing I don’t like about this RC relay board: when you power it on, it automatically closes for a second, then goes open. That’s a really crappy design, in my opinion. But without the Pixhawk armed it’s kind of a moot point.

A proper ground plane for the GNSS antennas. The foil to the left was what was underneath the RTK GNSS receiver previously.

I also finally got around to putting a proper ground plane under my GNSS antennas. We’ll see how much this improves performance.

I hope to have these wiring improvements wrapped up soon. The grass is green and growing out here in Kansas!

Inductive Kickback

I’ve learned a lot about the behavior of DC motors from the book Introduction to Mechatronic Design. Much of what I will discuss in this post comes from chapter 20 of this book. Electrical engineers reading this post will laugh at how elementary some of this information is, but it was news to me as a mechanical engineer.

I find that I solidify my understanding of ideas and concepts by writing about them. So what follows is a brief book report on a phenomena often called inductive kickback, which I believe was the cause of the wiring failure on my robot.

A motor is an inductor. Inductors store energy in magnetic fields. When you apply voltage to a motor, a magnetic field is created around the motor. A unique characteristic of inductors is that they resist changes in the flow of electricity through them.

If you were to suddenly disconnect the voltage source, the magnetic field would try to keep electricity flowing through the motor. But because there is no where for that electricity to go, the voltage across the motor terminals increases instead. And it can increase to very high levels, sometimes thousands of volts.

A typical graph of Inductive kickback voltage from Introduction to Mechatronic Design.

The energy stored in the motor’s magnetic field has to go somewhere. What usually happens is the voltage becomes high enough across the motor terminals that a nearby component becomes a target for electricity to arc through and flow out of the motor.

I didn’t state it in my previous post, but to power on the deck motors I’m using a large relay. To turn them off you have to open the relay, and you end up creating exactly the inductive kickback situation described above. And with nowhere for electricity to flow, I think the voltage between some of my wires became so large that it arced through the insulation.

What could have been the ignition source for a Kansas grass fire, save for my 100A fuse.

The damaged wires in the picture above are the + voltage wire on the motors and a battery ground wire, curiously enough. And notice how close they are to each other: a perfect place for electricity to arc. Better than the contacts inside the relay, which was still functional, surprisingly.

I now know why wires are voltage rated: it has nothing to do with the conductor material or size, and everything to do with the insulation. The insulation will only prevent arcing below a certain voltage threshold. And in the field several weeks ago, it looks like I greatly exceeded that threshold, whatever it was for those wires.

I checked the Posi-Lock website, and their connectors are rated for 600V. I don’t remember where I got my wire from. I’m sure it was the cheapest knock-off stuff I could find. The insulation has no identifying marks, so I’m not sure it’s voltage rated at all.

Next post I’ll describe the changes I’m going to make to robustify the wiring and electrical components in the robot mower.

A Poor Man’s RTK Base Station

I may not be able to afford a Emlid Reach RS2, but I’ve got a cordless drill and an Amazon Prime account, dang it!

Putting my RTK base station on the mailbox works pretty good, but it takes a while to set it up and it’s not very robust. Using it in this manner results in a few problems:

The cell phone battery pack that I use to power to the receiver turns off after a while. I’m not sure if this is because the receiver only draws ~120mA of current and it doesn’t detect the receiver, or if it just times out. Either way, it’s quite annoying to discover the reason I can’t get an RTK fix or float is because the base station isn’t even on.
The neighbors getting their mail usually block enough satellite signals to cause the receiver to lose an RTK fix. Cars driving down the street will often affect the quality of reception, too. Unfortunately, I can’t pick up the mailbox and move it to a more favorable location.
The receiver and antenna are exposed to the elements. While I usually use them in good weather, I would like to be able to use them without having to worry about risking damage to the units from rain, wind, and the Kansas critters.
When I’m out testing in the parking lot there’s not an equivalent of my mailbox out there for me to set the receiver on. The roof of my car doesn’t count because it’s not geostationary. I’d like to have a way to repeatably locate the receiver when I’m testing in the parking lot.
Maybe I’m paranoid, but I’m always worried about some punk kid walking off with the base station module when it’s not within my line of sight. The punk kid I used to be in my teenage years would have done something malicious like that. It’d be great if I could make it a little bit more difficult to steal.

With these goals in mind, I decided it was time to build a real base station. One like the Emlid Reach RS2, but doesn’t cost me $1,899.

A Glorified Enclosure

The Emlid guys are geniuses. They basically took an RTK GNSS chip they can buy in bulk for $150 a piece, slapped it in a super nice thermoplastic case, developed an app that is more or less equivalent to U-Blox’s U-Center, and then stuck a price tag of $1,899 on it. I’m embarrassed I didn’t think of doing it myself.

They do offer some nice benefits with that $1,899 price tag, such as integral Wi-Fi and data logging capability, but in my humble opinion, those features aren’t worth what they’re charging. Realistically, I need a tripod, a mostly waterproof enclosure, a lead acid battery with a charger, and a cover for my GNSS antenna. Something like this:

RSTP-A10001 (06-21-19) — My version of the Emlid Reach RS2.

I have a 12V lead acid battery and charger I stole from an old weed eater that I intend to use for this enclosure. The battery is rated for 3.6Ah, and according to the Ardusimple website, the board consumes 600mW at 5V, so 120mA of current. That would mean you could keep the Ardusimple board on for 30 hours. Not too shabby! I don’t know if they’re including the radio current consumption in those numbers, but even if it’s twice the 600mW they listed, we should be in good shape.

I’m still learning how to use these GPS modules, so I want to have access to the micro USB port that lets me communicate with them via U-Center. I found one of these cables for that purpose. I want to be able to interface with the board without opening the enclosure.

The guys that designed the Ardusimple boards were very forward thinking, and they made them such that you can power the board from any port or all the ports. The board has two micro USB ports, one for GPS data and the other for debugging the XBee radios. I don’t anticipate needing to use the XBee port often, so I am going to power the board with it instead.

To step down the 12V to 5V the board needs, I am going to use one of these DC to DC buck converters. Instead of two wire leads for the 5V output, it has a micro USB connector. Very handy. This converter should plug and play right into the XBee micro USB port.

One concern I have with it is RF interference. I’ve read some comments saying these converters don’t play well with FM radios. The way my enclosure is designed, I’ve got it sitting right below the Ardusimple board. GPS signals are in the 1.5GHz range if I remember right, so maybe we’ll be okay.

I’d like to use a tripod that’s stouter than your consumer grade camera tripod. Ideally it would have a hook under the center that I can hang a plumb bob from to make sure I’m setting the tripod up in the same location every time. I found a tripod that appears to fit the bill on Amazon.

tripod stud — A survey grade tripod that looks promising. The 5/8-11 UNC stud is stout, but a little inconvenient.

Most survey grade tripods appear to have a 5/8-11 UNC threaded stud, so I’ve used a low profile cap screw with a coupling hex nut to mount the enclosure on the tripod.

The tripod mount method — The coupling nut used to interface the enclosure with the tripod.

Last but not least, I need a way to protect the antenna as it sits on top of the enclosure. I opted for the OEM antennas that Ardusimple sells for the simple reason that all the other antennas they offered came with no less than 5m of extra cable. Yikes. Where would you put all of that cable? The OEM antenna cable was 30cm long.

The downside to the OEM antenna is that it doesn’t have any protective case. I could have 3D printed something, but I like to keep things simple. I really just need a dome looking thingy to cover it.

It’s kind of amazing what Google can find if you type “plastic dome” into the search field. At least for me, it turned up t his on the first page of results. Pretty much exactly what I’m looking for. I intend to use a modified pipe gasket and some rubber washers for an approximately water tight seal.

The dome is about an eighth of an inch thick, so to make sure it doesn’t attenuate the GPS signals too much, I did a little test where I put a similar plastic bowl over the receiver. It affects the signal strength only marginally.

Last but not least, every GPS antenna needs a good ground plane. Sparkfun sells a 4in diameter ground plane for $5. It’s 0.125in thick steel which is a bummer for drilling holes through, but it beats routing the circular profile out of a piece of bar stock.

bom — Bill of material for the poor man’s RTK GPS base station. The items I have on hand have a zero quantity.

Total cost? Should be under $200, depending on shipping for all these items. You too can have a Emlid Reach RS2 for the low, low price of $200.

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.

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:

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.

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.

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…

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.

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:

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.

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:

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:

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.

Selecting a Motor

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.

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

BLDC-108 speed torque power — The speed and power versus torque curves for the BLDC-108 motor. The blue curve is speed and the red curve is power. Excel only lets you plot two separate y-axes, which is very frustrating. Get it together Microsoft, this is 2018!

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.

Some thoughts about this motor:

The torque is a little on the low side, even after you factor in the pulley ratio. I suppose you could go with a higher pulley ratio, but that reduces your speed even further, which I’m told affects the quality of your grass cut.
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…

Next time I’ll evaluate the 3000W HPM3000B motor.

The Emergency Stop Switch

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.

Safety System — The wiring diagram for the emergency stop system.

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.

The big red button installed on the rover. Be sure to include large, clear signage stating that this is how you shut it off!

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.