Compiling and Flashing APM:Copter to Pixhawk

[Niels Joubert]

Hi everyone!

I'm developing the GPS Driver for Swift Navigation's Piksi GPS for the APM:Copter project. I had my code running on the old APM v2.6 boards, but now that I've gotten my hand on the Pixhawk I want to start developing for that, and I'm having some issues getting it to compile and flash to the Pixhawk board.

Can someone help me get my build and upload process going? I'm on Mac OS X 10.9 as my dev environment and I also have windows 8 in a Virtual Machine for using Mission Planner.

Here's my steps:

git clone https://github.com/diydrones/PX4Firmware.git

git clone https://github.com/diydrones/PX4NuttX.git

git clone https://github.com/diydrones/ardupilot.git

cd ardupilot/ArduCopter

make configure

make

All this returns with no errors, but now attempting to flash it, I'm running into trouble.

If I try to just use 

> make px4-upload

I get "ERROR: Firmware not suitable for this board"

and although it shows up in /dev/tty.usbmodem1 I cannot connect to it from mission planner. The normal large flight status LED doesn't come on as I expect it to either.

If i try to use

> make px4-v2-upload

it succeeds, but my pixhawk disappears from the /dev/tty list of devices within a couple of seconds and I cannot connect to it.

What am I doing wrong? And where is the instructions for building the Pixhawk code? I've had to trawl through the px4_targets.mk file to get some of this info. Is there instructions for the pixhawk build similar to the very helpful http://dev.ardupilot.com/wiki/building-the-code/

Thanks!

-Niels

[Ben Nizette]

Hi Niels,

make px4-v2-upload is the correct incantation there.  On a hunch, what ARM compiler version are you using?  What's the output of arm-none-eabi-gcc -v?

I found out last night that in fact the current Diydrones NuttX tree won't build with gcc 4.7 or newer, you need 4.6.  You can either download a 4.6 compiler from https://launchpad.net/gcc-arm-embedded/ or replace NuttX/nuttx/arch/arm/src/armv7-m/up_memcpy.s with the one from the PX4 native tree (github.com/PX4/NuttX)

The fix should be pulled in for diydrones/NuttX soon.

HTH.

--Ben.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ben Nizette]

> Diydrones NuttX tree won't build with gcc 4.7 or newer, you need 4.6

Correction, will build, won't /run/!

  --Ben.

[Niels Joubert]

Hi Ben!

Indeed I'm on v4.7.4! I replaced the file you mentioned, deleted everything and started fresh, and now it appears to be compiling and working just fine. Thanks for the catch!

Since I'm getting into the dev stuff here, who's the core team of people that's working on localization, GPS drivers and the attitude system (AHRS)?

I have a question about how the code works at a high level: all the ArduCopter code is the same between both the old Arduino/AVR and the new NuttX-based stuff. Is the entire abstraction layer that captures the differences between the NuttX/Pixhawk and the bare-metal AVR world captures in the AP_HAL library? And in that case, why aren't we running bare metal on the Pixhawk as well, why the need for NuttX?

[Andrew Tridgell]

Hi Niels,

> I'm developing the GPS Driver for Swift Navigation's Piksi GPS for the
> APM:Copter project.

great! Can you post the code you've done so far somewhere?

I have plans to re-vamp the GPS drivers a lot for APM, as the current
setup is inefficient and doesn't allow for any GPS_* parameters to
control key aspects of the GPS. I'd certainly like the Piksi to work
with the re-done driver.

I haven't started on the new driver layer yet, but I can describe the
idea if you would like me to.

Cheers, Tridge

[Ben Nizette]

> Since I'm getting into the dev stuff here, who's the core team of people that's working on localization, GPS drivers and the attitude system (AHRS)?

Hard to say, lots of people have worked on that stuff in the past.  Just posting to this list is probably the right thing to do, the right people will get back to you.  It's probably worth mentioning here though that Paul Riseborough is currently working on an EKF implementation for "fast" boards (i.e. not APM) that will complement and partially replace much of the current AHRS and INAV stuff for those boards.

> I have a question about how the code works at a high level: all the ArduCopter code is the same between both the old Arduino/AVR and the new NuttX-based stuff. Is the entire abstraction layer that captures the differences between the NuttX/Pixhawk and the bare-metal AVR world captures in the AP_HAL library? And in that case, why aren't we running bare metal on the Pixhawk as well, why the need for NuttX?

At the moment it's pretty true that nothing outside the HAL changes between platforms (I'm sure there are some exceptions?), but as mentioned above, that situation isn't forever.  The use of NuttX allows easier exploitation of the greater capabilities of new-gen hardware and also allows a good amount of low-level code sharing between APM and the PX4-native flight stack wrt drivers etc.  We don't have to re-invent the wheel.

There are certainly people more qualified than me to extend these points, but as I understand it they're the key ones.

--Ben.

[Niels Joubert]

Andrew!

Pleased to meet you! Big fan of Samba and rsync ;) I am just getting started on this, so if you're in the process of changing the driver layer we should talk! Shall we discuss this in a separate thread, and you can describe the changes you have in mind to the GPS? Why is the current setup inefficient?

There's a couple of interesting factors that come into play with the Piksi integration:

- This RTK GPS gives relative-to-base-station accurate positioning above and beyond the normal GPS location. Thus the driver now needs to expose both the lat-lon and a relative-to-basestation vector. 

- The Piksi can run at 50Hz using its own SBP protocol, which we would want to use, and thus the update loops needs to be faster.

- Given that the Piksi is still a fairly immature GPS platform I want to fly both the ublox GPS for normal GPS abilities and the Piksi for relative positioning through RTK. How do fly both and when to use which one (aka how to do the sensor fusion between these two GPSes) is also a question.

Let's coordinate!

-Niels Joubert

Stanford CS Ph.D candidate

-Niels

[Andrew Tridgell]

Hi Niels,

I've started a new thread for this GPS discussion.

> Shall we discuss this in a separate thread, and you can describe the
> changes you have in mind to the GPS? Why is the current setup
> inefficient?

The current GPS driver system is bad for several reasons:

1) it is not possible to have parameters on the GPS object, so we can't
have a GPS_USE_SBAS=0/1 parameter for example, can't have parameters
for the filtering, can't have parameters for the elevation mask etc
etc. This is a result of the GPS object being dynamically allocated,
combined with a limitation of the AP_Param system that only allows
parameters on static objects (that restriction results from a change to
save memory in AP_Param for AVR based boards, using flash to hold a
table of parameter pointers and names).

2) the GPS driver model doesn't provide a clean way to have multiple
GPS modules. You can hack it in (see my dgps-wip branch for a method
that works if the 2nd GPS is guaranteed to be a uBlox)

3) the internal variables are a mess of different units and conventions

What I'd like to do is have a AP_GPS object for holding parameters and
managing the GPSes attached, then have AP_GPS_Backend objects that
implement the specific protocols. AP_GPS_Backend would have the minimal
necessary logic for a particular protocol. It can be dynamically
allocated and receive a reference to the AP_GPS object in its
constructor.

Have a look at AP_Airspeed/AP_Airspeed_Backend.h for a somewhat similar
system for airspeed (not the same, but some similarities)

Once we have this then we would have the "GPS_" parameter prefix linked
to the AP_GPS driver, and have a GPS_TYPE and GPS_TYPE2 parameters for
the type of the first and 2nd GPS. That would default to AUTO and NONE
if we keep the auto-detector, or we could just make users configure
their GPS type (most people have UBLOX for example). The GPS type
auto-detection code has always been difficult to get really reliable as
some GPS modules (like uBlox) support multiple protocols.

> - This RTK GPS gives relative-to-base-station accurate positioning above
> and beyond the normal GPS location. Thus the driver now needs to expose
> both the lat-lon and a relative-to-basestation vector.

I'm not sure that this is necessary, as we have cm level resolution
using int32 global lat/lng, so why wouldn't the driver just give a
global position?

> - The Piksi can run at 50Hz using its own SBP protocol, which we would want
> to use, and thus the update loops needs to be faster.

It isn't clear to me that higher GPS update rates are actually better. I
suspect the EKF will not benefit from higher rates, as it quite happily
can fill in positions between samples using IMU updates.

Do you have some reason to think that higher than 5Hz GPS update rates
provide a benefit when using an inertial positioning system?

> - Given that the Piksi is still a fairly immature GPS platform I want to
> fly both the ublox GPS for normal GPS abilities and the Piksi for relative
> positioning through RTK. How do fly both and when to use which one (aka how
> to do the sensor fusion between these two GPSes) is also a question.

See my dgps-wip branch
(https://github.com/tridge/ardupilot/tree/dgps-wip) for how I've been
flying with two GPS modules.

I want to make this a standard feature on Pixhawk. Then I'm hoping Paul
can work out how to make best use of the 2nd GPS.

That branch also adds a 2nd simulated GPS to SITL, allowing for easier
software development, although currently the two simulated GPS signals
are identical, whereas we should be able to control their accuracy and
type separately.

btw, I would strongly recommend that the first step to writing a native
Piksi driver for APM is to write a SITL simulator for the Piksi
protocol. Then develop the GPS driver against that simulator. It will
save you a lot of time, and we have to do it anyway as it will be used
to ensure the Piksi support doesn't break with future updates.

Have a look at libraries/AP_HAL_AVR_SITL/sitl_gps.cpp and you will see
that we have simulations of 5 different GPS protocols already. You can
then select which one SITL produces using SIM_GPS_TYPE.

> I was just looking at the video you posted using an EKF rather than
> the old complimentary filter + DCM. Cool stuff! Once we add
> centimeter-accurate RTK positioning, do you anticipate that we'd be
> able to get these copters to hover 'perfectly' still the way the
> copters that fly in motion capture room for localization do (eg UPenn
> and ETH Zurich's work)? Or do you anticipate something more necessary?

I am pretty skeptical about cm-accurate RTK from the Piksi. I suspect
we'll get more like 50cm accuracy on good days. The Piksi is a single
frequency receiver, if it was L1/L2 and had a much higher quality
antenna then maybe we could get down to 10-cm or so.

Anyway, I ordered a Piksi ages ago, and when it finally turns up it will
be fun to give it a test.

I think that we'll need a much closer integration between the IMU
sensors and the GPS before we start to get down to cm-level even if we
had L1/L2 and a great antenna.

Also, have you seen this presentation that Ben and I did recently?

http://mirror.linux.org.au/linux.conf.au/2014/Wednesday/45-Building_an_affordable_differential_GPS_positioning_system_-_Andrew_Tridgell,_Ben_Nizette.mp4

Cheers, Tridge

[benni...@gmail.com]

>> - This RTK GPS gives relative-to-base-station accurate positioning above
>> and beyond the normal GPS location. Thus the driver now needs to expose
>> both the lat-lon and a relative-to-basestation vector.
>
>I'm not sure that this is necessary, as we have cm level resolution
>using int32 global lat/lng, so why wouldn't the driver just give a
>global position?

To quickly extend this question: I can see that having the vector might be interesting in cases where you don’t precisely know the base station position and therefore don’t have brilliant lat/lon truth, but where would it be /useful/ to have this relative data?  What’s the use case?

The use case that jumps to mind for me is the following:  If you have several aircraft working from the same base station then having the inter-agent positions at high accuracy independent of base station position would be super-useful for formation control and collision avoidance.  That said, I wouldn’t want it to be decoupled from the rest of the craft’s position awareness which in turn means that all the craft in the swarm need to have some common coordinate system in which they each individually fuse all of their data.

Given that the current INAV and the upcoming EKF both work in a local Cartesian frame, perhaps what we really want is this:  For DGPS/RTK systems with a base station, all receiving aircraft use that base station as the origin of their local frame and the GPS interface has the option of providing ground-referenced or locally-referenced readings (or both).  The base-station relative vector then simply becomes a position measurement input to the EKF.  This is actually something that’s been on my todo list for a while as a way to integrate other local-frame position data in to the fusing (e.g. vision systems, local beaconed TDOA systems etc).

  --Ben.

[Niels Joubert]

Hi Ben, Tridge!

Great to meet you guys! I just watched the talk you guys gave on building cheap DGPS systems - very cool!

comments included inline

On Thursday, January 30, 2014 6:05:57 PM UTC-8, Ben Nizette wrote:

>> - This RTK GPS gives relative-to-base-station accurate positioning above
>> and beyond the normal GPS location. Thus the driver now needs to expose
>> both the lat-lon and a relative-to-basestation vector.
>
>I'm not sure that this is necessary, as we have cm level resolution
>using int32 global lat/lng, so why wouldn't the driver just give a
>global position?

The Piksi does not calculate a global position to cm-level. It reports two pieces of data:

- standard meter-accurate gps lat-lon

- vector between the base and rover station that is centimeter accurate.

The driver can't report a centimeter-accurate global position since it doesn't know either of the GPSes to that accuracy, it only knows their relative position to that accuracy.

 

To quickly extend this question: I can see that having the vector might be interesting in cases where you don’t precisely know the base station position and therefore don’t have brilliant lat/lon truth, but where would it be /useful/ to have this relative data?  What’s the use case?

There's actually many use cases where knowing the relative position of your vehicle to, say, the starting liftoff point is useful. Consider all the research that's been done inside VICOM motion-capture rooms - all these quads know their relative position to the reference point of the room but no global lat/lon, and can perform all the neat acrobatics and collaborative work, navigating and mapping complex environments, or tracking other moving objects all known relative to a base station.

Your example is a good one - I can have one base station and my entire swarm has very accurate positioning relative to that base (that is, they are all using the same coordinate frame rooted at the base station to do positioning). This will allow you to do great swarm coordination.

 

The use case that jumps to mind for me is the following:  If you have several aircraft working from the same base station then having the inter-agent positions at high accuracy independent of base station position would be super-useful for formation control and collision avoidance.  That said, I wouldn’t want it to be decoupled from the rest of the craft’s position awareness which in turn means that all the craft in the swarm need to have some common coordinate system in which they each individually fuse all of their data.

Given that the current INAV and the upcoming EKF both work in a local Cartesian frame, perhaps what we really want is this:  For DGPS/RTK systems with a base station, all receiving aircraft use that base station as the origin of their local frame and the GPS interface has the option of providing ground-referenced or locally-referenced readings (or both).  The base-station relative vector then simply becomes a position measurement input to the EKF.  This is actually something that’s been on my todo list for a while as a way to integrate other local-frame position data in to the fusing (e.g. vision systems, local beaconed TDOA systems etc).

Yup, that's exactly what I'm thinking!

 

  --Ben.

[Niels Joubert]

Thanks for the info about the GPS changes! I'm with you on all of that - a cleaner way to have multiple GPSes with better internals sounds great. I think it's probably best if we don't couple our development too tightly, so I'll work on a SBP protocol implementation and get the Piksi running, and port it to your new GPS driver as you get that running.

It looks like a good place to start it to use your dgps-style multiple GPS code.

A couple of points:

1) As for writing a simulator for the Piksi, I think the first step there is to first just use real pre-recorded data that a fake SBP driver can replay - this is currently how we're doing all our development at Swift Navigation. I agree that a SITL simulator for Piksi is the way to go, that'll be a bit further down the todo list though.

2) As for the accuracy out of the Piksi - they've demonstrated sub 10cm relative position accuracy in the wild and sub 1cm accuracy on the lab bench. Naturally these are best conditions, what it looks like in the wild is still to be determined.

3) I imagine using the Piksi at 50Hz to do a much better job at localizing the quad. That is, to do a position hold or a preprogrammed-trajectory flight that is much more accurate than anything normal GPS gives us, and a 50Hz update rate will allow us to do a better job in these scenarios - I want to be able to fly complicated trajectories at decent speed, and a faster update rate will be important here. Why do you think that intertial navigation is good enough, given that currently position hold drifts around by quite a bit? I want position hold to be as good as those quads in VICON mocap rooms! As for a faster update rate helping the attitude calculation of the quad I don't know - the faster update rate might not buy us anything.

Thanks for bringing me up to speed! I'm going to get my SITL dev environment set up and see if I can get a first cut of the Piksi SBP driver up and running. 

Cheers guys!

[Ben Nizette]

The Piksi does not calculate a global position to cm-level. It reports two pieces of data:

- standard meter-accurate gps lat-lon

- vector between the base and rover station that is centimeter accurate.

The driver can't report a centimeter-accurate global position since it doesn't know either of the GPSes to that accuracy, it only knows their relative position to that accuracy.

Fair enough, you can't expect better ground-referenced accuracy at the rover than you have at the base!

 

 

To quickly extend this question: I can see that having the vector might be interesting in cases where you don’t precisely know the base station position and therefore don’t have brilliant lat/lon truth, but where would it be /useful/ to have this relative data?  What’s the use case?

There's actually many use cases where knowing the relative position of your vehicle to, say, the starting liftoff point is useful. Consider all the research that's been done inside VICOM motion-capture rooms - all these quads know their relative position to the reference point of the room but no global lat/lon, and can perform all the neat acrobatics and collaborative work, navigating and mapping complex environments, or tracking other moving objects all known relative to a base station.

Your example is a good one - I can have one base station and my entire swarm has very accurate positioning relative to that base (that is, they are all using the same coordinate frame rooted at the base station to do positioning). This will allow you to do great swarm coordination.

Right, we're on the same page here.  My point was that there's no point feeding the lat/lon through the current fusion path and having the relative position information separately.  The use case for the high accuracy vector is exactly like VICON: Providing high accuracy information in a *common*, local frame to all agents.  The point is that we don't currently have a common, local frame in the code; we've got the common global GPS frame and the local INAV frame defined wrt the specific vehicle's arming point.

As below, extending the local frame such that we can coordinate it between agents would be freaking perfect :DDD

  --Ben.

[Ben Nizette]

Just a quick one on this: 

3) I imagine using the Piksi at 50Hz to do a much better job at localizing the quad. That is, to do a position hold or a preprogrammed-trajectory flight that is much more accurate than anything normal GPS gives us, and a 50Hz update rate will allow us to do a better job in these scenarios - I want to be able to fly complicated trajectories at decent speed, and a faster update rate will be important here. Why do you think that intertial navigation is good enough, given that currently position hold drifts around by quite a bit? I want position hold to be as good as those quads in VICON mocap rooms! As for a faster update rate helping the attitude calculation of the quad I don't know - the faster update rate might not buy us anything.

I'll be really keen to see how a properly tuned EKF does position hold just using normal GPS; most of that high-frequency data is captured brilliantly well by the accelerometers and over short timescales, the GPS doesn't actually add that much.  It's actually the same case in a VICON room; we've got one at my Uni and the data is downsampled to 10Hz as anything higher than that and mostly what you're capturing is frame vibration.  In a system with high quality inav I'd back the update rate of the GPS to have a small impact on hold performance compared to, for example, a light breeze :)

Not that 50Hz isn't a good thing but it'll be in order that Gaussian-ish noise is averaged to zero over a shorter time period as opposed to actually getting useful position information at that speed.  Though I suppose some might say it's daft to try and make a distinction there.  Ho-hum.

  --Ben.

 

[Andrew Tridgell]

Hi Niels,

> The Piksi does not calculate a global position to cm-level. It reports two
> pieces of data:
> - standard meter-accurate gps lat-lon
> - vector between the base and rover station that is centimeter accurate.

I hope it is cm accurate, but I'll believe it when I see it!

> The driver can't report a centimeter-accurate global position since it
> doesn't know either of the GPSes to that accuracy

sure, but that doesn't matter. You just lock the position of the base
station at some arbitrary time (say when doing pre-flight cal before
takeoff), then call that your reference position and log it. From then
on you can use lat/lon as int32*10^7 degree positions for
everything. The relative position should be the same accuracy as what
the Piksi gives for its relative position. The global position will be
as accurate as the position you locked at.

> There's actually many use cases where knowing the relative position of your
> vehicle to, say, the starting liftoff point is useful.

sure, but we aren't really discussing whether relative positions are
useful - what we're discussing is what format we transmit them in. If
you transmit your relative position separately from your global position
then a few things happen:

1) you use more bandwidth for transmitting no more information

2) you get an inevitable time difference between your local and global
position samples, meaning post-processing to time shift them together
becomes an issue

3) you need to re-work all users of the more accurate position to
understand both global and local positions

4) in the case where you do have a surveyed antenna position for your
base station then you miss out on having great global positions

Just think of the global positions as local relative positions with an
offset that happens to be the starting position of your base station.

There is one thing we need to do to make this happen though. The
waypoint protocol in MAVLink uses 32 bit floats to represent
positions. We need to create new MISSION_ITEM_INT messages which use 32
bit signed integers (in 10^7 degrees). Otherwise waypoints in missions
will have a precision of around 1 to 1.5 meters, which is obviously no
good. When we change it to int32 we'll get 1 cm precision globally.

If you want to also add a MAVLink message for the base stations
reference position (as int32 lat/lon) then that would be great. Then any
use case that wants base station relative position can easily get it.

Cheers, Tridge

[Fergus Noble]

Hi,

Niels pointed me towards this thread and I though I would join in :). We are also really excited to get Piksi working with APM and want to do what we can to make life easier for system integrators.

The rationale behind keeping the absolute and relative positions clearly separated was to make it very clear how the solutions were derived. People are often unclear about the caveats of RTK GPS systems (i.e. that their excellent accuracy is only in the relative measurement) and we thought that giving people the measurements in their most natural form with no hidden assumptions would be the best thing to do. We didn't want to give people "absolute" RTK positions and them not be aware that they will have a bias of up to several meters.

sure, but we aren't really discussing whether relative positions are
useful - what we're discussing is what format we transmit them in. If
you transmit your relative position separately from your global position
then a few things happen:

 1) you use more bandwidth for transmitting no more information

The bandwidth tradeoff is certainly an issue but we thought that for most systems adding an extra 20ish bytes per solution wouldn't be a big deal.

 

 2) you get an inevitable time difference between your local and global
 position samples, meaning post-processing to time shift them together
 becomes an issue

This is actually not the case, at least for Piksi. The single point and RTK solutions actually use the exact same set of raw GPS observations so they are in fact sampled at exactly the same time.

 

 3) you need to re-work all users of the more accurate position to
 understand both global and local positions  

 4) in the case where you do have a surveyed antenna position for your
 base station then you miss out on having great global positions

Just think of the global positions as local relative positions with an
offset that happens to be the starting position of your base station.

These are good points and we certainly don't want to discourage people from converting back to "absolute" positions if that makes more sense for their particular system. This way you are forced to confront the limitations inherent with a fundamentally relative position solution and decide for yourself what set of assumptions you want to make in the conversion process (i.e. how the reference location is derived). We actually do plan to have the ability to do this conversion onboard Piksi so long as the user explicitly supplies a reference location.

We could make this feature a higher priority if it was needed by APM but it sounds like there are some arguments for being able to support sensors working in a local cartesian frame such as VICON anyway, and if you are moving to an EKF it is a more natural input for that filter without adding a second conversion.

On that note, Ben is spot on in that the inertial sensors and a good filter are much more important than GPS sensor bandwidth for getting really tight position hold. The RTK accuracy will help the filter a lot but the update rate I think will make less of a difference once you are into the 10s of Hz.

I have started playing around with getting SITL to generate Piksi SBP data, if anyone is interested the branch is here:

https://github.com/fnoble/ardupilot/tree/piksi_sitl

One question I had for the developers is what the policy is on external dependencies? The code currently uses libswiftnav which has portable functions for framing SBP together with the message definitions as structs. It would be fairly easy to just copy over the few relevant files but its nice not to duplicate things too much and keep things in sync with the libswiftnav development. Perhaps a build flag for enabling SBP support?

Thanks,

Fergus

--
Fergus Noble

CTO, Swift Navigation Inc.
148 Townsend St, Suite 18
San Francisco, CA 94107

[Jonathan Challinger]

I don't think 10s of Hz are remotely necessary. Even 1hz should be fine. Based on Randy's youtube video, we have 10 seconds of reasonable position just from integrating the accelerometers. Position error is quadratic in time, so over 1 second it is going to have 1/100th of the error that it had at 10 seconds. At 5hz, that's (0.2/10)^2 = 1/2500th. Given a 1m error at 10 seconds, that's 0.4mm.

My conclusion is that 5hz is fine. Tell me if I'm blowing hot air.

I think that it is much, much more important that:

1. We have minimal GPS latency or exactly known latency.

2. Paul have access to the delta- and pseudo- range data so that he can integrate those into the EKF instead of using the NED and lat/lon/alt result from a filter internal to the GPS (the EKF could evaluate each individual satellite and correlate to the accelerometers)

I don't think we need a $500 board (a la piksi) to do those things. I think that we need to find a cheaper GPS that gives us the delta- and pseudo- ranges, and 3DR should adopt it as the 3DR GPS. Piksi has value as an RTK GPS, but I think that a low-cost UAV has needs other than the kind of precision/accuracy that Piksi offers (and hopefully delivers).

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

[Fergus Noble]

Agreed, 5Hz should be fine depending on the quality of your sensors and how well you can estimate the gyro and accel biases.

1) That can be achieved by using the PPS output from the GPS into a capture compare pin on the microcontroller to sync the clocks. It should be quite straightforward to do with any GPS. You would want to do the same with the timing signal from the IMU if possible too.

2) This is referred to as a "tightly coupled" INS and would be really sweet. Its definitely something we hope to work on in the future. That said the biggest gain it gives you is better robustness in marginal GPS environments, i.e. you can drop to 3 satellites and keep solving for your position pretty accurately for a while. Its not going to give you vastly better accuracy than a loosely coupled system where you feed the position solutions and IMU data into the EKF. It also requires a lot more processing power as you now have a measurement per satellite to process in your EKF!

Also agree that there is a lot you can do with a regular inexpensive GPS, we just want to give people an option to do RTK more affordably than is currently possible :)

Fergus

--
Fergus Noble

CTO, Swift Navigation Inc.
148 Townsend St, Suite 18

San Francisco, CA 94107

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/GbLkmEJB0XU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Niels Joubert]

Tridge,

OK, I see what you guys are getting at - we should just use relative locations everythere through the pipeline, and absolute locations can all be made relative to some calibration point.

Here's a concern with that approach: If there is a error in your home location, flying waypoint missions in auto will then propagate that error to every other waypoint. The larger the error, the worse this will be, which seems like a big downside. What's your take on this?

-Niels

[Niels Joubert]

Ben, if that's the case, what prevents these quads from doing a really high accuracy position hold at the moment? All the ones I've worked with that is GPS based drifts quite a bit.

My assumption here is, if I have a higher rate, more accurate localization of the quad, then my control algorithm can do a better job keeping it at a fixed point. Rather than having the GPS signal drift on the order of meters, and having the quad attempt to follow that drifting point, the GPS signal only drifts on the order of centimeters, and the quad can thus have a much better position hold.

In other words - I see that having a well-tuned EKF and excellent IMU is what's necessary to do a high quality position hold, but if that position is drifting drastically in the global frame then so will the quad, and a higher accuracy GPS will prevent that. I do see your argument that just increasing the rate of your GPS won't help, you have to decrease the amount it drifts.

So actually here's a good question: how much of current position hold drifting comes from GPS signals drifting and how much of it comes from noise in the IMU and the filtering/localization algorithms introducing drift?  This is something we should be able to answer in the simulator and thus quantize how well we can do with different GPS accuracy and rates.

-Niels

[Jonathan Challinger]

Better robustness is exactly what we need for copter! No point hovering with centimeter accuracy if it occasionally flies away or has to land.

[Andrew Tridgell]

Hi Fergus, thanks for joining in!

> Niels pointed me towards this thread and I though I would join in :). We
> are also really excited to get Piksi working with APM and want to do what
> we can to make life easier for system integrators.

I think Piksi has huge potential too.

> The rationale behind keeping the absolute and relative positions clearly
> separated was to make it very clear how the solutions were derived.

I actually agree completely with that :-)

I'm not saying that the Piksi GPS protocol on the UART shouldn't
separate relative and absolute positions - in fact I think it probably
should.

What I'm saying is that the APM GPS driver should present absolute
positions to the rest of the APM internals. To make that possible the
Piksi APM GPS driver will need access to the base station reference
position. Is that communicated to the roving GPS using your RTK
protocol?

> People are often unclear about the caveats of RTK GPS systems
> (i.e. that their excellent accuracy is only in the relative
> measurement) and we thought that giving people the measurements in
> their most natural form with no hidden assumptions would be the best
> thing to do. We didn't want to give people "absolute" RTK positions
> and them not be aware that they will have a bias of up to several
> meters.

At the UART protocol level I agree, but for the passing the info onto
the APM driver I think it should give absolute positions, although we
should make sure that the reference position is logged (both over
MAVLink and to the internal logs on SD card) so the relative position
can be determined in post-processing of logs.

> This is actually not the case, at least for Piksi. The single point and RTK
> solutions actually use the exact same set of raw GPS observations so they
> are in fact sampled at exactly the same time.

ok, then that can be a detail the APM GPS driver for Piksi knows about,
and hides the time difference from the rest of APM :-)

> These are good points and we certainly don't want to discourage people from
> converting back to "absolute" positions if that makes more sense for their
> particular system. This way you are forced to confront the limitations
> inherent with a fundamentally relative position solution and decide for
> yourself what set of assumptions you want to make in the conversion process
> (i.e. how the reference location is derived). We actually do plan to have
> the ability to do this conversion onboard Piksi so long as the user
> explicitly supplies a reference location.

I think doing it in the APM Piksi GPS driver is fine too

> I have started playing around with getting SITL to generate Piksi SBP data,
> if anyone is interested the branch is here:
> https://github.com/fnoble/ardupilot/tree/piksi_sitl

Thanks!

> One question I had for the developers is what the policy is on external
> dependencies?

I would prefer that it not depend on libswiftnav, although perhaps not
for the reason you may think.

You may notice that the uBlox and NMEA SITL code doesn't use the AP_GPS
library code, or even the headers for the structures. That was done to
maximise the likelyhood that any breakage of the implementation is
detected. If we used the same structures in AP_GPS and in SITL then if
those structures changed we may not detect that we've broken uBlox
support, as the test would change in the same way as the implementation.

I'm guessing that the swiftnav protocol is just a simple set of
structures, so it shouldn't be too hard to have a copy of those
structures and the marshalling code in sitl_gps.cpp. To make life easier
we're quite happy to use PACKED (which is a macro for
__attribute__((__packed__))) and to assume little-endian. That should
make for very easy marshalling.

It will also remove one small pain point in building SITL on Windows,
MacOS etc, as there will be no need to install the swiftnav library. Is
that ok with you?

btw, with a risk of diverting the discussion a bit, can you tell me if
you have any update on the accuracy of velocity information from the
Piksi? Last time I asked you thought it wouldn't match the uBlox
accuracy. We currently are quite reliant on good GPS velocity in APM.

I'd also be interested in any thoughts from you and Niels on the
transport for the RTK protocol between the ground GPS and the rover.

For the RTCMv2 based DPGS that Ben and I did we added a new
GPS_INJECT_DATA message:

https://github.com/tridge/ardupilot/commit/88eb2cf0c3376f54b613785401752b69111cc232

the contents of that message is opaque to APM, it just passes it through
to the GPS. We marshalled RTCMv2 messages on the ground station, then
send GPS_INJECT_DATA messages up to the aircraft. The aircraft injects
it into the GPS, and the uBlox then processes the RTCMv2. We also ask
the uBlox for DGPS messages, which we then log back via MAVLink and
dataflash to allow us to monitor the status of the DGPS internals of the
uBlox.

Is this similar to what you had in mind for Piksi with RTK, or do you
have another idea in mind?

Cheers, Tridge

PS: You may notice some security implications in the implementation of
GPS_INJECT_DATA ....

[Andrew Tridgell]

Hi Jon,

> I don't think we need a $500 board (a la piksi) to do those things. I think
> that we need to find a cheaper GPS that gives us the delta- and pseudo-
> ranges, and 3DR should adopt it as the 3DR GPS. Piksi has value as an RTK
> GPS, but I think that a low-cost UAV has needs other than the kind of
> precision/accuracy that Piksi offers (and hopefully delivers).

while I agree with some of your points, I think that there isn't any
other GPS on the market or announced that has the potential to give us
the accuracy that Piksi does for below $500.

I don't think doing the RTK solution ourselves in Pixhawk would work. I
suspect that tracking the phase accurately enough for a fast moving and
highly dynamic aircraft would probably be beyond what Pixhawk can do
even if we had a 50Hz capable raw receiver (which we don't).

On the BeagleBone we would have enough CPU to do it, if we could get the
right receiver. I suspect that tightly coupled RTK/INS will be something
that APM on Linux on BeagleBone can do, and would be a great project,
probably using the Piksi as the receiver.

Cheers, Tridge

[Andrew Tridgell]

Hi Fergus,

> 1) That can be achieved by using the PPS output from the GPS into a
> capture compare pin on the microcontroller to sync the clocks. It
> should be quite straightforward to do with any GPS. You would want to
> do the same with the timing signal from the IMU if possible too.

Even if we did this, what lag should we expect from Piksi for its
velocity and position estimates? We currently see about 0.2s lag in
velocity estimates from uBlox by comparing it to the accelerometers.

Cheers, Tridge

[Andrew Tridgell]

Hi Niels,

> OK, I see what you guys are getting at - we should just use relative
> locations everythere through the pipeline, and absolute locations can all
> be made relative to some calibration point.

not quite everythere in the pipeline, it would be fine to have relative
positions in the UART protocol. I just think we should expose global
positions to the rest of APM via the API.

> Here's a concern with that approach: If there is a error in your home
> location, flying waypoint missions in auto will then propagate that error
> to every other waypoint. The larger the error, the worse this will be,
> which seems like a big downside. What's your take on this?

That is a GCS and operator issue really. When the operator sets up the
mission there is no reason they shouldn't say "fly a rectangle relative
to this reference position". The GCS can turn that into global
coordinates before sending over MAVLink to the aircraft.

Cheers, Tridge

[Andrew Tridgell]

> So actually here's a good question: how much of current position hold
> drifting comes from GPS signals drifting and how much of it comes from
> noise in the IMU and the filtering/localization algorithms introducing
> drift? This is something we should be able to answer in the simulator and
> thus quantize how well we can do with different GPS accuracy and rates.

I suspect quite a large part of it (perhaps the majority?) is GPS
position drift. Most of the rest is probably errors in the accel bias
estimates. I'm just guessing though.

Randy, what do you think?

Cheers, Tridge

[Jonathan Challinger]

My point is that the robustness we could gain from tightly-coupling the GPS is more important than the accuracy we could gain from RTK for our purposes. We don't need a 50hz-capable GPS, just a 5hz-capable GPS. I'm not asking for RTK on Pixhawk.

It would certainly make the ekf more complex... I don't know the performance implications, but Paul might. I'm just advocating for my understanding of what he told me, I could be totally off-base.

[Jonathan Challinger]

I would order it this way (most severe first):
1. Position error and jumps
2. Yaw error
3. Accel bias

Hence the need for the EKF (improved yaw) and tight coupling (improved handling of GPS problems)

Of course, vibrations can bump #3 straight to the top.

[Fergus Noble]

On 31 Jan 2014, at 19:52, Andrew Tridgell <and...@tridgell.net> wrote:

> I would prefer that it not depend on libswiftnav, although perhaps not
> for the reason you may think.
>
> You may notice that the uBlox and NMEA SITL code doesn't use the AP_GPS
> library code, or even the headers for the structures. That was done to
> maximise the likelyhood that any breakage of the implementation is
> detected. If we used the same structures in AP_GPS and in SITL then if
> those structures changed we may not detect that we've broken uBlox
> support, as the test would change in the same way as the implementation.

This makes a lot of sense.

> I'm guessing that the swiftnav protocol is just a simple set of
> structures, so it shouldn't be too hard to have a copy of those
> structures and the marshalling code in sitl_gps.cpp. To make life easier
> we're quite happy to use PACKED (which is a macro for
> __attribute__((__packed__))) and to assume little-endian. That should
> make for very easy marshalling.

Yes this is correct, we provide a header file with packed structures assuming you are running on a little endian machine. Should be a simple job to copy over the relevant parts and change them to use your PACKED macro.

> It will also remove one small pain point in building SITL on Windows,
> MacOS etc, as there will be no need to install the swiftnav library. Is
> that ok with you?

Yes I expected that would be the outcome, if I was an APM user I wouldn't want to worry about some strange library used by only a small number of people :)

The only counter-argument is that in using libswiftnav you are using the exact same implementation as used on Piksi (that is quite well tested) so the change of introducing some bugs there is smaller. Also, the protocol is still in draft so if we make any changes you will get the updates for free, although we don't expect any significant changes at this point.

I would say its a tough call but obviously its for you to make

> btw, with a risk of diverting the discussion a bit, can you tell me if
> you have any update on the accuracy of velocity information from the
> Piksi? Last time I asked you thought it wouldn't match the uBlox
> accuracy. We currently are quite reliant on good GPS velocity in APM.

Yes, actually I was working on this a little bit yesterday, sorry it has taken so long. I need to be more testing but with the velocity now derived from the time difference of carrier phase the accuracy is now in the few mm/s range at 1Hz, still need to try it at say 5 and 50Hz but I expect there will be a 1/sqrt(N) relationship in the accuracy where N is the number of milliseconds between samples. This puts it in the same order of magnitude as uBlox but will need to do some more testing to see exactly how we compare.

> I'd also be interested in any thoughts from you and Niels on the
> transport for the RTK protocol between the ground GPS and the rover.
>
> For the RTCMv2 based DPGS that Ben and I did we added a new
> GPS_INJECT_DATA message:
>
> https://github.com/tridge/ardupilot/commit/88eb2cf0c3376f54b613785401752b69111cc232
>
> the contents of that message is opaque to APM, it just passes it through
> to the GPS. We marshalled RTCMv2 messages on the ground station, then
> send GPS_INJECT_DATA messages up to the aircraft. The aircraft injects
> it into the GPS, and the uBlox then processes the RTCMv2. We also ask
> the uBlox for DGPS messages, which we then log back via MAVLink and
> dataflash to allow us to monitor the status of the DGPS internals of the
> uBlox.
>
> Is this similar to what you had in mind for Piksi with RTK, or do you
> have another idea in mind?
>
> Cheers, Tridge
>
> PS: You may notice some security implications in the implementation of

> GPS_INJECT_DATA ….

I haven't given it much thought other than obviously it would be nice to pass the messages up over the same radio link. The GPS_INJECT_DATA message could probably do the job very well. If you made the payload 263 bytes then it could fit a maximum size SBP packet but observations messages will be smaller than the maximum for a typical number of satellites, maybe half that. The observations use the same payload format as RTCMv3 1002 messages which are 64 + n_sat*74 bits long.

Thanks,
Fergus

[Andrew Tridgell]

Hi Fergus,

> I haven't given it much thought other than obviously it would be nice
> to pass the messages up over the same radio link. The GPS_INJECT_DATA
> message could probably do the job very well. If you made the payload
> 263 bytes then it could fit a maximum size SBP packet but observations
> messages will be smaller than the maximum for a typical number of
> satellites, maybe half that. The observations use the same payload
> format as RTCMv3 1002 messages which are 64 + n_sat*74 bits long.

could we break it up? Current MAVLink 1.0 is limited to max 256 byte
payloads, and we like to keep well below that as it eats up memory on
APM2 to have message buffers of that size sitting around.

btw, how does (64+n_sat*74) match up with 263? That would imply 28
satellites. Is there also any checksums or parity bits we could remove?
The MAVLink packet has a CRC.

Or is the SBP not the observation data?

Cheers, Tridge

[Fergus Noble]

I think a <256 byte limit would be fine, 263 is a 255 maximum SBP payload plus the framing overhead. I only suggested that because it would allow tunnelling SBP over mavlink completely generally, and even then we could drop the 16bit CRC and preamble to save a few more bytes.

SBP is used for observations, solutions and status information. Seeing as we are mainly wanting to pass observations and not re-flash the piksi firmware during flight its probably fine to have a lower limit :) Like you say an observations message for say 10 satellites would be 101 bytes, so not a problem.  

Fergus