Jump to content


Photo

AHRS accuracy (time and space)


  • Please log in to reply
8 replies to this topic

#1 EldenC

EldenC

    New Member

  • Members
  • Pip
  • 4 posts
  • Country: flag of United States United States

Posted 23 February 2010 - 11:59 PM

How accurate do you believe the accuracy of the GPS+AHRS will be? Right now, I use paparazzi on a fixed wing Twin Star, but found that my landing site is not big enough to deal with the GPS/flight errors. From what I've heard, a runway 200m is required to land (I've always bailed out and landed manually myself). But paparazzi's gps is 250milli second report rate with 10meter error bubble vs. OpenGps's 100milli second report rate with ??? meter error bubble, but I think still too big for me (hill, 40 meter flat spot, valley).

I realized this is dependent on a lot of factors...but off the cuff,

If an accurate position (+/-5cm) can be determined at one point during the flight, what will the AHRS's error be 5 seconds later, 20 seconds later, etc? Or is the AHRS only intended for stabilization, not long term position?

#2 Angus

Angus

    Core Developer

  • Members
  • PipPipPip
  • 224 posts
  • Country: flag of Australia Australia

Posted 24 February 2010 - 04:44 AM

The OpenPilot GPS update rate is 10Hz, so 100ms between updates. Error (or EPE) varies with how many satellites you have and is usually somewhere between 2-15m.

The AHRS is not a dead reckoning device, meaning it does not track position in space, it only tracks attitude (pitch/roll/yaw) and the heading.

For a multirotor aircraft landing is easy, you can do it in a 1m diameter column of air/ground if you wish. Planes are harder to do auto-land on. With paparazzi it doesn't really "land" so to speak, it more does a controlled decent into terrain, which is why it takes quite a lot of runway.

#3 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 24 February 2010 - 04:49 AM

Welcome Elden!

I am also a Paparazzi user and love the coolness of the auto-landing feature and I think they do a great job with what they have available. However auto landing in Paparazzi is based purely on the GPS, they have trust it for position like we do but they also have to trust it for height and speed information. Given this they are very cautious with auto landing and make sure they are getting stable information from the GPS, hence autoland needs a big area. The Paparazzi auto landing code is excellent, the downside for Paparazzi is their sole reliance on the GPS.

We have a couple of advantages, first we have an on board pressure sensor to determine hight which is very accurate, our GPS is a 10Hz unit and updates 2.5 time faster than the standard u-blox used on on the Paparazzi Tiny hence our real time position information from the GPS is more accurate. For aircraft use we will also use an airspeed sensor which most Paparazzi users don't use (one of the founders of OpenPilot added that code to Paparazzi last year), so yet again we can get a better sense of what the aircraft is actually doing than just relying on the GPS like Paparazzi does.

Saying all this, the AHRS doesn't factor much in to this, the AHRS is basically a replacement for the thermopile sensors on the Paparazzi and gives us much more flexibility, thermopiles are not so great at flying other kinds of aircraft like Quads or helis and they are also covered by a dubious patent as well.

As you might or might not know, OpenPilot is starting with Quad rotor craft, if you fly in a small area and want to land in exactly one spot, a Quad would be ideal for this as the worst case it will land 5 meters from where you tell it but generally within 1 meter. Another innovation that we thought about for OpenPilot is a ground sense switch when flying a Quad or a heli, this is just a simple switch that goes on the skids and when contact with the ground is made on auto landing, the OpenPilot knows about it.

How accurate do you believe the accuracy of the GPS+AHRS will be? Right now, I use paparazzi on a fixed wing Twin Star, but found that my landing site is not big enough to deal with the GPS/flight errors. From what I've heard, a runway 200m is required to land (I've always bailed out and landed manually myself). But paparazzi's gps is 250milli second report rate with 10meter error bubble vs. OpenGps's 100milli second report rate with ??? meter error bubble, but I think still too big for me (hill, 40 meter flat spot, valley).

I realized this is dependent on a lot of factors...but off the cuff,

If an accurate position (+/-5cm) can be determined at one point during the flight, what will the AHRS's error be 5 seconds later, 20 seconds later, etc? Or is the AHRS only intended for stabilization, not long term position?



#4 EldenC

EldenC

    New Member

  • Members
  • Pip
  • 4 posts
  • Country: flag of United States United States

Posted 24 February 2010 - 05:13 PM

Thanks for the info and a great project.

For a bit, I thought my work on the WiiMote Camera Landing system that I'm going to put into paprazzi was going to be OBE. But it may still have use. The majority of the algorithms will be independent of the ppz and since you already have i2c, integration into OpenPilot should be easy. I believe that I can get position accuracies of better than 10cm @ a rate of up to 5ms (depending on how fast the CPU is at floating point cosine and sqrt, which I use a lot of.) for a limited set of positions/attitudes in space with the cheap and light WiiMote camera. (The positions/attitudes happen to be those going down the the 'runway' :-).

To date, I don't know how to assign the i2c addr of the camera, so I can only have one per bus, but it does have a chip select.

To allow for more than one wiimote camera, how many i2c interfaces does OpenPilot have? Or perhaps chip selects?
(I guess the better question is, where are the schematics? (pdfs?) I didn't see them in the repository.)

#5 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 24 February 2010 - 06:54 PM

Angus can send you the schematics as they currently stand, we are slowly verifying each subsystem works but as you might have seen elsewhere we have some I2C issues that we need to sort out asap. There are two I2C on the chip we use but not sure how these are broken out, not my field really, Angus can answer more.

Your project sounds awesome! Sorry to mention Quads again but it could be very useful there as well, very very useful actually. Of course Quads hover and they rely on GPS for position hold which is good but not perfect. One of the ways around that is to use visual cues to provide exact hover location by a visual means. I am not an expert in this at all, Angus knows more for sure as it is something he has talked about. I believe the DIYDrones Podcast covered the Parrot.AR mini quad which uses visual cues for positioning.

This is the mp3 in case you have not heard it, I actually haven't so I could be wrong here.



There are also a couple of helicopter training aids which I forget the name of that also use visual cues for hover position.

#6 Angus

Angus

    Core Developer

  • Members
  • PipPipPip
  • 224 posts
  • Country: flag of Australia Australia

Posted 25 February 2010 - 08:49 PM

Angus can send you the schematics as they currently stand, we are slowly verifying each subsystem works but as you might have seen elsewhere we have some I2C issues that we need to sort out asap. There are two I2C on the chip we use but not sure how these are broken out, not my field really, Angus can answer more.

PM Sent!

An I2C device shouldn't have a chip select, normally that would be something like an SPI device. There is only 1 accessibly I2C bus on the OpenPilot so to attach more than one device with the same address would cause problems.

Some I2C devices/modules (actually most) will have a jumper/short or something inside them to select between different addresses, it's possible something like this could exist on your device.

#7 alex

alex

    New Member

  • Members
  • Pip
  • 4 posts
  • Country: flag of South Africa South Africa

Posted 11 March 2010 - 06:20 AM

Are there any plans for implementing GPS/INS?

For those who dont konw(i guess everyone does), basically you use dead reckoning to measure aircraft position and then use the GPS signal to correct position every second or less. I have only ever implemented this in matlab at uni so I don't relay know about the real world application complications. I guess that this is something that would be implemented on the main board side of things and not on the AHRS, cuz then it would not be an AHRS anymore :P Am i correct when i say other autopilots like ardupilot/UAV dev board are only using GPS for navigation? and then use the AHRS/thermopiles just to stabilise?

#8 Angus

Angus

    Core Developer

  • Members
  • PipPipPip
  • 224 posts
  • Country: flag of Australia Australia

Posted 11 March 2010 - 07:06 AM

Am i correct when i say other autopilots like ardupilot/UAV dev board are only using GPS for navigation? and then use the AHRS/thermopiles just to stabilise?

That's correct, the position on space is determined by the GPS and barometer (for higher accuracy altitude). How the aircraft is oriented in that #D space is determined by the AHRS/Thermopiles.

An INS is not out of the question, I think we have the processing power to do it, it would depends on how accurate the sensors are.
I think you would still want to integrate GPS at 5Hz or 10Hz, but in the event of a GPS lockout you would be able to dead-rekon for a while.

#9 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 11 March 2010 - 01:18 PM

There is a bit more to this as we have been a bit cleaver here. Strictly speaking the AHRS would become a INS if we have GPS connected to it, this doesn't really let us do some cool things though and is not optimal nor as flexible as the way we decided to go. I think we can agree that the AHRS is going to be busy with some serious filtering, but parsing GPS NMEA sentences is also a load on the cpu especially at 10Hz. So the approach is to have the OpenPilot board parse the GPS and handle things like how many satellites are in view and all that stuff, however, we can pass the minimal required and already decoded GPS data back to the AHRS over SPI in a more efficient binary form. This way we get the most use out of the two cpus and also the most flexibility, initially we will fly without a GPS just to get flight stability right, if we used a pure INS approach from day one then it would add to the time required and the hardware required just to get in the air. This way we don't need an more powerful cpu on the AHRS but we can still implement a dead reckoning INS in the future and by that time will will know how accurate the sensors are.

Ardu is a bit of a special case, it also uses the GPS for yaw bias as well because parts of DCM as not there for this but yeah, as Angus says GPS is the sole means it uses to locate its position in 3D space including its only means to measure altitude. For speed of course it has GPS for ground speed and a pitot for airspeed.


That's correct, the position on space is determined by the GPS and barometer (for higher accuracy altitude). How the aircraft is oriented in that #D space is determined by the AHRS/Thermopiles.

An INS is not out of the question, I think we have the processing power to do it, it would depends on how accurate the sensors are.
I think you would still want to integrate GPS at 5Hz or 10Hz, but in the event of a GPS lockout you would be able to dead-rekon for a while.