NASA competition - suitability of AQ6 or M4

[JussiH]

Pls send me a PM to arrange the HW

Jussi

[Max]

[Kisssys]

I agree with Max on the M4, the AQ6 is better for your purpose. The AQ7 is probably the perfect choice with a Gumstix to run your algorithm but that's all very virgin ground.

[flomartel]

Thank you all for the information provided! I will need some more time to study it...

[flomartel]

I'm starting to setup my build environment and will soon attempt to compile and upload an unmodified firmware onto the AQ at first.

On a somewhat separate note, I am also looking at possibly implementing an AGL sensor with the AQ. The obvious functionalities are precision landing and flying at a set altitude above ground. Has any of this work been done for a sonar/lidar?

I noticed a separate UKF has been added lately for the altitude ("alt_ukf") that uses measured downward acceleration integrated over time for the prediction step and measured barometric pressure converted to an altitude value for the correction step. The resulting ALT_POS and ALT_VEL state estimates are used when gpsData.hAcc (horizontal accuracy estimate contained in the NAV-POSLLH uBlox message) > 0.8 meters. Otherwise, UKF_PRES_ALT (the 17th state estimate - navUkfData.x[16] - of the nav filter) and UKF_VELD (the 3rd state estimate) are used since USE_PRES_ALT is set to 1 by default.

So, what I understand from this is that when the reported horizontal (why not vertical?) accuracy of the GPS measurements is insufficient, ALT_POS and ALT_VEL are used, otherwise UKF_PRES_ALT and UKF_VELD are used. I looked at the equations and the state estimates are calculated a little differently between the two filters (initial values are the same), but I’m struggling to understand why. For example, barometer bias is taken into account in the altUkfTimeUpdate but not the accelerometer bias. Another example is that measured downward acceleration integrated over time for the prediction step (“acc”) is divided by two in the alt UKF but not in the nav UKF. More fundamentally, I don’t get why there’s a separate alt UKF coded for when GPS performance is degraded (or in a GPS denied environment) since UKF_VELD is not determined using GPS height anyways. Is it linked to the use of “navData.presAltOffset” which adjusts pressure altitude for waypoint navigation when there’s a good GPS fix?

I’m not intimately familiar with UKFs, and I haven’t taken the time to reconstruct all the equations, so I may be a little over my head. I do want to learn how it all works...

How were the process and measurement noise values for the altitude and vertical velocity for both the alt and nav UKFs determined (there’s a bunch of them)? I’m trying to find what kind of specs/measurements I would need to find out about the sensor I would like to integrate to determine some decent noise values to use.

[bn999]

[flomartel]

[bn999]

[zhlearnaq]

hello,
Could anybody tell me the frequency of the attitude calculation - the value of AQ_OUTER_TIMSTEP? Is it a fixed value?

[zhlearnaq]

hello,
Could anybody tell me the frequency of the attitude calculation - the value of AQ_OUTER_TIMSTEP? Is it a fixed value?