Hi there. I have tried with the ino of post 151 and with the AOG v 5.2.2. and when i switch to differential mode and record, the arduino stops working.
I used your code. it works wonderfully well!
One almost wonders how useful the WAS is still.
Small note for other users do not change the PWM frequency otherwise the code no longer works. moreover a small additional delay at the start of the code is useful (1 time out of 2 when starting the autosteer the bno does not start quickly enough and is not recognized).
2 Likes
It’s seriously rough code but I was trying to prove a concept with limited knowledge. TBF I only posted it publicly because I got pushed into it! Someone with more coding experience and more time could probably do a fair bit better.
I think @BrianTee_Admin was looking into the Idea a while ago.
2 Likes
Been thinking about this now for a while, to develop sensing and filtering the steering rate from the IMU, it would be probably beneficial to run a tractor (or two for that matter) with a wheel angle sensor AND IMU raw data logging on. Should be doable with Teensy 4.1 to an SD card.
Then you could do the algorithm development offline, not having to drive around and optimize such that you get equivalent results from the WAS and the IMU. Of course, WAS in muddy ground etc isn’t giving the absolute truth either.
1 Like
I did wonder about running a second BNO085 on my teensy can bus 724. Considering putting it on the ISO bus anyway. Running triple mowers really shows up the limitations of WAS output. Lifting individual mowers definitely affects tracking. The IMU would obviously pick up the angle change no problem.
The data logging idea is definitely a good one. Would be interesting to try the WAS less on the 724. This tractor presently sends the requested angle straight back as the WAS value whilst it is steering. It only uses the WAS on the tractor when not steering.
This also brings up ideas to experiment if the antenna is better placed on the tractor or fixed implement in cases where the fixed implement drag affects the tractor greatly.
Or a dual setup where an articulated implement has its own GPS and imu, as does the tractor. Then the implement is mostly in charge of of keeping itself on the desired line by passing its error forward to the tractor.
Or using the WASless code as an error check on the WAS if equipped to identify and correct for slippage quicker.
So many ideas to pull in that last few cm in poor conditions. With U turn I finally got used to finishing a full sandwich without interruption, It would be nice to keep it accurate that way even on mud and side hills.
1 Like
There’s quite some development on similar ideas on the automotive side, using a vehicle kinematic / dynamic model to predict the attitude and wheel slip and fuse that with the IMU data to get the vehicle motion.
Another way to get rid of the long-term bias in the IMU is to attach it to a rotating platform (which is expensive and tricky). Hence, there’s some developments on attaching the IMU to the wheel and utilizing acceleration data to define the motion of the IMU itself and then use that information to calculate the vehicle motion from the IMU motion.
I think the most feasible way would be to use the GPS information (at as high rate as possible) and a kinematic vehicle model to run a Kalman filter on the IMU signal, maybe you need to cut off the model feed-in to the filter when the machine is doing some heavy slippage. The target of the GPS/model is to get rid of the bias errors from the IMU and that works fine as long as you are in a “normal” driving condition.
As for data logging, shouldn’t is be possible to just connect the second UART from Ardusimple to one of the Teensy extra serial ports, and do the data logging from both IMU and GPS on the same go with Teensy (4.1 to an SD card, couple of those on the way)
If would be even possible to run the data fusion algorithm on the Teensy, which would deliver a corrected navigation solution. Of course, this gets bit tricky if you implement the whole INS/GPS fusion on the same hardware running the autosteer code.
1 Like
I was actually hoping to do this but I need time to investigate the issues and have been way too busy!!
I did some studying on this and have a few algorithms worth a shot. Trying to write the maths down when I get a chance. Will test out dumping the NMEA to Teensy via a second serial when the HW arrives, don’t want to tear up the working setup. Maybe run that on the tractor with WAS installed and see the correlation to wheel angle.
Please do. I would like to implement fusion on a teensy for another project. Would be interesting to see what algorithms you found. I was going to start with the filtering and fusion that is coded into AOG and see what happens.
I can find almost no academic papers or information on methods for fusing IMU with GPS to compensate for terrain. Seems like all the research is going into using IMU to inertially find your GPS position when GPS is blocked by buildings, etc. Not at all what we’re looking for. I guess I’ll start with a naive approach and see what happens. Very frustrating.
My thinking is more like this: To get a reliable vehicle attitude estimation, you need an EKF to fuse the GPS and IMU signals, you’re basically using the GPS to get rid of the gyro bias errors. You need to also transform the GPS velocities into the IMU coordinate frame taking into account the lever arm between the IMU and the antenna before the EKF. Then, with the fused pitch and yaw angles you can compute the path over ground by vehicle kinematics. That’s what is happening in the CMPS14 as well, it’s just using the magnetometer for the error calculations.
Yaw is bit more complicated as the vertical velocity is basically zero, as the observability is low unless there’s some accelerations present. I was thinking of adapting the way to deal with yaw from this: Improving Accuracy of the Vehicle Attitude Estimation for Low-Cost INS/GPS Integration Aided by the GPS-Measured Course Angle | IEEE Journals & Magazine | IEEE Xplore So basically run a separate cascaded EKF for the yaw angle with the switching off rules to not use GPS data when you know it’s giving wrong results in cornering and rely on the IMU accuracy for the short period of time.
Hi Micheal,
I have found this open source. GitHub - MapIV/eagleye: Precise localization based on GNSS and IMU..
When I watch the demo video, it works well but not sure how this will work if we port it into embedded boards or controllers.
1 Like
Like the green arrow in the video, GNSS 5Hz, I wonder if it’s 10 Hz. If so, would there be any difference?
Theoretically yes, basically you’re updating the error function with double rate in the Kalman filter so its performance should increase.
EPE and speed adaptive Extended Kalman Filter for vehicle position and attitude estimation with low cost GNSS and IMU sensors | IEEE Conference Publication | IEEE Xplore here’s another quite simple implementation maybe worth looking into, code on github GitHub - balzer82/ICINCO-2014: Paper for 11th International Conference on Informatics in Control, Automation and Robotics (ICINCO) (along with most of the maths)
I’m not sure how applicable any of those papers are, though. None of them address the issue of correcting GPS for the terrain using the tilt of the vehicle. These papers are all seem to be addressing the problems of high speed dynamics on the IMU and how to predict where a vehicle is when GPS is momentarily unreliable. While that kind of filtering is somewhat applicable to the issues of autosteer because it can extrapolate in-between positions thus making autosteer respond faster and smoother, it doesn’t appear to have much to do with calculating a new frame of reference on the ground based on the roll of the vehicle.
Seems to me that the only approach is the naive one that AOG implements. Using the current heading (calculated, filtered), at the moment of a new GPS position, use trigonometry to calculate the the position on the ground using IMU roll info at that moment (perhaps filtered and smoothed a bit). The result of that possibly could be fed into one of these algorithms to filter the final GPS position before autosteer uses it.
1 Like
Yes that is interesting. Is it doing roll compensation though?
I think I’ll start a new topic where this can be discussed because it’s off topic.
1 Like
Well, I don’t know if there’s much more to roll compensation than that to be honest. As long as the IMU / GPS combination is producing good data that’s it. Okay, if you want, you could add a vehicle dynamic model that takes into account tyre stiffness, possible suspension effects etc. My experience from using the BNO085 for tilt compensation is very good, the chip itself is using sensor fusion from the accelerometers to get a better roll. Main problems I’ve been experiencing on side slopes is more related to slipping downhill, and then the problem comes back to the fact that where the nose points and where the tractor is going are two different things.
My main motivation in those papers mentioned is the WASless steering, and for that you need to do some tricks on the yaw, which are pretty similar to those addressed.
Interesting topic overall, and I don’t there a clear wrong or right way of doing things. If you have WAS in the play, you can probably get even better by fusing the data from a simple vehicle model (bicycle, for example) into the IMU and GPS data.
2 Likes
I tried to figure out the entire code but it’s seemed a little complex to catch where the code flow is going. I guess it does compensation.