Several comments on my post about the RTK GNSS results I experienced in the parking lot have made me reconsider how good my RTK fix really was. I was able to get a fix pretty easily, but it was fragile, and would frequently drop back to float without any apparent change in the environment.
When searching for ways to improve the robustness of the RTK fix, I came across this very comprehensive discussion about u-Blox receiver settings. The consensus I gathered from the discussion was that there are two configuration changes on the ZED-F9P boards that can really improve your RTK fix robustness: tightening up the elevation mask and increasing the signal to noise threshold.
To change these settings, I connected the ZED-F9P module via USB to my computer and then connected to it within the u-Center software. I then went to View > Generation 9 Configuration View. I double clicked on the Advanced Configuration on the left pane to show all the various configuration items.
You can use the CFG-NAVSPG-INFIL_MINELEV configuration item to set the elevation mask. This angle is measured from the horizon upwards. Satellites below this elevation are excluded from the navigation solution. The default is 10°, which I changed to 15°.
You can use the CFG-NAVSPG-INFIL_MINCNO configuration item to set the signal to noise ratio. The default is 6dbHz. I set mine to 35dbHz.
It was kind of a pain to remove the module from the robot, connect it to my laptop, change the settings, and then replace it in the robot, so I didn’t do any A-B testing on these values, although I may in the future. The 15° elevation mask and 35dbHz signal to noise values were recommended from the discussion linked to above.
I did do an A-B test on an aluminum foil ground plane to see how that would improve the fix quality.
Below is the results with and without the ground plane. Initially I had the robot parked in my driveway under some trees, but after waiting more than 10 minutes for an RTK fix, I decided to drive the robot out in the street where there was a better view of the sky. Shortly thereafter, I got a fix.
But with the foil ground plane, I was actually able to get a fix in my driveway under the trees. I drove the robot along my street at about 2:30 to see how robust the fix was. Much fewer hiccups, even with a more challenging environment.
I ran the same mission down my street and back with and without the foil ground plane. The ability to keep the RTK fix with the foil was quite surprising. It’s definitely an improvement.
I will take these settings and foil ground plane to the parking lot soon and see how they perform.
Previously I was using GPS blending between a u-Blox NEO-M8N and a ZED-F9P. When the F9P had an RTK fix solution, all was well. But after losing the RTK fix, the position estimate reverted to the inferior M8N position solution.
So I conducted a few experiments to see if there was a way to get a better position estimate. I realized while tweaking parameters that the final position estimate is what we’re really trying to improve, not just the quality of our RTK fix from the F9P module. A better RTK fix will help our position estimate, but that’s only part of the equation.
Instead of feeding arbitrary coordinates into the base F9P module, this time I let it survey in with a precision of 2.5m and a time of 300s. I was surprised how close to the map imagery the survey in solution was. It was off by ~18in would be my guess.
I started by unplugging the M8N module, but unfortunately the compass is also powered by the 5V and GND pins on the data cable. So with both modules active, I set the GPS_AUTO_SWITCH parameter to 3, so that only the second GPS, the F9P, would be used.
This was a great way to test things because the flight controller was still logging the M8N data, but it wasn’t used for computing the robot’s position.
I was skeptical that this change would actually improve things because the F9P maintains an RTK fix only intermittently at best. But the results surprised me.
The Ardupilot software has some magic in it (meaning code I don’t currently understand) that allows the rover to continue with high accuracy even without a GPS solution at times. I think the wheel encoders are helping significantly in this regard but I can’t say for certain.
And related, the blue line is the M8N position accuracy. It’s really terrible. At times it’s a parking stall width, about 2m, from the RTK fix position. In hindsight, I was corrupting a really good position solution by blending it with a solution that was always off by at least 2m.
I looped the same square mission about 20 times and placed screwdrivers on the asphalt at the center of the robot’s travel to mark it’s path and check its repeatability. I would estimate the path drifted ~4in over the 20 loops.
Here’s a picture of the first few loops of the mission. Even with some hiccups in the RTK fix solution, the overall position estimate is very good.
I didn’t realize it until I started reviewing the logs, but the cell phone battery pack that I was using to power the base F9P module went to sleep after about 10 loops. That means no RTCM stream from the base, which means no RTK fix at the rover. But even without an RTK fix for 10 loops, the position solution was still very good.
In hindsight, the repeatability could be even better than ~4in that I was seeing if we could have intermittently re-established an RTK fix during that time.
Moral of the story: don’t ruin a really good answer (RTK fix) by averaging it with a really bad answer (3D fix).
Late last year I traded in the Honda for a small truck. As I was designing the robot lawn mower it quickly became apparent that it wouldn’t fit in my little sedan. And even if it could, I’m not sure how I would load and unload a machine that weighs 300lb by myself.
I thought about taking it apart to transport it and then putting it back together in the field. But that is a very inefficient way to do business. The Honda had a great run, it was 16 years old and needed a new timing belt so I figured it was time to upgrade.
I’m a big fan of goals. For my afternoon in the parking lot, here was my to do list:
Figure out the best way to load and unload the robot mower into the truck.
Install my new wheel encoders and make sure they are working robustly.
Play with the RTK GPS modules.
Take the robot into some tall grass and see how it performs.
I realized that I have a few more things I need to bring to the field with the new robot lawn mower, so I updated my checklist of things to bring or do prior to leaving the house:
Cell phone with cellular data and enough storage space for several videos and photos
AA batteries for the RC transmitter
Make sure rover batteries are sufficiently charged
The toolbox with hex wrenches, adjustable wrench, and screwdrivers
Laptop with a good battery charge
Telemetry radio for the laptop
SD card, installed in the Pixhawk
RTK GPS receiver, antenna, and micro USB cable for power
Rechargeable batteries for RTK GPS base station
Prefetch any map data that will be needed in Mission Planner
Preplan any missions that may be needed and save the waypoint files
I typically would have gone to an actual field, but a parking lot offers some really nice geostationary markers that show up on satellite imagery: parking stripes.
My neighbor saw me using chunks of plywood to load the robot in the truck. He had some tailgate ramps he wasn’t using and let me borrow them for the day. I think I’m going to make him an offer for them. They were tremendously easy to use and transport.
The roof of a car makes for an awesome ground plane, so I decided to set up the RTK GPS base station on top of the truck. I noted which parking stall I was in and then found that same stall on the map imagery in Mission Planner and fed those coordinates to the ZED-F9P module.
To get a feel for how the RTK GPS was performing, I ran a circle mission.
On the map, the green line is GPS2, the position solution from the ZED-F9P module on the rover. The blue line is GPS1, the NEO-M8N module. My understanding is the red line is the EKF’s estimation of position after fusing sensor data with the GPS data.
The blue line is offset from the green line, even though their paths are pretty similar. I think this is because I arbitrarily selected the location of the base module. Essentially, I’m using two different origins: one for the RTK GPS versus whatever the M8N uses. This poses a problem when you lose the RTK fix.
The ZED-F9P module doesn’t lose the RTK fix gracefully. It frequently goes from RTK fix to no solution. After a few seconds though it usually returns to an RTK fix. But once it’s lost, the EKF replaces the F9P position solution with the M8N’s solution. Which is off by a few feet.
You can see an example of this behavior in the picture above. The position is heavily weighted to the F9P solution, but once it’s lost, it jumps immediately to the M8N solution. Interestingly, when the F9P reports an intermediate solution such as 3D fix, the weighting behavior is more of an average between the two receivers.
I double checked my parameters and GPS_AUTO_SWITCH = 2, so the EKF should be blending solutions, not just using the most accurate solution of the two. And when both receivers are in 3D fix mode, that’s the behavior you see.
I have some questions based on these observations:
Is GPS blending really that useful? Maybe I should just ditch the M8N module all together. Whenever you have an RTK fix, it seems like this solution is so superior that the EKF basically ignores the M8N solution.
For GPS blending, would an additional RTK GPS help? The reported accuracies from two identical modules would be similar. Maybe the redundancy would help when an RTK fix is lost on one receiver.
Why does the EFK assume the robot’s position suddenly jumps? This is a rover, not a quadcopter. Especially when you have wheel encoders and an IMU, you should be able to assume that the robot’s position isn’t drifting significantly due to external disturbances, even if the GPS position jumps.
If we could eliminate the offset between the two solutions by using the same “datums” would that make the failover more graceful?
Some of those questions can be turned into experiments I can conduct the next time I’m out in the field:
Disable the NEO-M8N module. How does the robot respond when the ZED-F9P module loses an RTK fix?
Instead of arbitrarily setting the coordinates of the RTK base module, we can let it “survey in” to determine its location. This may eliminate some of the offset between the F9P and M8N position solutions.
We can measure the offset between the F9P and M8N solutions and then adjust the coordinates of the RTK base module to compensate. This would minimize the position jump between solutions when RTK fix is lost.
I also took the robot out into some taller grass to see how it would perform. You can see a video of it here. I also took a time-lapse of a typical grid run. Overall not bad, but for striping grass, it’s not good enough.
Going forward it looks like I will need ways to obtain a better position solution. I don’t think RTK GPS will get us there entirely. There are some exciting visual odometry solutions out there I may look into.
I was able to take the prototype robot lawn mower out for a drive this week. Watching the design drive off the computer screen and into my backyard has been immensely satisfying. Below are my notes from a day spent becoming better acquainted with the robot mower.
Initially I wired the RC receiver straight into the Sabertooth so I could take it out for a drive. I’d forgotten how much smoothing the Ardupilot software adds to the control output. The robot was almost too responsive without it.
But overall, it handled wonderfully. I was almost able to drive up the curb from my street into my yard, but there wasn’t enough traction to get the back wheels up the curb. So far, so good!
After I got the Pixhawk wired up (more on that below) I ran a few autonomous missions and started tuning the steering and throttle PID values. At lower steering turn rates, I noticed the swivel caster wheels sometimes catch on the grass instead of swiveling, and the whole setup actually rotates about the center pin. The scenario in the picture above only occurred once, but I noticed the wheels getting hung up more than once.
When I was putting the robot together, I noticed the casters weren’t fabricated per my print. I had designed them with more offset between the wheel axle and the swivel axis. If this continues to be a problem, I’ll have them remade with a little extra offset so they swivel easier.
Getting the robot wired correctly was nerve wracking. I made a wiring diagram for the power enclosure and modeled up all the components and connections to make sure they fit, but I skipped this planning step for the Pixhawk enclosure. The amount of wires I had to route to the Pixhawk multiplied quickly:
5 wires from the drive wheel rotary encoders, a total of 10 for both motors.
4 Sabertooth control wires.
4 relay control wires.
6 wires for the Pixhawk power port.
2 emergency stop wires.
2 additional wires to power the servo rail on the Pixhawk.
I wasn’t expecting 23 wires needing to be routed to the Pixhawk enclosure, and making sure I didn’t get something wired incorrectly was nerve wracking.
And ultimately, I did wire something incorrectly. When I first powered the robot on, nothing happened, other than the Mauch BEC getting hot. And that’s never a good sign.
Turns out I had incorrectly wired the servo rail by swapping the + and – wires. Yikes. I eventually discovered the issue and fixed it, but not before learning a lot about the LM2576 voltage regulator I incorrectly thought was the issue.
After I fixed the wiring, everything seemed to work, until I started running autonomous missions and had trouble getting the MAVLink Inspector within Mission Planner to show wheel encoder data. Initially I couldn’t even find the wheel encoder message. But after a few reboots it magically appeared. Not sure why it wasn’t visible from the start.
From the get-go, only the right wheel encoder was working. Below is WENC.Dist0 for the encoder on the left motor and WENC.Dist1 for the encoder on the right motor.
And below is what the graph for the right encoder by itself, WENC.Dist1 versus time, looks like.
So to troubleshoot, I swapped the encoders. The idea is that WENC.Dist0 should look like the graph above and WENC.Dist1 should look like more like the first graph, with values much greater than 10E-6 and gradually increasing. This would isolate the issue to the encoder and not a settings, wiring, or Pixhawk error.
As an aside, having posted that graph I’m now wondering if the negative value means I have the A and B wires swapped. I was driving the robot forward mostly, so I would expect the values to be increasing, not decreasing. Regardless, at least the left encoder is obviously outputting some kind of useful data.
After swapping the encoders…
Great, now they’re both broken!
I decided to call it quits after this because the sun was going down. I took the robot back into the garage and got the Arduino out to see what it said about the encoder output. Unfortunately it confirmed that the left encoder at a minimum was broken. The Arduino sketch counted pulses and only got up to 1 or 2 regardless of how much the wheel was rotating.
I remembered I had some 900CPR encoders I had purchased a while back and decided to see if I could get them to work with the Pixhawk. So I swapped the 32 CPR encoder with the 900 CPR encoder, and lo and behold, it started to work again.
All I can gather is that I must have fried one or both of the encoders with my wiring shenanigans. But it concerns me that one of the encoders was working at the start of the day and stopped working by the end of the day.
More to come once I get the mower deck assembled and installed. You can find a brief video of the rover doing an autonomous mission in my backyard here.
The lack of activity here on MowerProject.com hasn’t been due to a lack of autonomous lawn mower development. This June we were blessed with a baby boy, and he has been taking up a lot of our time! Posting to the blog in the meantime has been difficult.
Juggling my 8 to 5, the mower project, and making time for Mr. Mower Jr. has been quite challenging. I owe a special thanks to my wonderful wife for letting me run errands for the project and work on it in the evenings. She is truly something special! Having her to bounce ideas off of and to encourage me along the way has been invaluable. I love you so much Mrs. Mower!
As I’ve done in the past, I find it’s good to set goals. Even if I don’t achieve them, they focus my mind and give me a sense of accomplishment and purpose as I work toward them. Below are some goals I have for the next few months.
Finish Procurement and Begin Assembly
I have all of the parts to build the prototype robot lawn mower except for two more SLA batteries and new enclosures for the electronics. The SLA batteries are so cheap that I think it’s worth a gamble on them instead of ponying up the $1,000+ I’d need for some good quality LiFePo4’s.
Once those items arrive I will start to wire up the enclosures and get the subassemblies put together. I will probably need to make another wiring diagram showing how everything connects and functions before I get too far along.
Support Fabrication of the Prototype Weldments
Originally I had planned to fabricate a lot of the robot lawn mower components myself. The idea was that it would be cheaper to purchase my own tools and make the parts myself. Unfortunately, that plan requires a lot of time, a resource I’m very much short on these days with Mr. Mower Jr. in the picture. The economics of paying someone to make the parts suddenly looks attractive again.
To this end I’ve found a local gentleman who is helping me make the weldments. I find myself over at his shop every week or so answering questions about the design, and working with him has been very productive. His feedback has been quite helpful in helping simplify and refine the design so that it is easy to fabricate.
I have a litany of questions I need to get answered about the performance of the prototype before we even cut grass. A few questions I need to get answered:
How long can the mower run on four 12V, 35Ah SLA batteries?
How well does the prototype handle pivot turns?
How much current does the entire robot draw at typical operation?
We need to verify emergency stop and safety features function correctly.
How much air flow does the current mower deck and blade design create?
Once I’m satisfied the design adequately answers these questions, we can start cutting grass. Stay tuned for some pictures of the fabrication so far!
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:
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.
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.
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 this 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.
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.
I have decided that I need to refine the wheelchair robot’s ability to navigate accurately and robustly before I shell out a few thousand dollars to build the robot lawn mower. The goal here is to have the wheelchair robot “mow” my lawn before I invest in the actual robot lawn mower. If the wheelchair robot can’t do it, the robot lawn mower doesn’t have much of a chance, either.
So I’ve spent most of my time testing the wheelchair robot and the RTK GPS system. I have been typically placing the base on my community mailbox because it is geostationary, has a large metallic surface to prevent multipath, and a decent view of the sky.
Surprisingly, I was able to get several RTK Fixes partially underneath my large maple tree in my front lawn. While in RTK Fixed mode I had the rover running a mission with 10 waypoints in a 3m diameter circle. I cranked down the waypoint radius to 0.3m to try and make sure the robot was accurately traveling to each waypoint.
The map above shows some calculated positions prior to obtaining the RTK fix and after the RTK fix is lost.
There is some offset between the satellite imagery and the actual location on the ground, which makes things a little confusing, especially when planning a mission close to many obstacles. I almost ran into my neighbor’s basketball goal after I lost my RTK fix.
To give you a better idea of the quality of the fix, here is the latitude reported by the GPS receivers and the blended location as calculated by the EKF:
The RTK fix in the graph above is first obtained at 18:06:15 and is maintained intermittently until about 18:14:12. The reported HDOP for both GPS receivers was close to 0.7, but despite this, I am impressed that by default, the EKF is giving much more weight to the RTK solution. You can see this in the graph: the red and green lines are much closer than the blue line.
The oscillations in the graph above are from the circular mission I was running. It looks like I had a pretty good RTK fix from about 6:09PM to about 6:13PM. This was about 11 laps about the circle.
Some additional information about the fix status:
I don’t want to oversell these results, because they weren’t typical of the entire afternoon. I spent a good chunk of time running the wheelchair robot in Acro mode tuning the throttle and steering parameters, and I wasn’t able to get an RTK fix throughout that time. It’s very much a patience thing.
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.
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:
I made sure the motor still works. I connected the motor wires to the battery terminals and it spooled up just fine. No problem.
I checked continuity across the motor wires to the relays and Sabertooth motor controller. Everything is connected. No problem.
I checked the relays to make sure they weren’t broken, they function as desired. No problem.
I checked the fuses on the motors. Not blown. No problem.
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.
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.
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.
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.
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:
It is plug and play with the Pixhawk (mostly).
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.
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:
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.
And then I had to mod the adapter cable because apparently the pinouts are inverted between the DF13 and JST-GH connectors. Frustrating.
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.
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.
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.
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.
As Roby over at Deep South Robotics can tell you, there is a lot of snake oil being peddled in the RTK GPS space. I’ve been a quiet spectator in this area for as long as I’ve been working on the mower project, and I’ve seen a lot of systems come and go.
Two modules that I had my eye on for a long time were SwiftNav’s Piksi V1 and Emlid’s Reach. Both were L1 only systems. I religiously visited their forums and poured over commenter’s experiences with both modules. In a nutshell, here’s what I learned:
L1 only systems can take a long time to get an RTK fix, and they can lose them in a heartbeat
If you’re in the air with a quadcopter or fixed wing plane, an L1 system generally works well because there is no multipath
If you have any kind of multipath that you are contending with, you are absolutely screwed with an L1 system
On top of that, integrating these systems require that master’s degree in computer engineering I talked about earlier (remember, I am a lowly mechanical engineer, wires aren’t really my thing). Neither system is truly plug and play, from what I can tell. A lot of the integration has to do with injecting GPS corrections through telemetry over MAVLink, as I understand it.
Then last year I discovered that u-Blox was coming out with their own L1 system, the NEO-M8P. I watched a very thorough introduction to the module and was almost going to buy one when I noticed that u-Blox was coming out with a multi-band, multi-constellation RTK GNSS receiver, the ZED-F9P.
I contacted the folks out at u-Blox and they said that an evaluation board would be available in Q1 of 2019, but in my research I stumbled across the folks at Ardusimple. These guys are making a similar evaluation board for the ZED-F9P module that includes a Pixhawk GPS port. Talk about simple.
Is this the holy grail of RTK GNSS? From my experience with this board so far, the answer is yes.
A Simple Test
I conducted a test similar to the one in the video I linked to above. I took reported baseline measurements from u-Blox’s u-Center software, converted the NED components to a net distance and then compared the value with a tape measure.
I intentionally placed the receivers in a really crappy area of my yard to see what these modules are capable of. My neighborhood has lots of two story houses, and many fully grown trees, although they are without leaves this time of year which certainly helps. Here’s a panoramic shot of the backyard, with my house to the right:
Bottom line is that this was a pretty challenging multipath environment. I would estimate 50% of the horizon was occluded by my and my neighbor’s house. The remaining areas were pretty well covered up to about 20° if you exclude bare trees. How well did the modules perform?
It’s tough to see in the picture but the NED measures in meters are:
N = -2.1990 E = 0.1063 D = -0.0006
Using the 3D distance formula on these components and converting to inches gives a baseline distance of 86.6759in. You can see in the picture above that the rover antenna is sitting right at 87in. Holy geography Batman indeed!
Some Other Observations
A few other things I noticed in my brief time working with these modules:
The Ardusimple boards have the LED status “backward” from what you’d expect. No corrections means solid blue light, receiving corrections but no fix is blinking blue, and RTK fix is no light. Counter intuitive, but their documentation does mention this.
Just for fun I covered the antenna and waited for the light to turn on, indicating the RTK fix was lost. When I removed my hand, the light would turn back off consistently after less than a second. It appears that if you lose your fix with these modules, you can get it back very quickly, even in a challenging environment.
I kept moving the boards toward the alley between my house and my neighbor’s house, just to see what it would take to force the modules to lose the RTK fix and I was able to get as far as 227in from the base point in the picture above, which was about 3 feet away from my covered patio area before I lost my RTK fix.
Even after I lost the RTK fix, the baseline error was only 12in in 3D float mode. Still really good. Keep in mind during most of this test, I am standing at the laptop taking pictures and fiddling with u-Center. So my body is blocking some signals, too, I’d imagine.
So far these boards are looking awesome! Next step is to hook things up to the Pixhawk.