Is the purpose of your code to create an accurate yaw rate of the vehicle?
We tested the FJ Dynamics for RTK persistence. With no RTK it won’t work but we managed to keep it running for 20 minutes with the NTRIP disconnected after running with RTK for some time.
personally I would do a test, now we use the gps at 38400 baud, the softwareSerial should manage them, so for those who already have the external imu module, just make the connection and load the ino
Yes, and the heading comes as a by product. It’s basically the same thing algorithm wise. It’s also calculating the speed by fusing VTG speed and accelerometer, that way you get also the reverse detection from the accelerometer.
I think the 328 with software serial would just be able to handle the nmea alone as it is so inefficient without a buffer. The parsing, reading imu, building $PANDA take a bit of horsepower and hardware uart’s to work.
Personally, for longevity, onboard connectivity and 100% reliable compatibility (no clones) I think the Teensy4.1 would be a good future move for AOG’s steer board / external interfaces. Coupled with it’s very close Arduino compatibility thanks to Paul Stoffregen’s large contribution to the Arduino project, to make backwards compatibility relatively simple.
1 Like
I’ve been playing with the WitMotion WTGAHRS1 combined GPS/IMU. To get both IMU data and GNSS data, you lose NMEA formatted data (you only get lat/long and hdop, vdop, and vdop). I’ve an interface to the device and am working to patch it into AOG but it would require a completely different interface than currently used in AIO.
I like the built-in compass for heading verification. It would be nice to be able to tap into the tractor’s wheel speed sensors for an independent ground velocity (Deere 4555).
I have one Aceinna OpenIMU300 waiting for time to play with it. It can take also odometry from e.g. wheel angle sensors and GPS via uart/rs232 or CAN. Similar to the witmotion vut without internal GPS and you can get NMEA out, the code is open source so it’s pretty neat.
Today did some field testing with the BNO080 fusion gode, heading is now solid but needs some work with the reverse detection. WAS sensing works as well, just need to use IMU only for sharp cornering, the 8 Hz GPS is too slow. Still some bugs when it’s returning to GPS aided mode, used 6 deg/s as the limit yaw rate.
Drove around several kilometers with the GPS fusion on, works quite well except for some sawtooth in the WAS signal in rapid turns, for steering angle below 10 degrees it’s really smooth and seems to give good zeroing of the virtual WAS.
2 Likes
Welcome to the community Wizard!
There are 2 options to get data into AOG, using PAOGI and PANDA (just new for single antenna/imu).
Can you explain in more detail what is missing/needed that either sentence wouldn’t work?
$PANDA
(1) Time of fix
position
(2,3) 4807.038,N Latitude 48 deg 07.038' N
(4,5) 01131.000,E Longitude 11 deg 31.000' E
(6) 1 Fix quality:
0 = invalid
1 = GPS fix(SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated(dead reckoning)(2.3 feature)
7 = Manual input mode
8 = Simulation mode
(7) Number of satellites being tracked
(8) 0.9 Horizontal dilution of position
(9) 545.4 Altitude (ALWAYS in Meters, above mean sea level)
(10) 1.2 time in seconds since last DGPS update
(11) Speed in knots
FROM IMU:
(12) Heading in degrees
(13) Roll angle in degrees(positive roll = right leaning - right down, left up)
//not implemented
(xx) Pitch angle in degrees(Positive pitch = nose up)
(xx) Yaw Rate in Degrees / second
* CHKSUM
*/
The data comes from the sensor in byte format that needs to be converted manually to the corresponding parameters; not as a string based sentence to be parsed. I’ve built a class library and a corresponding test interface (C#, NET 5.0), that all works fine. I could add an interface to format the data as a sentence to pass to AOG but I already have the data parsed and could pass it directly.
Small steps forward, heading fusion starts to be stable. It drops the GPS corrections when yaw rate is over 6 deg/s, and now the transition is smooth. Had a bug in the first version where it took the new heading from the point from the start of high yaw rate, not from the previous fix. Next step is to set the covariances based on HDOP, speed etc.
Also the OpenIMU300 project is proceeding, trying to get the GPS updates into the IMU and add the WAS calculation etc. It has CAN and RS232, would want to run the whole steering algorithm on the IMU Cortex M4 chip and connect to PC via the RS232 and the connect the IMU to steering bus. Needs the GPS over can though.
4 Likes
You could send the data to AOG just like the imu module, using that sentence format which is in bytes.
It is very simple
Thanks Brian. I would like access to more of the IMU data including acceleration and angular velocity than currently comes across in the $PANDA message. I suppose additional proprietary NEMA messages could be added. For example, in theory acceleration data could be integrated to velocity and combined with angular velocity to provide additional filtering for lat/long. Of course, a wheel speed sensor (or radar for those so equipped) would be an even better input for velocity but that would require additional I/O and the calculations would still want angular velocity. Comparing compass/IMU heading data to GPS heading is another data filtering option.
I’ve seen some drone code that uses IMU data from multiple sources combined with multiple source GPS data to provide even higher reliability location filtering. I note that the tablet I use for my display also has an IMU and am playing with the idea of combining that data (converted to match the orientation of my GPS/IMU sensor) with the IMU data from my GPS. To date, the only way I’ve found to tap into the tablet IMU data is via UWP which isn’t readily compatible with Framework (I could create a socket or serial stream to pass that data to AgIO). All of that requires establishing a standard format for transferring all of the available IMU data. Perhaps a bit ambitious.
While new to AgOpenGPS, I’m not new to software development. As a closet farmer (my brother has the family farm, I’m the helper for planting and harvest), and an engineer (growing up on the farm was the best training I had to be an engineer), it kills me that access to this technology is priced as high as it is, especially now that the technology is relatively mature. What you and the rest of the community are doing to not only make the technology more affordable but also in advancing the state of the art is nothing short of outstanding. Combine AGO with new sensors (U-BLOX has some impressive technology at moderate prices including GPS with imbedded IMU with the dead reckoning already built into the chip (assuming you can tap into a reliable velocity), RTK, and multi-band GPS; the WitMotion has potential, especially if it could be post processed for RTK correction via RTKLIB methods) and CAN/ISOBus interface with existing equipment and you have a quantum change to the industry.
I’m here to help (I’ve made some recent changes to AgIO that have been incorporated into the current product) and if I’m too far in left field (or the back 40), let me know. Is there a master list somewhere of desired enhancements? Recognizing that I have ideas for enhancements but some of them may not have the immediate impact/priority desired of the broader community.
I see a lot of potential in lowering the cost threshold for precision ag with this platform, especially for vintage equipment. I recognize and appreciate all of the good work that went into developing these tools and would like to help pay for it in my sweat equity.
6 Likes
That is great to hear. One of the most important things is taking ideas and putting them into actual hardware and doing real field operation in an actual tractor for hours showing it works is key.
Proven ideas are extremely easy to add to the existing project. @nut is also working on integration of imu/gps and am excited to see where all that goes.
Yes the ZED-F9R is almost exactly what we need for precision ag purposes. Unfortunately it’s not quite there as the F9R does not do RTK fix, only float. So half metre precision is all it can do. Hopefully they will produce a full RTK fix version some day that would be perfect for AOG and any ag application. Especially if they can do virtual reference points as the F9R does, which would mean integrated terrain compensation and filtering, as well as dead reckoning and integrated kalman filtering for position. This would eliminating the need for any external IMU at all in the system.
2 Likes
ZED-F9R datasheet reports RTK precision 0.01 m + 1 ppm 
But it never goes to RTK fix mode in sensor fusion: https://www.ardusimple.com/rtk-ins-simplertk2b-f9r-hookup-guide/
So like said, you’ll only get RTK float.
2 Likes
I thought it was about the first version of the F9R.