Yeah it’s 3.3 volt. Just connect IOREF pin to 3.3 volt on ardusimple, that sets the UART level to 3.3 volts.
As for CMPS14 I don’t know but at least teh BNO080/085 breakouts run at 3.3 volts as well.
2 Likes
Yes the CMPS runs on 3.3v to 5 v so no problem.
You can yes. Might be tricky doing antenna offset compensation initially with knowing the heading you are going.
1 Like
I’m now doing the fix2fix calculation on the IMU directly, was thinking just to take the same approach as is used in the AOG code for the offset? Anyhow it’s only for the initial start of the vehicle. If speed drops below a certain treshold, I’m going to direct integration mode for the IMU only. The Kalman filter is working in a way that’s not correcting the GPS signal with the IMU, but using the IMU rates to drive time integration forward at high rate and correct the position, attitude etc. with the additional sensors such as GPS, odometry etc. That also gets you rid of the time sync problem, the IMU signal is integrated constantly at high rate and immediately as a GPS measurement arrives a measurement correction is applied.
Waiting to see how it works in the field. That will be exciting.
Low speed is a real pain.
Trying to go for it when the snow drops a bit, plan is to get the OpenIMU300 going on the same run so can compare the results.
1 Like
Tony and Giovanni have been busy doing roll correction work with the new PANDA and the results are spectacular. I have to put videos on youtube to post here unfortunately.
We have built a new graph that shows antenna easting, correction distance, corrected distance and roll in degrees. Mounting the imu on a pole and the antenna on top we can swing the antenna back and forth showing everything. Panda teensy code allows timing the imu reading with the gps fix so correction works well.
Here you can see it in an image.
6 Likes
2 Likes
My least favorite spot for the imu is on the steer board - and this is why… basically makes it worse which is why the filter needs to smooth it out so much and only good for sidehill correction.
The green line is the “corrected” and should be straight.
This looks very promising! I’m really looking forward to use PANDA
This will bring a lot of stability in the steering on ploughed land where tractor is “wiggling”
I’ve been playing around with the F9R system for the last few days. The unit has achieved RTK fix and can output this at 10Hz. Haven’t cross checked accuracy yet, but it reports that all is well in RTKFix.
I just figured out how to get UBX-ATT and UBX-PVT messages out of the system. This gives the pitch, roll, yaw, and rates. Now I need to figure out how to decode these messages out of the UBX proprietary format and get them into Panda or Paogi. I’ll be really curious to see how this works. Another option I guess would be to figure out the AgIO code and see if I could do the UBX read and conversion directly in there.
I like this in that the ublox f9r system takes care of teh reading and synchronization of the data. I have the IMU running at 50 Hz right now and then outputting the IMU data at 10Hz in sync with the GPS.
Now to see if the data is any good…
<UBX(NAV-PVAT, iTOW=03:41:11.600000, version=0, validDate=1, validTime=1, fullyResolved=1, validMag=1, year=2022, month=1, day=25, hour=3, min=41, sec=11, reserved0=0, reserved1=500, tAcc=22, nano=600000007, fixType=4, gnssFixOK=1, diffSoln=1, vehRollValid=1, vehPitchValid=1, vehHeadingValid=1, carrSoln=0, confirmedAvai=1, confirmedDate=1, confirmedTime=1, numSV=31, lon=-81.7048022, lat=41.11391, height=325152, hMSL=359574, hAcc=4026, vAcc=2877, velN=0, velE=0, velD=0, gSpeed=0, sAcc=25, vehRoll=-4.23701, vehPitch=0.80516, vehHeading=348.68509, motHeading=348.68508, accRoll=0.25, accPitch=0.25, accHeading=40.9, magDec=-8.34, magAcc=0.7, errEllipseOrient=165.22, errEllipseMajor=7102, errEllipseMinor=7052, reserved2=1011181288, reserved3=0)>
How do we know the data is synced or if you’re just seeing the same messages you might see from an external IMU? The real value of the F9R to me is how it can resolve a virtual reference point. This eliminates the entire need for any terrain compensation at all—at least as far as GPS is concerned—since the virtual GPS coordinates returned would be translated from say the roof position down to the axle position. But as far I know, when you do this virtual position stuff, it can only do RTK Float, not fix. Have you tried that part of the F9R yet?
1 Like
For the message sync, there is a timestamp provided with each message that can be used to line up and cross check. I’m not too worried about the messages lining up, running at 20 Hz is quicker that the dynamics of a tractor can react. I’m more interested in understanding any filtering lag that might exist in the IMU signals. Still more testing to do…I like the swing arms system that was shown above.
I have not figured out anywhere to configure the virtual reference point. it does the dynamics to keep position data running through GPS blackout, but I don’t see where to enter info about the antenna height and mounting orientation for the system to provide a virtual point. Will keep looking for that. If you have any info or references to the virtual reference, I’d be interested.
1 Like
Sounds good. If things are synced up nicely then doing the terrain compensation calculations inside of AOG should be easy and accurate (as long as the heading is good).
Here you: F9P, BNO08X in gyroIntegratedRotationVector at 200Hz (5ms GYRO_DELAY_TYME) and imuHandler() synchronization with an ISR from the TimePulse of the F9
5 Likes
Had some time to work on the OpenIMU300 finally, now running GPS over CAN and the fusion algorithm on the IMU. Documentation is quite bad so lots of source code reading, now I gotta transfer this mess into something more manageable for field testing. You can set the IMU / GPS antenna coordinates directly in the SW, as well as the point of interest, so it should give the corrected position with roll & everything, we’ll see.
5 Likes
Been thinking of the field setup, maybe something like this could work? I wouldn’t want to push RTCM through CAN as it needs the multimessage J1939 protocol and I wouldn’t want to have separate RS232 to the IMU unit either, as the RS232 is really handy for logging and debugging with Aceinna toolset.
- F9P connected via Ethernet/UDP receiving the RTCM corrections and outputting the UBX NAV-PVT binary message
- T4.1 reading the NAV-PVT and converting that to the OpenIMU300 supported J1939 messages (working already). Getting back the fused lat/lon/velocity etc. and sending a modified NMEA message back to AOG via UDP
- OpenIMU300 is working purely in CAN mode, settings for position, lever arm etc. provided over CAN if needed
Or another alternative, where the F9P and T4.1 are connected directly. Maybe better for latencies as well. T4.1 would work for both steering as well as machine control.
2 Likes
How you are doing the fusion on the IMU (Something needed to write code on the IMU?)? Can I see the data of the raw and fused GPS data comes from the IMU?
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