82 replies to this topic

[peabody124]

So I've checked in the INS/GPS algorithm developed by Dr. Schinstock (Dschin) and it's working pretty well in my hands.

I put a message in the wiki http://wiki.openpilo...d_configuration for how to get it running. I'll be interested in hearing how it performs for people.

[Pip]

Sounds like were getting close to it's first flight!

I would gladly (and would like too) test it all out but the orange LED on the AHRS board I have does not light up at all these days, I still don't have the HMC magnetic chip fitted on the board, which 'may' be the reason?

[dankers]

I suspect it is, it needs the HMC, it would be worth fitting it.

[Pip]

I went for it and fitted the HMC chip, the orange LED is now flashing at a high rate of knotts.

The AHRS board is flat on the table (not moving), GPS is not locked as it can't get a lock in the house.

Here's what I am now see'ing in the GCS ..

AHRS readings

[stac]

With my AHRS in an approximately level and definitely stable position, I see:

• Pitch: continuously rotating so I see 1 rotation about every 16s in this axis
  
• Roll: flips between -90 and +90 as pitch goes through 90
  
• Yaw: flips between 270 and 90 as pitch goes through 90

As far as I can tell, this is indicating that my AHRS orientation is lying on its side and slowly rotating. The flipping of Roll and Yaw sounds like it's probably just showing off gimbal lock (if I'm understand correctly) in the Euler angles. The rotating Pitch and the _values_ of Roll and Yaw seem wrong.

Note that I do not have GPS lock and that I have done a calibration step. I tried repeating calibration to see if it changed and I have managed to sometimes get a slightly more stable Pitch but it just rotates slower.

With the rotation and flipping, the PFD view is a bit disorienting so I may not have the description exactly right.

[peabody124]

Pip and Stac. Did you run the calibration routine with the measure_vars described on the wiki first? One of the things it does is measure the gyro bias term and if that's off it can take a while to converge. Also does it stay like that after ten minutse?

Pip - yeah it's definitely going to lock up without mag. Once it's working in normal conditions we'll think how to do a self test operation.

Also Stac with the I2C driver - could we actually implement a timeout when it's spinning in the I2C driver for too long? In other news I left mine with GPS lock and I2C and flight time was what I expected when I woke up, so I'm not seeing that issue you are.

[Pip]

I did try to do the calibration, but where it says the AHRS LED should stop flashing and go out for 5 to 10 secs or so, it does not, it continues to flash at a high rate.

I've entered the XYZ values as shown in the picture then clicked SEND, but no apparent difference.

Attached Thumbnails

• 

[peabody124]

I bet you're using USB? If so then it doesn't send the AHRSCalibration because it's > 62 bytes. I need to implement a circular sending buffer (on my todo list).

If not you set measure_var to true before sending and it didn't flash?

[Pip]

I am using USB yes.

I'll see if I can find the RS232 adapter and try it again via an RS232 port.

[Pip]

That looks better! .. Now using the serial port connection and not the USB port.

The AHRS led went stable for 5 to 10 seconds this time in the calibration (sometimes it stays OFF for 5-10 secs, sometimes it stays ON for 5-10 secs).

In the following video the AHRS board is flat on the table, I then turn it on it's side so that it's at a 90deg angle, then back flat again, then onto it's other side. Then the same again using the SIMPLE algorithum.

AHRS readings

[peabody124]

Cool. I really want to fix that USB bug because I like debugging over USB (really also want to add a virtual comm port to the descriptor too for debugging output) but it's a slightly lower priority that AHRS.

Once the calibration configuration is easy then that bias you are seeing when it's flat will go away too. Although from looking at it you go flat in simple so it's probably not an accel bias. Did you configure the right magnetic field?

[Pip]

Well those magnetic field values I took from the X, Y & Z lines on the map webpage you point us towards to get them. I guess they were the correct lines to copy into the 0, 1 & 2 entries?

[peabody124]

Yeah they should be - certainly my ones computed on the OP are a close match to the map. Puzzling.

[Edouard]

Pip, on 23 August 2010 - 12:36 PM, said:

I went for it and fitted the HMC chip, the orange LED is now flashing at a high rate of knotts.

The AHRS board is flat on the table (not moving), GPS is not locked as it can't get a lock in the house.

Here's what I am now see'ing in the GCS ..

AHRS readings

Pip: I'm seeing exactly the same kind of tilt, but it goes away with the Simple algorithm. Same for you?

[peabody124]

I'm pretty sure this is coming from the mag in both cases. The mag has a pretty low variance like the accel, so since we don't correct for mag bias right now that's likely to be the cause. The attitude in INSGPS is much more weakly driven by accel's for gravity than simple (where it's all of it) because it is designed to track well under high acceleration.

[peabody124]

Ok, I've checked in a 6 point calibration routine. I want to change it so it collects a bit more data in each orientation to average, but see the Wiki link above for instructions on how to use it. Let's see if this calibrates out the tilt (or makes it work - please take before and after notes in case I have any sign reversal's I missed).

[peabody124]

Also from talking with Edouard we realized that having a _poor_ GPS fix is the worst thing for stability because it tries to use position for a correction and things don't make sense. We'll update that shortly but for now either get a good lock or just set the Be field in HomeLocation and Set to TRUE.

[Jonathan Brandmeyer]

Quote

Also from talking with Edouard we realized that having a _poor_ GPS fix is the worst thing for stability because it tries to use position for a correction and things don't make sense.

There is an optimization opportunity here. A GPS-INS can use a poor GPS fix for attitude information, but only if you are honest about how poor the estimate is. Ideally, the GPS's report should have fairly high error bounds with zero smoothing in its internal KF. Depending on your level of access to the GPS firmware, you may be able to approximate that ideal by raising the acceleration uncertainty in the GPS's internal KF implementation. For example, if the internal software architecture is similar to the one exposed by the Fastrax iTalk protocol, you would raise KLM_ACC_NOISE (and maybe KLM_ACC_VERT_NOISE) to somewhat high values, maybe 4-6G in the horizontal plane and 2G in the vertical direction. That way you are relying more on the acceleration reported by your AHRS accel's for this data.

[peabody124]

Jonathan Brandmeyer, on 31 August 2010 - 07:16 PM, said:

There is an optimization opportunity here. A GPS-INS can use a poor GPS fix for attitude information, but only if you are honest about how poor the estimate is. Ideally, the GPS's report should have fairly high error bounds with zero smoothing in its internal KF. Depending on your level of access to the GPS firmware, you may be able to approximate that ideal by raising the acceleration uncertainty in the GPS's internal KF implementation. For example, if the internal software architecture is similar to the one exposed by the Fastrax iTalk protocol, you would raise KLM_ACC_NOISE (and maybe KLM_ACC_VERT_NOISE) to somewhat high values, maybe 4-6G in the horizontal plane and 2G in the vertical direction. That way you are relying more on the acceleration reported by your AHRS accel's for this data.

Yeah I actually checked in a fairly similar algorithm last night (variance scales linearly with sum of DOP values) although it's crude and need's fine tuning. According to Dschin he doesn't think those estimates of variance will actually be accurate enough though and we'll probably just apply a threshold where a poor GPS lock doesn't trigger an EKF correction step on GPS, just Mag's. There's also an "Indoor mode" which will switch to updating at 0,0,0 with a high variance to say "same place on average" which is still technically incorrect for a few reasons. I think this will end up being empirical.

See http://progress.open...omment-tabpanel

[Jonathan Brandmeyer]

Quote

According to Dschin he doesn't think those estimates of variance will actually be accurate enough though

While operating outdoors, you might be able to recover the entire GPS fix covariance matrix in a manner similar to what gpsd does for some receivers.