uNav AHRS
- Thread starter brtaylor
- Start date
- Status
defragster
Senior Member+
As Mike noted - INS9State_V11 just works with SPI_MSTransfer16 per post #796 - when both M & S are recompiled.
I noted there the two changes I made at the end of that post.
I should revisit the examples to keep the current default message PacketID #55 free from confusing debug - odd enough packing the stuff on one end and then doing the output on the other and keeping them in sync. Looking to add a second one to accept that will be the Debug that 'Master' will use separate from the one feeding 'INS9State_V11' as Master - that will also show how a future message could be done if there end up being OLD and NEW or different setting to TVIewer - without ruining the existing one that may work in some cases.
defragster
Senior Member+
Indeed - that Slave needs DEBUGHACK commented. I was about to upload the version of that with it off when Tony uploaded the other and didn't want a double post of similar.
If I get to the post #802 noted Edit I'll make the Slave respond uniquely to the Messages #55 being the TViewer proper output and then another so the Slave will be ready for either without recompiling it.
If I get to the post #802 noted Edit I'll make the Slave respond uniquely to the Messages #55 being the TViewer proper output and then another so the Slave will be ready for either without recompiling it.
mjs513
Senior Member+
Don-Tim
In case you are interested, I went back to Watson's thesis implementation of the EKF and think I got the drifting fixed on that one. Had to do a bunch of tuning though. The changes are noted in the ExtendedKalman.cpp file. I am attaching two zip files, one with the sketch and the other with the updated library. If you give it a try let me know how it works out.
Just as a note I also tried the uNavAHRS and no matter what I did could not get the drift to stabilize. This included periodic gyro bias updates based on temperature or time, and accelerometer temp cal curves. Some thing else must be going on. Maybe the initializations for Q,R and P.
EDIT: almost forgot think still have an axis alignment to solve with Watson's paper and current set up but that's next step. Priority was yaw drift
Mike
In case you are interested, I went back to Watson's thesis implementation of the EKF and think I got the drifting fixed on that one. Had to do a bunch of tuning though. The changes are noted in the ExtendedKalman.cpp file. I am attaching two zip files, one with the sketch and the other with the updated library. If you give it a try let me know how it works out.
Just as a note I also tried the uNavAHRS and no matter what I did could not get the drift to stabilize. This included periodic gyro bias updates based on temperature or time, and accelerometer temp cal curves. Some thing else must be going on. Maybe the initializations for Q,R and P.
EDIT: almost forgot think still have an axis alignment to solve with Watson's paper and current set up but that's next step. Priority was yaw drift
Mike
Last edited:
defragster
Senior Member+
Nice Mike. Assuming the TViewer output unchanged with the order, number, mods to the Format/Display SerialPrint?
For reference - the SPI_MST_V0.0.16 seems to be the good F&F version for getting that offloaded to Slave. A new version to work on T_3.2 may be pending with only one set of #ifdef's needed to account for # of Serial's on a given Teensy.
I strapped together a twinned side by side T_3.6 and T_3.1 with it ran zero errors overnight at 500 TViewer messages and 10 LED toggles per second at 30 MHz SPI. Now I can compress and do that with the MPU/GPS T_3.6&T-3.5 pair. Also need to present a TV_Slave and TV_Master Sketch pair that is cleaner with distinct DEBUG versus REAL messages for maintainability.
<EDIT>: Tony just posted MST_V_0.1.0 that should be good for baseline usage: Project-SPI_MSTransfer
For reference - the SPI_MST_V0.0.16 seems to be the good F&F version for getting that offloaded to Slave. A new version to work on T_3.2 may be pending with only one set of #ifdef's needed to account for # of Serial's on a given Teensy.
I strapped together a twinned side by side T_3.6 and T_3.1 with it ran zero errors overnight at 500 TViewer messages and 10 LED toggles per second at 30 MHz SPI. Now I can compress and do that with the MPU/GPS T_3.6&T-3.5 pair. Also need to present a TV_Slave and TV_Master Sketch pair that is cleaner with distinct DEBUG versus REAL messages for maintainability.
<EDIT>: Tony just posted MST_V_0.1.0 that should be good for baseline usage: Project-SPI_MSTransfer
mjs513
Senior Member+
Didn't put this version of the KF (no ins) in the same format as the INS yet. Wanted to get it tuned and bugs out first before I spent time reformatting for SPI_MSTransfer. Posted what I have to see what you all thought.
I just saw in the other thread that v0_1_0 was released and will update.
TV_Slave and Master would be nice to keep things clean from the other examples. Beginning to get confused on which versions do what - have to do some reorganizing and archiving today before I start changing my setup to T3.5/T3.2.
Mike,
Have you checked out Jook Brokking's website (http://www.brokking.net), and then his series of youtube videos? His videos are fantastic. I built two drones mainly based on his designs (about $200 each) a year or so ago, but since then have stepped it up to using the PixHawk flight controller. I do really like that Drotek flight controller you pointed out too, but have a lot invested in my current setup now though!
Have you checked out Jook Brokking's website (http://www.brokking.net), and then his series of youtube videos? His videos are fantastic. I built two drones mainly based on his designs (about $200 each) a year or so ago, but since then have stepped it up to using the PixHawk flight controller. I do really like that Drotek flight controller you pointed out too, but have a lot invested in my current setup now though!
mjs513
Senior Member+
Yup. Saw the YMFC-AL and kind of liked it. Keep toying with the idea but keep getting sidetracked if you know what I mean. It would be easy to substitute a teensy 3.5 into that system . Just came across this as I was typing, curiosity always gets to me - https://diydrones.com/profiles/blogs/hackflight-teensycopter.
. Just came across this as I was typing, curiosity always gets to me - https://diydrones.com/profiles/blogs/hackflight-teensycopter.my car runs off a Teensy, literally. It controls the majority of the "accessories" including the radio, windows, wipers, trunk, doors, (converted analog ->digital climate system), alarm system, transponder system <--so yeah, even with an original key you wont be able to start it
even has gear position status and canbus dual network interface with dual touchscreen and 13.2" tablet in dash
![2poz6ky[1].jpg](https://forum.pjrc.com/data/attachments/11/11582-4ddcfc8d163bf0a36c8e11e6c8d60f2c.jpg "2poz6ky[1].jpg")
yeah theres the arduino IDE in background, thats for reprogramming the teensy lol
even has gear position status and canbus dual network interface with dual touchscreen and 13.2" tablet in dash
yeah theres the arduino IDE in background, thats for reprogramming the teensy lol
mjs513
Senior Member+
Don - Tim - Brian
I think I managed to get the uNAVAhrs version semi working. I added in two modules, one the 9250 library, calGyroFast which allows you to specify the number of points to redo the calibration, the second is a motion/no-motion function that I added to the sketch. So right now I call the calGyroFast function every second if the Temperature <30C and there is no motion. This is just a test, will probably need to refine it later. I am attaching the sketch in case you want to give it try with you MPU-9250 modules.
I am using Logging Library that you will need, https://github.com/thijse/Arduino-Log.
Cheers
I think I managed to get the uNAVAhrs version semi working. I added in two modules, one the 9250 library, calGyroFast which allows you to specify the number of points to redo the calibration, the second is a motion/no-motion function that I added to the sketch. So right now I call the calGyroFast function every second if the Temperature <30C and there is no motion. This is just a test, will probably need to refine it later. I am attaching the sketch in case you want to give it try with you MPU-9250 modules.
I am using Logging Library that you will need, https://github.com/thijse/Arduino-Log.
Cheers
mjs513
Senior Member+
Sorry - couldn't edit previous post to add this test run. While the fix above is not perfect in its present state at least there is not the continuous drift that we saw before. There are a couple more things that can be done to tweak it, that will work on and off. Here is the test run that I just completed:
Note: with Watson's implementation I did not see this temp dependence.
Note: with Watson's implementation I did not see this temp dependence.
mjs513
Senior Member+
Have fun with the sketches Don.. Not really happy with the performance of uNAVAHRS - something else has to be on. Maybe its the update only periodically - don't know. Watson's was a better but I didn't extensive testing - hoping maybe for some feedback on how its working - that one is actually easier to tune. Put some notes in the .h or .cpp file (forgot which). Have a bunch of coals in the fire.
BTW. How did your testing go? Hope it was a success.
BTW. How did your testing go? Hope it was a success.
Thx, will try them out, likely over the weekend.
Testing went fairly well. We flew the 550 drone I built and got RTK Float (carrier phase ambiguity not resolved) easily, but again never transitioned to RTK Fixed (ambiguity resolved). We're thinking that this may just be an issue with the PixHawk2.1/Here+ system. That particular client has a Phase I project starting where we'll need to build five RTK drones, so we'll be looking for an alternative to Here+. DroTek might be an option, as are a couple of other like systems. By the way, one recent study found that RTK Float gave 50-70cm accuracy, whereas RTK Fixed was 5-20cm, so we really need to be in RTK Fixed mode reliably.
Testing went fairly well. We flew the 550 drone I built and got RTK Float (carrier phase ambiguity not resolved) easily, but again never transitioned to RTK Fixed (ambiguity resolved). We're thinking that this may just be an issue with the PixHawk2.1/Here+ system. That particular client has a Phase I project starting where we'll need to build five RTK drones, so we'll be looking for an alternative to Here+. DroTek might be an option, as are a couple of other like systems. By the way, one recent study found that RTK Float gave 50-70cm accuracy, whereas RTK Fixed was 5-20cm, so we really need to be in RTK Fixed mode reliably.
brtaylor
Well-known member
Integer ambiguity is tough! The only time I had experience with it was with all the receivers on the aircraft (trying to get attitude directly with multiple GPS receivers). Had to keep the baseline small to resolve the integer ambiguity more quickly; worked fine on the ground, but as soon as we launched the aircraft, the integer ambiguity would come back and we'd lose the solution. Later a bunch of analysis should that it always occurred when we were pitching or banking the aircraft such that the receiver would be blocked from looking south by the wing or fuselage. Never tried it with a fixed base or with one of the off the shelf solutions; was hoping it would be more plug and play at this point for those conditions. Especially with uBlox and others having products that claim to work with a fixed base.
Brian,
Yes, thought it would've been bit more plug-n-play, but not finding that with the PixHawk/Here+.
Mike,
The rtkexplorer site is interesting, I've been following it some, but thinking we're actually needing something a bit more off-the-shelf vs. using RTKLib. Although that may be our backup if no one seems to have a more off-the-shelf solution!!
Don
Yes, thought it would've been bit more plug-n-play, but not finding that with the PixHawk/Here+.
Mike,
The rtkexplorer site is interesting, I've been following it some, but thinking we're actually needing something a bit more off-the-shelf vs. using RTKLib. Although that may be our backup if no one seems to have a more off-the-shelf solution!!
Don
- Status