Maybe for future use the openIMU300ZI with uart could be used, direct nmea from GPS. Seem cheaper also.
https://openimu.readthedocs.io/en/latest/hw_sw_interface/gps_input.html#gps-receiver-input-signal
Yeah been looking at that as well. I’m using the CAN version as I plan to integrate the steering controller into the IMU. There’s also a SMT BGA package available that’s around 100 eur.
Edit: Looks like the 330BI is not an option, as it’s so low on memory that it can’t run the INS+GPS app. So gotta go with the 300 series.
Hello !
By following the forum, I could see that you were talking about the different frames that were sent to the software. @BrianTee_Admin
Do you have a list of frames that can be sent and received?
it would be super interesting to have a functional diagram of the software a bit like on ardupilot and pixhawk.
Thank you for all the work done.
Improvement would be also to combinated it with the latest Ardusimple with higher Frequenzy and better accuracy. Maybe use it with 20 Hz and RTK.
Would require some code changes and assumptions - but if your computer was fast enough it should work at 20 hz
Exactly.
Okay. But than i need to use a other AOG Version which can read Panda or?
Of course, just download it on GitHub.
Yes, get the latest pre release.
I like to test with panda too. I have the latest pre release,
so load the panda.ino in the teensy, connect things like few posts above and go?
(assumed that it works with bno085 also?)
I’m using with BNO085 and it goes very well.
Had someone already looked into Panda UDP Arduino. ino?
Is the RTCM Ntrip-Data for the simpleRTK2b provided via the serial connection from the teensy board?
…because there is no “direct” link between AgOpen and the simpleRTK2b in the PANDA setup anymore.
As near as I understand, AgIO transmits the RTCM data that it received via NTRIP over the same serial link that the teensy sends the PANDA nmea sentence back to AgIO.
Am I reading the panda source code right that the IMU is read 90 ms after the GGA fix is parsed from NMEA? Or is it reading the IMU data that will be used for the subsequent GGA sentence 90 ms after the last one? I think the latter is correct.
Yes the latter is correct. Once a fix is rec’d the clock starts and since gps is accurate, and the teensy is a blazing ball of speedy fire, it works perfectly to time the fix with the imu roll sample about 90 or so msec later for the current fix to arrive.
Yes it does, and Teensy just does a pass through from the NTRIP receiver in AgIO.
Yes that makes a lot of sense!
I’m adapting the code to run on an ESP32 (because it has built-in bluetooth and I like to use NTRIP client on my phone). And I have an idea to try doing the roll compensation right on the ESP32 and then generate new GGA strings. Not necessarily useful to AOG, but it might have application in other places. The ESP32 is pretty fast, but not nearly as fast as the Teensy, and it does have good floating point math.
Could do it all on the Teensy also of course.