To add some whiskey to the wine - fusion of gps and imu reduces that error to 0 drift.
Canada has good whiskey? 
Yes, that was what I’m talking about. And w/o steering wheel sensor, you need to guess very well the steering reaction of all the PWM preset. But appreciate to hear, you’re optimistic 
1 Like
Now this looks like a topic of flowing whiskey and wine 
As for the prediction, I would go with a Kalman filter with a model of the steering. Something like this that I built for the hydraulic steering: GitHub - jkonno/AOG-virtual-testing Similarly you could have a model of the orbitrol and the motor with slacks, delays etc. That’s just really a quick & dirty model, but you get the steering angle from the hydraulic input (+lots of the CAN communication stuff what it’s built for).
Bit related to this I’ve been experimenting with neural network + PID to have an adaptive PID for different driving situations, let’s see what comes out of that.
3 Likes
amazing to see how many professional methods are used in this community
2 Likes
It’s amazing, but sometimes farmers helping farmers work
3 Likes
Well with my limited coding ability, I’ve had a go.
This is a first attempt, coded tonight and first time out,on my motor steered 716.
Rough code and by no means perfect but this is running standard latest AOG, a near standard .ino, no additional hardware (no encoder etc), no ADS and no WAS. Performs U turns as well as it did with a WAS and holds the line reasonably well with no hunting at speed. It might never be good enough for real use, but after some rough code it isn’t horribly worse than when the WAS was fitted, and on a rough maize field too.
Following an AB line on a pretty rough maize field.
…and changing to a line 10 degrees to the left. I did try to film a u-turn too but my phone died. Hence short vids 
18 Likes
well done!!
hope you share the code and we can improve this!!
Really good Alan. I am curious!
nice! Are you using a motor position encoder or just the imu and angular velocity/acceleration?
Great stuff! Are you using only the IMU data or helping out with GPS to compensate drift or some other way of zeroing the drift?
Anyone got experience with the TinyEKF package for kalman filtering?
No encoder. Just the BNO085 yaw output that is already being read, and applied some rather iffy, way too linear maths derived from driving around in circles watching serial plotter and serial monitor. Also some light Kalman filtering. It needed tamer steer settings. The report interval is standard (90ms) too. Shorter may be better but with my first attempt code it actually made it worse.
I was that impressed with it last night given how roughly I wrote the code I actually had to test it again this morning with the WAS physically disconnected just in case it had miraculously mended it’self and also somehow enabled itself too!
Maybe a second BNO085 would be good running gyro output but my aim was to do it with no additional hardware so it could be used in a simple installation. The quality of the BNO085 heading output is what made me think it might be possible. I’m going to have another play with it later and hopefully clean up the maths a bit and try some different or even lighter filtering. It may not turn out to be any use but it’s interesting to try!
If it works ok ish and i can make the code a bit more refined I’ll obviously share it with pleasure.
4 Likes
Drift in the BNO085 running GameRotationVector at 0.5°/S ( and from what I can see significantly less than that) is that slow as to be insignificant to steer in this respect given the operating conditions, as far as I can see.
If I understand correctly then bno085 is in the AS box and not on the steering knuckle? What if I gave additional imu on the crossover and only take into account the differences between the imu AS box and the imu crossover?
That would then be very susceptible to drift as drift would create an angle differential. Also, in the spirit of how I am looking at it, it would defeat the object. It would require wiring and a fitment at the steering axle. If that is the case, it might as well be a WAS.
1 Like
I’ve had another play with it tonight and now I’ve got my head around the issues involved I think I could do a fair bit better yet. Half of it is understanding what detail is important and what really isn’t.
Do you think this might be a future solution for swathers and the guys with two track tractors?
1 Like
Do you thing that it will be better to use a f9r ublox with imu fusion ?
Hello,
Nice work @Alan.Webb !
It what I feel too when I look on IMU data while driving. But I never record data and carefully check that.
Math
So you’re just taking the AOG steer angle and convert that to Angular velocity required using speed and wheelbase in the ino?
If you do a quick search for angular velocity in ABLines.cs, you will find it calculates the angular acceleration of the setpoint in pure pursuit. You could substitute that for steer angle and save a bunch of calcs in your ino which would also allow you to play with wheelbase etc in AOG. With tan theta it calculates angular acceleration, but taking the integral gives you velocity, integral again is distance. You will need the first two to steer properly and tame the final heading by anticipating and possibly limiting the angular acceleration.
Fun project - keep playing! Seeding now so zero time for play for me. 
4 Likes
Basically, yes that’s what I’ve been doing. Very crude at first, based on figures derived from driving around with an arduino and a bno mounted on a breadboard.
I’ll look at the ABLines.cs code and see if I can work out your suggestion!!
It’s an interesting project, easy to play with and as I’ve got it set up on ADS differential (that I don’t use), it is easy to turn on and off!
Do need to sort out my WAS though as running a direct comparison would be very interesting.
…and I need it working properly for maize drilling!
2 Likes