Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VTOL Model Specific Attitude Estimator / INS #2260

Open
peabody124 opened this issue Jan 11, 2017 · 1 comment
Open

VTOL Model Specific Attitude Estimator / INS #2260

peabody124 opened this issue Jan 11, 2017 · 1 comment

Comments

@peabody124
Copy link
Contributor

I've been increasingly pleased with the performance of the multirotor model in system identification and LQG (#2237). Historically despite a lot of work on the INS (#1506), I feel like it is still somewhat performance limiting. This comes from a number of issues including accuracy and reliability of the magnetometer. However, it also comes from the fact the filter was designed to be model agnostic so discards a lot of information that could be quite informative (e.g. the attitude and rate).

Now that we can estimate the parameters for it (e.g. SystemIdentification), it would be good to extend this to a model-based estimation algorithm from what is used in LQG (just instantaneous torque and rotation rate) to the full state estimate of attitude and position. This would get rid of the arbitrary segmentation of the filter between one for the low level rate/torque and another for position and estimation, and should improve performance by utilizing more information. It should also outperform the existing complementary filter, even when not utilizing a GPS, as it will account for how the thrust should bias the attitude estimate. This should improve perform of things like altitude hold in fast forward flight.

@peabody124
Copy link
Contributor Author

For what it is worth whenever I watch some of the commercial devices using position hold and delve into the raw logs from navigation (e.g. the GPS wander) I've become completely convinced this is what they are using under the hood. Superficially, this will likely not increase the complexity of the filter as we will still be using a 14 state estimate, although it will probably want to run faster as we will need to clock it at the gyro rate. I suspect for really good navigation performance, integrating a wind model will also be important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant