uNav AHRS

Status
Not open for further replies.
Don
Didn't mean for rtklib to be a final solution, but more of comparison of the different rtk units out there and maybe provide some guidance on settings that you could potentially use in your rtk setup..
Mike
 
Mike,
Yes, I can see where RTKLib would be really helpful in analyzing the raw files for troubleshooting. When I can carve out time, I need to download it and test it out. Next rtk thing I'm setting up to try is to use one of the CORS rtk sites' data as my base station and see how that works.

But hoping to get time today or Sun to try out your Watson EKF version!
Don
 
Don
I have been using CORS rtk sites in a lot of my tests. Works well for me, I have one or two within 10miles of my house. So its a win-win. Real easy to get an account. You can get real-time data and download files for post-processing later on as well. :)

Don't worry about the KF code - no big rush. Have fun with rtk.

Mike
 
Mike,
Cool, might be getting back to you on how you got the CORS rtk up and running. Hopefully I can figure it out.

Downloading the Watson EKF now...
Don
 
Mike,

Got your Watson 7-State running. Like I think you mentioned, looks as tho the axes orientation is off, need to think about it some...
Don
 
Don,
Thanks for checking the Watson 7-state for me. Haven't touched it since I posted. Been working on a couple of things. Besides the axis being off, hows the yaw stability.

Mike
 
Mike,
I'm trying the uNavAHRS sketch right now. It says MovingAvarageFilter.h missing. Is that a separate library you were using for the motion detect?

On the Watson, I haven't been able to resolve the axes misalignment. Tried a couple simple things, but decided to move on to the uNavAHRS until I think about it some more.
 
Mike,

Getting it to compile and upload, but not getting anything on the slave terminal. Will look at again tomorrow, might have something in configDefines off or maybe I have older version of slave or the SPI library.
Don
 
Mike,
EDIT to last post... I am seeing the values in my Serial terminal now, not sure what I had wrong. Will check it out more tomorrow.
Don
 
Last edited:
Hi Don,

Sorry I didn't get back to you sooner been distracted to day to say the least. Yep, for the Watson the only I dumped to Tviewer was yaw, pitch, roll and heading. Heading is just zero for now as I didn't add that code yet. Before i spent anymore time on it wanted to make sure was going done the right path.

Thanks for taking the time to check it out. A lot has been going on with the SPI_MSTransfer library. Some amazing stuff.

Mike
 
Putting some hooks into uNavAHRS so I can see how the states, residuals, and noise terms (Q,R) are behaving.

An interesting thing I noticed on the serial printout is that about 1-2% of the time the filter does propagate-only (no accel or mag update), about 10% of the time the filter does a propagate with both accel and mag update, and the rest of the time (~85% or so) it does a propagate with an accel-only update. This is just a rough guess until I get the analytics hooks into uNavAHRS...

Don
 
Hey Don.
This is going to get interesting. I would of thought that updates for all the sensors would occur more frequently. It could be why the yaw is drifting so much. I did have some success if just setting mag = true.

Mike
 
Mike,
When I send data to the serial, I'm doing it at maybe 25ms intervals or greater I think (the printRate interval you all set up).

With the SPI work tonton81, you, Tim, and others are doing, do you think we'll get to where we can store all the IMU filter updates in realtime? Maybe including 25 or so filter parameters?

With the serial streaming I'm doing now, I'm guessing I catch a percentage of the data, but for analysis it would be slick to be able to create raw data files without missed filter updates.

Don
 
Don
I think it depends on whether you want to store it to an SD card or just write the data to a pc file as it is streaming. 99.99% sure the SPI_MSTransfer library will be able to handle it. Think the only limiting factor will be the latency in writing to an SD card if you want to go that route. I know Tviewer will handle a ton of data and can keep up with what you are streaming. It also has a save function for later analysis. It saves everything not just what you see on the screen.

So long story short - don't know why not. 25 parameters should not be the issue.

Mike
 
Mike,
Great! I was actually thinking that it's ok if there are some missed data for real-time displaying, but would be slick if all the data could be stored for "post-mission" analysis. So sounds doable.

Don
 
Don Kelly said:
Putting some hooks into uNavAHRS so I can see how the states, residuals, and noise terms (Q,R) are behaving.

An interesting thing I noticed on the serial printout is that about 1-2% of the time the filter does propagate-only (no accel or mag update), about 10% of the time the filter does a propagate with both accel and mag update, and the rest of the time (~85% or so) it does a propagate with an accel-only update. This is just a rough guess until I get the analytics hooks into uNavAHRS...

Don
Click to expand...

One thing it seems { i.e. bad terminology and limited understanding of the internals } onehorse did in his writings was note that the process was successive approximation in some fashion - it would iterate again with perhaps no new data. And of course some data arrives at different rates: IMU incoming { accel and gyro ?} is a multiple of the MAG rate.

It seems - any new data should be incorporated in delta time order - but it left the idea that when time allowed re-running to further the approximation?

With the SPI connect to a SLAVE - It may be possible that all incoming data could be time stamped and shipped to a Slave to log to SD for late replay analysis in some fashion.
 
elapsedMillis does not seem to be printing to serial at our desired "printRate" rates. First of all, it seems to execute more reliably (not lock up) if I hard code in the time interval rather than using "#define printRate 100"

second, the elapsed time is not coming out correctly. For example:

for 100ms elapsed time, I get prints to serial at even 120ms

for 25ms elapsed time, I get prints to serial at even 40ms

for 50ms elapsed time, I get prints to serial at even 60ms

for 20ms elapsed time, I get prints to serial at even 40ms

for 75ms elapsed time, I get prints to serial at even 80ms

So seems very weird. Think I'll set up a timer without using elapsedMillis and see what happens
 
I'd have to see context - but printRate is really a wish - the IMU updates determine rate of updates where it was before?
 
Just put in my own timer, and the prints to serial now seem to be correct. Now if I ask for 100ms data to the serial port, it prints to serial at 100ms. seems to be issue with using elapsedMillis, or at least how we have it set up. I commented out the logging as well to see if that might be contributing, but it didn't help.

yes, the IMU updates are the true update rates, but I just wanted to verify the timestamps on the data that was going to serial (at the slower rate).

I'm also having a problem with the serial terminal freezing when I rotate the IMU. Was hoping it was related to this elapsedMillis timing issue, but it's still doing it. grrrrrr.
 
If you are using the version of uNavAHRS that you just downloaded comment out the temp comp tests. the two should be almost the same
 
The SD can be written after the circular buffer is full i would imagine, you'd need to setup a ring buffer of 512 bytes, print to it just like the serial monitor, and later on when the size() >= 511, you could have it automatically written to the SD card reading from back -> front of the ring buffer

To be a little more efficient, you could read(buffer,len), readBytes(buffer,len) to a local 512byte array, it will memmove the queue directly to a local array and deque so your ISR could keep adding to the new empty queue while your SD is still...writing.. :)
 
Don Kelly said:
...
I'm also having a problem with the serial terminal freezing when I rotate the IMU. Was hoping it was related to this elapsedMillis timing issue, but it's still doing it. grrrrrr.
Click to expand...

Does the output just stop - or the Teensy go offline? That sounds like a wire/electron disturbance?
 
Ran into a similar problem with Tviewer for some reason. It would stop and when I checked the serial monitor I was still getting data. The other problem I seemed to be running into was when mpu went too far over 30C it would seem to hang or maybe related to the way I was doing temp corrections.
 
adjust the ISR levels, thats what made MST work better, because the USBSerial was higher priority (lower value)
 
Status
Not open for further replies.
Back
Top