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.

More Backyard Testing

The weather the past two weekends has been good enough to take the robot out for some testing with the new RTK GPS system. The Ardusimple boards are pretty awesome. The things I like about them:

  1. It is plug and play with the Pixhawk (mostly).
  2. It is configured to automatically survey in the base location. This means you don’t have to mess with U-Center and configure it out of the box, unless you want to plug in specific coordinates.
  3. The long range radios I ordered mean you don’t have to mess with injecting the RTCM data stream through telemetry, although I will eventually attempt this.

Those things I like are huge. A few minor things I didn’t like:

  1. The connector on the board is technically the correct Pixhawk connector, a JST-GH 6 pin connector. Which is great, but every Pixhawk I’ve seen has DF13 connectors. So I had to buy an adapter cable.
  2. And then I had to mod the adapter cable because apparently the pinouts are inverted between the DF13 and JST-GH connectors. Frustrating.
  3. The antenna choices offered by Ardusimple included a nice IP65 antenna and a unenclosed one. Initially I wanted the IP65 antenna, but then realized it came with a 5m (!) long cable. Where are you supposed to store 15ft of wire on a robot like this? So I went with the unenclosed version with a 10cm long cable.
IMG_4241
The robot wheelchair with the RTK GNSS antenna mounted to the top enclosure. The second longer antenna is for RTCM corrections from the base station.

Once you tweak the adapter cable, you can plug it in to your Pixhawk and get RTK positioning in no time flat! Very awesome. No need to even tweak anything in mission planner. It will interpret RTK float and RTK fixed messages from the rover module.

To set up a base station, I grabbed my charcoal grill, a micro USB DC adapter, and an extension cord.

Image-1
The base station is on the grill. The thought was the metal shell would make a good ground plane to mitigate multipath.

And it worked pretty well until the rover tried to ram it in auto mode. Not cool, robot wheelchair. Not cool.

Another issue is that my backyard is a crappy GPS environment. It was pretty easy to get an RTK fix when stationary, but in motion losing one or two satellites was enough to bump back to RTK float. Bummer!

So to fix these two issues I moved the base station to my front yard which had a better view of the sky, and mounted the unit on the roof of my car, which I’ve heard makes an excellent ground plane. Whoever said that is right.

This was quite an improvement. I was able to run autonomous missions while maintaining an RTK fix for 80%+ of the time in the back yard.

IMG_4267
The black tick marks is the position of the front caster as it runs a loop in my driveway.

I had the robot run an autonomous mission in circles in my driveway and the repeatability was still pretty good. The tick marks on the drive way indicate the position of the side of the front caster through each pass. The distance between the furthest two tick marks is 5in.

Overall, the Ardusimple boards are looking like a very good investment.

Small Design Changes

mower 1-6-19
The robot mower design as of this weekend. Some wiring is completed.

I’ve decided to change a few things on the robot mower design. I have a tendency to get hung up on really small things by spending way too much time thinking about them. The deck height adjustment was turning into one of those things.

I’ve changed the design to include four simple clevis pins. They’re $0.50 a piece. You don’t need to adjust the deck height that often, and spending $100 on parts to do that in a fancy way is a waste of effort and money.

I modeled up a discharge chute because I think the mower will need one to look professional. I intended to 3D print it, but it turns out the dimensions are big enough that most hobby websites won’t take it. I know of a place nearby that does industrial 3D printing and they quoted me $290 for the part out of ABS. Yikes. Maybe I’ll try to adapt an off the shelf chute instead. That’ll be more reverse engineering but it will probably work better. And cost a few hundred less.

xt60
Some simple XT60 connectors for the motors. They’re rated for 60A and should be appropriate for this application.

I’ve started modeling up some wires and coming up with a way to neatly connect the motors was more challenging than I thought it would be. I found some “wall mount” XT60 connectors that will hopefully will work well. I’ll have some mounting plates NC machined and then attach the XT60 wall mounts to the plate.

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.

Mower Positioning

5939749916dcd.image
A typical robot lawn mower on the market today. It’s basically a Roomba, but for your lawn. Have fun tearing up your lawn to bury cable!

When you google “robot lawn mower” you will find a bunch of Roomba looking robots like the one above. The missing ingredient between these robots and the one I’m attempting to make is one thing: positioning.

When you need your lawn mowed, you want it to be mowed 100%. You don’t want half the lawn cut and the other half not cut. You don’t want gaps of uncut grass between your stripes. You don’t want random paths cut through your lawn. You want nice, parallel, alternating stripes.

To accomplish that, you need to know the location of the mower throughout the process so you can keep track of areas that have been cut, and so you can cut the grass in a specific manner. Back and forth stripes, for example, or perhaps a nice circular spiral moving outward from a tree.

I’ve come to the conclusion that to really automate the mowing process, you need at least +/-1in of positioning accuracy. Historically, such a system required a $40,000 survey grade GPS system from Trimble or Leica and the equivalent of a master’s degree in computer engineering to integrate it into your robot.

So the Roomba mower guys, given these constraints, came up with the following solution:

Who cares where the mower is? Just fence it in and have it mow all the time. You’ll eventually cut all the grass. We gotta make a product that we can realistically sell to people at a profit, you know.

-Some engineering manager out at Roomba Mowers Inc, I’m guessing

Every robot mower has to compete with the neighbor kid that will mow your lawn for $20. He’ll even try to make the stripes in the front lawn mostly straight and parallel. That’s the price point and level of quality that you have to beat with any robotic mowing system.

The Roomba mower guys sacrificed quality and scalability to get there with their system. Those are probably decent tradeoffs if we’re honest. While these Roomba mowers are for the most part a novelty, for some folks they work okay. But in the scenarios where they do perform well, they’re probably not value added at their $2,000+ price point.

So for years, guys like me that dreamed of real robot lawn mowers were left with just that: dreams. I don’t have $40,000 laying around, and I’m a mechanical engineer, not a hardware guy or a computer engineer. And even if I had both of those things, such a system can never turn a profit in the market place.

Enter u-Blox with the ZED-F9P module….