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.
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! To say nothing of FFTs, which I agree are probably applicable here.
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).
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.
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.
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).
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.