SwiftNav Piksi RTK (high accuracy) GPS now supported by Pixhawk/APM

Great news from the SwiftNav team:

Swift and I are proud to announce our first official public release of ArduPilot integration for Piksi! This includes:

- A complete step-by-step integration guide available on our wiki

- An Swift Binary Protocol driver for ArduPilot, available in the forthcoming ArduCopter 3.3 (currently available in Beta, soon to be released: ).

- Version 23 of the Piksi Console, with support for communicating with ground station software.

- Mission Planner and MAVProxy support for ground station-based GPS corrections.

We are releasing this integration as a major milestone towards bringing centimeter-accurate flight to ArduPilot! But we need everyone's help! There is still significant work up ahead to better use Piksi on ArduPilot! Specifically, we're working to improve ArduPilot's control and estimation systems as to use Piksi more effectively. We're also building an analysis pipeline to help the community analyze the accuracy of their flight paths and debug potential problems with their setup.

To that end, we're issuing a Call for Logs! If you use Piksi on ArduPilot, please send us your DataFlash logs! You can do so by attaching it in a reply to this forum. These logs contains valuable Piksi behavior data, which will help us debug and improve ArduPilot and Piksi.

This announcement represents the culmination of a lot of effort from Swift, myself, and the open source community.  I'd like to take this opportunity to thank Andrew Tridgell, Randy Mackay, Michael Oborne and the entire community for their help and encouragement with this ongoing project.

We look forward to everyone's thoughts and feedback about the documentation and current experience with the integration!

Get started here! http://docs.swiftnav.com/wiki/Integrating_Piksi_with_the_Pixhawk_platform


-Niels and the SwiftNav team

Views: 11563

Comment by Antonie Kruger on July 9, 2015 at 10:19pm

A giant leap - well done. Let me see if I have this right.

The stationary GPS(Base) has an autonomous coordinate as achieved on startup. The RTK correction(I suppose the binary protocol referred to) is carried to the other receiver(rover) embedded in the mavlink stream where it is received by the pixhawk and routed to the GPS receiver. Using this it can achieve RTK fix.

A brilliant solution. A next step might be using the Ground Station to dial into a NTRIP caster (RTCM provider), get the correction from a NTRIP base, translate into the proprietary binary protocol and transmit to the rover. This will remove the need for a base receiver. Might have a bit of a latency issue.

Thanks for the great work - I guess Piksi is on the shopping list. 

Comment by Rob Dunbar on July 10, 2015 at 12:17am

I'll be dusting off my two Piksi's now to try out. Thanks for the update.

Comment by Greg Nuspel on July 10, 2015 at 3:45am

A little of the topic question. If the external antenna is really the best option, could you reduce the weight and cost by eliminating the patch antenna?

Comment by Michael Papenhagen on July 10, 2015 at 4:33am

Hi Guys

Great work. If I understand it correctly, could I eliminate the requirements for surveyed ground control when doing Topographical Surveys?



Comment by RPM on July 10, 2015 at 7:39am

Michael, from what I've found the centimeter level accuracy of the UAV will greatly increase vehicle position and attitude accuracy, which will achieve more accurate results in PIX4D Photoscan etc...

You will still need a known point for the base and the further away you get from the base the more GCPs you will need to achieve centimeter accuracy in your map/model. If you are mapping a large area that is not flat GCPs at the extremes, interior and perimeter will help a lot.

This is great news that I have been waiting for and it seems clear now which RTK solution to go with for pixhawk powered vehicles. Well done!!

Comment by Nikola Rabchevsky on July 10, 2015 at 7:43am

The short answer is "no".  That's how all RTK systems work.  You only get centimeter precision North/East/Down separation between the rover module and the base module.

Comment by Jason Franciosa on July 10, 2015 at 7:50am

Excellent! Thank you for the hard work. I will test this shortly and post logs to help with development!

Not only is this great for increased mapping accuracy, but, if working properly we can use the GPS Altitude for much more precise landings on long flights when the baro typically has issues with drifting. May be a better solution than the LIDAR for some situations!

Comment by Jason Franciosa on July 10, 2015 at 8:37am

Quick Question. Is there any issue with using the RFD900's with this setup instead of 3DR Radios? And if using RFD900's would we set the GPS BAUD to 115200 still or 57600?

Comment by Peter on July 10, 2015 at 10:51am

A couple questions:

1. Can these units be used to log raw gps data that could be post processed after the flight (thereby removing the need for another transmitter)?. Can one convert the raw GPS data to RINEX?

2. Using you units for both base and rover how far can you go out while still maintaining centimeter accuracy? Do you have some test data available for viewing?

I'm intrigued! As a long-time DGPS user this is very exciting. Combined with a brushless gimbal on my hexacopter it should be possible - in theory - to achieve centimeter level XYZ image center points using your devices. A selection of image centers would then be used as ground control for triangulation. External ground control points - collected manually - would then just be used as independent check points. I LIKE!! 

Comment by Mauricio on July 12, 2015 at 11:23am

So is this ready or not? it ways "now supported by Pixhawk/APM" but then it says "there's still siginificant work ahead"...


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service