uNav AHRS

Status
Not open for further replies.
Tim:
"Those same 12 doubles of 48 bytes could be shared using SPI connect to a Slave Teensy in 1/3'rd the time of the print routine at 24 MHz SPI." That may change after debugging of the KF. But if we keep it to a max of 12 it would be good stress test. For instance - do we really need to spit out the 3 timestamps to Tviewer once we're confident that we got the timing down? After we get the KF debugged we may want to just spit out YPR, LAT, LONG, ALT and a elapsed time for reference, that would reduce the output from 12 to 7. Something to think about for the future.

"without the 2Mbps UART Serial link that right now is showing fitful at 200 Hz IMU updates." - I saw the same thing even with the FTDI adapter.

"I've got a working link to a T_3.5 - but it may be a week before it is ready to try. " - probably good timing. There will probably be more changes to the filter as time progresses. And all I can say is WOW - where do you find the time.
 
Don - Tim

Was busy this morning looking at a theory I had on the temperature impact to the gyro and accelerometer. I would say yes there is based on the attached charts. Gyro can probably be adjusted if there is no motion and running a short gyro cal. Accelerometer is another story.
 

Attachments

  • MPU9250TempDependency.PNG
    MPU9250TempDependency.PNG
    45.7 KB · Views: 233
hi mike :)

the 60 "words" (120 uint8_t bytes) with F&F transfers are down to 77uS @ 24MHz by end of transaction, gained just under 20 uS from going round trip to fire and forget
 
tonton81,

All I can say is wow. I have been periodically looking at the other thread but a little over me until I see how Tim is going to incorporate it into this project. I am dense sometimes. I am really curious on your first post, about hooking it up to an 8266, and do the wireless communication. But that's for another's day discussion :)

Thanks for putting that together - going to make life better in the long run.
Cheers
Mike
 
Is post #612 the latest _V8 baseline?

tonton81 has posted working code I'm looking to integrate in coming hours ...
 
Yes it is. Have not made a single change since that post. Just finished reading the other thread and saw what tonton81 did. Amazing.
 
Yes, quite amazing. I've seen posts pass about inter Teensy access - but never saw one that posted back working - and 24 MHz SPI - other than its limited distance - is impressive. And the process and wrappers seem understandable and functional as much as I've looked.

Fully equipped with a CRC to detect corruption - and auto resend when appropriate ( the F&F is Fire and Forget and to make it faster the Slave can see corruption - but faster not having to ACK the Master in the case a message gets lost for resend ).

I poked at SPI once adding the SPI interrupt detection to the PJRC ILI9341 XPT touchscreen - even cleaned it up a bit based on the protocol to exit early when no touch - but just used the transfer commands Paul had in place. So looking forward to seeing this work and then looking under the covers to appreciate it more.
 
Tomorrow I am going to have to solder up another T3.5 to get ready for the change. But should be worth it. Going to be fun the examples you two come up with.
 
Advance Note in case it helps wiring and setup as the transition is made.

Using SPI0 on both I have this working as T_3.5 Slave :: T_3.6 Master > Connections
Code: 
[U]T_3.5 :: T_3.6 > Connections[/U]
GND:: GND > GND
14  :: 14 > SCK
12  :: 11 > MOSI
11  :: 12 > MISO
02  :: 15 > CS

and a pic - the T_3.0 wires still coming up to Serial1:
SPI_MST.jpg
 
Last edited:
I figured the picture would make up for my possibly writing it badly. tonton81 is running Master off SPI2 bottom pins.

The Master uses standard config - the Slave is hardcoded to function pins AFAIK.
 
A quick update here...

I've got a new version, V8LF (V8 with lineFit). I ended up modifying 3 existing tabs (globals, kfINS9State, getIMUFilter) and adding one new tab (lineFit).

The code is done and compiling, but I've got one more hook (ties in getIMUFilter to lineFit) that I need to add, and then I'll need to test it and work out any kinks. It was more challenging than I thought to port over the Python code and to get it connected, primarily because Eigen handles matrices, vectors, and scalers differently than Python. So I'm cautiously optimistic that it'll run off the bat, but guessing it's more likely that I'll need to do some debug.

Anyway, making progress...

Tim... I'm keeping track where I'm making mods, so if you morph V8 into V9, I can come along and insert the V8LF mods to V9.
 
Looking good ... Had time to make the prototype work: micros() _time==33 for 12 Dword transfer!

Just set test to 200 prints/sec no problem. Actually alternates between a measured 32 and 33 uS as written.

Will migrate later. So if you get _V9 where you want it - give it a post.

AFAIK :: I'll add #ifdef code in serialPort.ino and updates to A_ConfigDefines.h

I'll SPI_MSTransfer whatever is in Master :: serialPortOutKF() and recreate it from Slave to USB.
BTW: If there is any variable to see on TViewer this 7X updated faster method of output says include it if it will tell you anything!
 
Don. Can't wait to see what you came up with for the line fit and how it works.

Tim-Don. As for output would probably add the YPR values. The one thing we have not tried yet was to tie in a pressure sensor. Onehorse's 9250 includes a MS5637. These tend to eat up time so should be interesting to incorporate after the SPI_MSTransfer is incorporated. On a t3.5 pushing it.
 
cant go wrong with ~120 gpios activating within 14uS, who needs a bank set of mcp23s17’s when youve got dual teensies over 24mhz link. newest version allows writing data to all serial ports of slave (including usbserial) :)
 
hi tonton81. I was just going through your other thread and was beginning to read. A lot there. Can't wait to see it in action. You are going fast and furious with the library. Here's a question for you = would it eventually work if you have multiple slave teensies attached, chain teensies (so in some instances the slave becomes the master to transmit other data :) You are essentially putting together teensy network.... reminds me of a xbee setup only better :)

Oh. Almost forgot - tomorrow I am going to wire it up and give a go with the test sketches in the other thread.. :) Too many projects not enough time.
 
mjs513 - I already queried about 'SPI Broadcast' on the other thread. It should be do-able. Master controls the remote Chip Selects - and if the Slave's all listen only on command then they could all clock in the same message at the same time.
 
yes it _should_ support multiple slaves, although i havnt setup 3 teensies for testing, the library does indeed support it the way im laying out the object references.

if you have 3 slaves and 1 master it should be okay
and if you slave.transfer16(....) from all slaves to the master, your master will get all 3 callbacks

regarding which slave sent the message, well, now you could use the packetID field as an identifier :)
 
Yup, broadcasting support will be eventually added, itll require a single assert for all slaves, a broadcast and deassertion, basically like UDP. this most likely will be a fire and forget unless additional ideas come up

the library most likely will keep a static array of CS lines it captures during construction to automate this process
 
well i _could_ make a teensy act as a master and a slave, to support chaining, yeah

it can do it now but.. theres some things that need to be checked first to make sure no conflicts arise

chaining is a test we can implement later on, but 5 slaves to 1 master should be possible now at least
 
Tim - missed that one in the other thread about "SPI Broadcast". Didn't know what I started here :) was talking out loud for the future. Personally I like UDP. Use it from a EP32 to send IMU to a Processing program I use for visualization. A lot easier for me to understand :).
 
Broadcast etc is good fodder for the SPI_MSTransfer thread. Is quite promising.

I'll be back at my workstation soon to put the SPI Master Slave Transfer into _V8 code I have to see how it acts having the Slave push out the verbose USB for TViewer.
 
tonton81(Tony?) - I do now. Just did a search and found it - teensquitto. I saw the thread but didn't read through it - I think I was busy with this project. Kept meaning to read through it but kept getting side tracked.
 
update...
V9 (V8 with lineFit to smooth accel) seems to be working. The smoothing algorithm output matches what I get in Matlab with the same numbers, so appears it's getting the right numbers. I need to go run a few errands, but after dinner I will send raw accel and smoothed accel to TViewer, and if all looks well, release a V9 tonight or in morning. Took me longer than I thought, figuring out some of the Eigen library stuff was bit of bear, I kept using the "block" slicing tool wrong... brrrr!

Will still need to try a combo of things probably for it to actually benefit the KF, like
- trying different DLP and LP settings in MPU9250 library
- deciding which lineFit order (1st or 2nd) seems to work best, my guess is 2nd
- deciding how much data to lineFit, the default is 10 points. too long and we create a lag, too short and lineFit might not produce great answer

off to do some errands...
 
Status
Not open for further replies.
Back
Top