Okay, some updates. Tried to find some proper data for BNO085 parameters, not so easy. Got the following from several sources:
Bias instability 0.5 deg/min i.e. 30 deg/hr vs OpenIMU300 6 deg/hr
Angular random walk 1.2 deg / sqrt(hr) vs OpenIMU300 0.3 deg/sqrt(hr)
Acceleration bias instability 1.5 mg vs OpenIMU300 0.01 mg
Velocity random walk 0.12 m/s / sqrt(hr) vs OpenIMU300 0.06 m/s / sqrt(hr)
So performance wise there’s a clear gap to a “professional grade” IMU, nonetheless the BNO08x seems like a good piece of kit. Tried playing around with the covariance values, and some “correct” settings just made things worse, I guess trial and error is the way to go, especially for te measurement covariances.
As for the OpenIMU300RI I’m testing now, working on the GPS hookup at the moment. Setup is F9P talking to Teensy over serial with the UBX-NAV-PVT binary message, that contains all the stuff needed for the four J1939 messages that OpenIMU300 takes in via the bus. I want to keep the RS232 port free for communication to the PC, so I don’t need a separate CAN gateway for that. The nice thing is that the whole sensor fusion code is open source, so you know what’s happening inside and can quite easily modify it. The 300ZI version has double UARTs so that would be really easy to hook up directly to the F9P and use NMEA sentences.
Another benefit from the CAN version is that you can easily hook up to the vehicle bus to get the speed sensor messages if needed. Big picture setup I have in mind is the Teensy acting as a gateway between the vehicle bus, hydraulics bus and steering bus, so that you can share information and also run implement automation directly on the bus.
Here’s some new code for reading uBlox UBX-NAV-PVT message and converting that to the CAN messages required by the OpenIMU300RI. Maybe useful for someone else as well for decoding from the uBlox binary message, it’s sorta handy as you don’t need to parse the NMEA string and all the data needed is in one message only. I’m outputting that on UART1 in F9P and reading with Teensy.
Just having some trouble with the new MAX3051 transceivers, they refuse to work so gotta find some replacement chips to get the CAN up and running or steal a board from some old project…
I used the MCP2562FD. They work well. They have VIO so you can still get teensy safe 3v3 levels.
Does the Teensy Arduino package now come with the updated Flexcan library? When I installed it didn’t so you had to replace it for the latest flexcan (far better) code to work.
Yeah gotta find an alternative, would have bought the 2562 but seems to be in short supply globally. Bought instead a bunch of these: Dual CAN-Bus adapter for Teensy 4.0, 4.1 from Fusion Tech on Tindie The design is very compact, so would be really good if I get them to work.
The newest Teensyduino was released some days ago and according to the release update it should contain an updated version of Flexcan_T4: Teensyduino 1.56 Released
I have been thinking about the comments made that the autosteer board is the worst place for the IMU data to come from. It got me thinking why?
We have UDP or USB highway to AOG, with the IMU data sitting on the steering truck doing a loop every GPS fix or 100msec.
Get GPS fix - Do some maths - Send data to steering - steering returns with IMU data. While that was happing the next fix arrives and around the loop again. The IMU and GPS data must be from around the same time.
I thought I have been wrong plenty of times before so I tested a few things. First I changed the Arduino program to run two timed loops, one for steering control and another for the IMU loop. Removed the IMU data from the steering message and into the new IMU loop. Not really anymore work for the Nano and send the IMU data as the IMU message. (Get a second truck on the highway)
Didn’t see any diffrence in performace really (Roll filter slider full less & centre), so I went looking in AgOpen source code and see the filter there (min value 2 in the user interface). Then I thought “Thats no good, the data was good and now we only use part of it ?” so all of a sudden we have wrong data till next time.
Then I thought why only run the IMU at 100msec? Now I have the IMU loop seperate (Still on the main steering PCB) . Changed BNO085 report time to 40msec and IMU loop time to 45mec, now AgOpen gets two IMU readings between the GPS fix’s and the filter can do something with them.
Get IMU data - Use part of it - Get more IMU data - Use part of it - GPS fix - Do maths - run again.
Roll correcton was alot better when moving a 3.1m pole (with gps and autosteer borad on it) side to side when connected to the vechile.
Why is the min roll filter value in v5 two ? Cant see any filter in v4 roll data.
Why do we have the IMU data in the steering message when it can go seperately with only a .ino program change (for the current uses that dont want to build external IMU)
Why is the external IMU program only running at 100msec
Can’t really answer any of the questions, but I think the whole sensor fusion needs to happen on the hardware (is it then IMU or autosteer PCB), and you just send AOG the corrected signal as an NMEA sentence. Then you don’t need to worry about the timings that much.
The faster you run the IMU loop the better it gets, I run at 100 Hz now for the IMU fusion code. That reads the GPS via serial and fuses that with IMU data now for the heading and speed only, but if you extend the filter you can add the location variables as well. So it’s doing the forward model with IMU at 100 Hz and whenever a GPS message arrives it updates the estimate based on the GPS.
My coding is very rusty and my maths more so, but I’ve been looking at Franz’s dual code roll compensation routine and, with the addition of heading I can’t see it being too difficult to add to the teensy code I already use.
Getting back up to speed on this stuff. I keep up with AgOpen in the winter, then disappear in the spring until next winter. I’m the one that originally started #PAOGI (Proprietary, AgOpen Gps Imu). I had it working on the original EMLID reach to combine the GPS and IMU data. It wasn’t dead reckoning, just sending all he data together in one sentence. It worked , however, the L1 EMLID GPS wasn’t accurate enough.
A couple things learned from that. Coordination of timing was critical and difficult. The IMU data was running at 100Hz. I’m monitor for a new GPS sentence and when it came in, take the next IMU sample and send as a combined unit with the GPS time stamp. This worked well with a clean IMU signal. Any noise on the IMU and you needed to filter, which would cause a signal delay.
I still have one Reach that sends out PAOGI, however I dropped working on this after moving to the F9P. I think the idea of treating the GPS/IMU as black boxes outside of AgOpen is great. The development and different solutions can be tried and send the standardized messages into AgOpen without changing the program.
I’m going to play around with the F9R this winter. I’m curious to see how well the IMU performs. It looks like you can get the IMU data out via proprietary UBX messages to general heading and tilt into into AgOpen on top of the onboard dead reckoning.
It looks like there’s very little difference between the data included in $PANDA and $PAOGI. Does AgOpen process the common field any differently between the two?
Why is the min roll filter value in v5 two ? Cant see any filter in v4 roll data.
Because at 2 it means almost nothing. Even at 50 you can barely tell there is a filter. It is not linear.
Why do we have the IMU data in the steering message when it can go seperately with only a .ino program change (for the current uses that dont want to build external IMU)
Because many systems are already running on the edge.
Why is the external IMU program only running at 100msec
Same answer as above. You can run it at 50 msec, but it will still be wrong. You can fiddle with it but it will never work as well as intercepting the nmea and timing the imu with the fix time.
The odd part is, you would think it would work better then it does but the antenna is on the wrong end of the sin, huge position change for very little roll values.
At 3m height:
1 deg = 5cm
2 deg = 10.4 cm
3 deg = 15.7 cm
4 deg = 21 cm
Now at 3.5 kmh ( 1 m/sec) fixes at 10 cm apart. The tractor takes almost no time to wiggle back and forth a few degrees, add to that the timing is off up to 100 msec - or even 50 msec if running at 20 hz and it is a complete disaster compensation adding when it should be subtracting and vice versa.
The imu must be taken at exactly the time the gps is doing its fix and putting the imu on the steer board or as an external imu will not give satisfactory performance.
Add to that windows - delays and different timings from fix to fix in AgIO and AOG and serial ports and you do the only sane thing - filter the roll so it works on sidehills.
At least this is my experience. I think what is maybe hard to grasp is how critical GPS position correction is. It has to be dead on.
Good to hear from you again Charles! Yes, PAOGI has gotten pretty old. PANDA is much the same except it excludes dual and has imu. Parsed the same way, just fills in what is required for single with imu so without any settings AOG knows it is single.
With current boards having the GPS and imu on the same board talking to a Teensy powerhouse, it simply becomes a software solution to time the imu and fixes.
It is a nice little unit. To use the IMU with dead reckoning, it needs a speed input; I plan to install a mag pickup to TTL converter and use the existing speed sensor off of the transmission on my Deere 4555.
As far as RTK goes, there does not appear to be any reason (while not in dead reckoning mode, in which case you don’t have a reliable GNSS signal anyway) that it won’t go into RTK fix. I’ve not gotten it there yet as I still don’t have my RTK working right and don’t have the ability to test outside in the open due to the weather. MTC.
In a quick comparison between the ZED-F9 (I’ve got bot a R and a P version) vs the Witmotion WTEAHRS1, the GNSS capabilities of the are far superior to the WTEAHRS1 just on access to the data alone. The desktop version of U-Center provides access to all kinds of GNSS metadata if using the native ublox protocol. The Witmotion GNSS data is largely limited to lat/long, number of satellites, and HDOP, VDOP, PDOP when not in the NMEA communication mode; when in the NMEA communication mode, the IMU data is not available. I do think the IMU in the Witmotion is a bit better than the IMU in the ZED-F9R, it uses a 9 axis IMU with very fast update times. I like the aluminum case of the C102-F9R, more rugged than the plastic case on the Witmotion.
But hands down, the ublox is a far superior product, largely based on the documentation and corresponding software. The ZED-F9 is ~twice the price of the Witmotion but still a steal compared to other commercial options. The dual band of the ZED-F9 gives me about twice the number of satellites as I get with the Witmotion.
With a 1.2m antenna spacing and 2cm +1mm/Km (so say 25mm) vertical rtk accuracy, dual roll could actually be towards 2.4° out on any given fix. Would I be right in thinking that this error could also be random about this range, fix to fix?
A well placed IMU should easily sit within this range surely?
Here is Panda - the teensy 4.1 GPS and imu combiner. Roll and z gyro run at 100 hz, then combined to the 10 hz GPS. Please play around with it, we have so much snow here and cold so it will be a bit for me to do anything. It accepts GxGGA and GxVTG.
Just be clear: the code is time syncing the IMU data with the GPS fix and then sending that as a PANDA package to AOG for further processing? If I run the sensor fusion on the Teensy, I can just send the new VTG and GGA sentences to aog and set the roll correction to zero in AOG, no need for modifications in AOG?
it depends on where you want to compensate for the roll, and calculate the heading. if you do everything in the teensy better to use PAOGI (you have to do also the fix2fix calc/fusion in the teensy), so AoG uses the values as they are, otherwise PANDA or GGA + VTG + IMU
