Roll compensation thoughts

I’ve been working on a project (not related to AOG) where I need to do some roll compensation for GPS data. I was trying to use the roll filtering code from the arduino sketch from AOG and use it’s kalman filter but the filter is way too slow for what I need. I need to be able to actually compensate for small bumps and little ditches, so I’ll need to reduce the filtering a lot. But less filtering means more jitter. I got thinking about ways of dealing with the little bumps that inevitably cause noise or just arrive too late to be useful.

I had an idea that might hold some promise, but it’s extremely computationally intensive and not suitable for an Arduino Uno or the like. So basically the position that we care about, that is used for everything in AOG is the position calculated with the antenna offset stuff. So what if we treated it all as a trailer system. The GPS receiver position leads everything, and the “offset” position is the trailer. This gives us a very small trailing moment that can absorb some of position bumps while still always tending towards the real position, essentially averaging things out, especially on long, straight runs. In actuality a tractor is a trailer system, with the front axle leading. the rear axle which is a trailer.

I did a bunch of tests in simulation, introducing random bits of noise to the roll and trying to compensate for it and see what kind of tracking error I got. It looks like it does work to greatly reduce tracking error. Not sure yet about the real world though. It’s crazy and it’s very expensive (takes a lot of trigometry to do haversine calculations and work in lat/lon coordinates which I need), but it’s completely doable on an ESP32, Due, or Teensy. calculations take less than 1 ms on those boards, so doing that calculation at 10 hz is no sweat.

Anyway, not sure this would be of value to AOG or not, but I’m going to try a real world test of it to see if it can work.

1 Like

Is there any merit in using a hall sensor for font axle articulation? That would basically give forward measurement of expected roll.

Sounds something like hedge trimmer level compensation in it’s requirements.

I am wondering about excavator guidance. Another hugely expensive area with not overly expensive technology.

Fast Fourier Transformation (FFT) and DSP filters

1 Like

As there is a relationship between lat/lon and heading it should be possible to use a multi dimensional kalman filter. The logic could be: as heading doesn’t change, the projected waypoints must be on a line. With this and a slow roll compensation you should be done

Possibly. I was thinking along those lines also initially.

The difficulty I see with making the roll value slow and smooth is that there are times when the tractor must make a fairly sudden correction to stay on the line. This is very apparent on my sprayer tractor (using John Deere’s autotrac) when I cross a ditch at an angle, for example. Has to steer one way, then the other way. In other words it needs some active steering to stay on the line. This cannot be done when the roll is filtered too much, and if it was ignored completely that would can really whip the sprayer around.

There are definitely lots things worth exploring for sure. I’m not sure I have the skills to understand the kalman filter, let alone try to implement a multi-dimensional one! :slight_smile: To say nothing of FFTs, which I agree are probably applicable here.

Could be. Not all tractors have pivoting front axles ahead of the GPS receiver, though. My 4WD, for instance.

I fail to understand why the sensor is so noisy in the first place.

1 Like

My issue is that for my purposes at least, I need to compensate for not just the overall average roll, but the little bumps too. As roll filtering is reduced the question is how to determine what is noise and what is roll that needs to be compensated for (going back to crossing a ditch as we’ve talked about in the past).

I am sure you will find no matter how you do it, it all comes down to filtering and ends up with associated delays/phase shifts. Engineering problem as old as time.

1 Like

Yup. But apparently a solved problem, because I can run Autotrac and it holds the line very nicely, while actively steering over bumps and ditches. That’s what I’m trying to match/replace.

If you could do some sort of slope rejection it may be better. Hence the FIR or IIR filters. I think there is real promise in those using digital low pass

If you started with the same imu, that would help considerably. As well as a team of engineers to write the EKF code. That’s some real voodoo. The right combination of gyro and acc is amazing. Plus they have direct access to the fixes where all we can use is so delayed from nmea.

I’ve used this site before for FIR. even generates the source code.

Yeah you’re right! Theoretically, though, we can get fixes from GPS at a very high rate (is 20 Hz possible?), so fixes don’t have to be delayed all that much. IMU information comes in at a pretty fast rate also. So yes there’s always latency in the GPS, but might not be enough to matter.

This stuff is so fricken hard,

I was going to put the antenna on a pole and mount the inclinometer at the base and see if under ideal conditions i could correct the position when swinging it side to side.

Would take out a LOT of variables

1 Like

No kidding! I thought of that too. For surveying. Of course not only do you have to compensate for pitch and yaw, but you have to deal with magnetic compass information too to know which way it’s facing (and thus compensate in the right direction).

Anyway I’m having fun doing some hacking and if there’s anything of use to AOG I’ll report back!

Really appreciate this! Hope you have fun and learn lots!

BTW have you seen this!!! CAN Bus Sniffer - Reverse Engineer Vehicle Data [SavvyCAN/Wireshark] – CSS Electronics

Very handy! In my travels I’ve not used wireshark so far, but I’ve got some things in mind in the future that it would be handy to use for making sense of a very busy bus.

I’ve got in mind a project to control throttle and PTO through the CAN for running the auger remotely at harvest time. There’s a lot of traffic on that bus, so might need wireshark to make sense of it.

The cool part is you can quiet all the normal traffic, do the action, then have a hope of finding it

1 Like