An on wheel permanent AHRS? (parallel to the wheel plate, bluetooth and motion energy harvester (to avoid batteries) or tiny solar with consumption below 10mA?
Hi all, I’m a bit late to the party here having just discovered AgOpenGPS and now have built a system which I am currently testing out.
I’m intrigued by this development for a WASless system posted by @Alan.Webb , which from my understanding of reading this thread seems to have been implemented successfully.
So, I’m wondering whether this could/should be incorporated into the official build of AgOpenGPS, that could be enabled/disabled via a configuration setting? Seems a shame for this work to have been done but not have it available within the official build.
I do plan to use AgOpenGPS with a conventional tractor, but am also particularly interested in trying it out with my Kubota ZD1211 zero turn mower, which of course wouldn’t be possible if a WAS is required.
My thought is that it could be the basis for the ultimate robot lawnmower, in a supervised environment of course by still sitting on the machine ready to take control rather than in an unattended way like the commercially available domestic robot mowers.
How we then actuate the steering levers automatically is another question, but that’s a problem to solve for further down the line.
I can’t speak to WAS-less autosteer.
AOG has been successfully implemented on swathers. Most (all?) swathers are much like a zero-turn mower, under the cab somewhere is a linkage arrangement that operates two levers on two wheel motor control valves. The difference in position between those two arms is the wheel angle.
On swathers people usually seem to be able to mount the sensor on one arm and connect the linkage to the other arm, thus measuring the linkage different directly with a single sensor. “Difference” in math is the subtraction of two numbers. For your zero turn there is no reason that you could not measure each linkage with its own sensor and then calculate the difference in position with code.
One WAS signal would be hooked to the high signal and one would be hooked to the low signal on the AMPSEAL. I believe the code is in place for differential WAS but someone can correct me if it isn’t.
I don’t have any experience with this but couldn’t the IMU yaw rate simply be scaled to an appropriate WAS angle?
Yeah
I think it’s yaw rate multiplied or diveded by speed.
With a little bit of filters.
And the minimum speed to autosteer a little higher, like 2-3 kmph
It should be relatively easy and only need changes in the ino.
@Alan.Webb said it worked well as far as I remember. His code would be a good base if someone want to try.
Thanks all, all very helpful. I had seen the differential WAS input on the pinout but wasn’t sure what it was for, so that makes sense.
So essentially we would be using a pair (or one, with appropriate differential mechanical mounting) of angle sensors simulating a ‘virtual’ steering angle to feed into AOG.
But then following on from that, if we were to use a pair of linear actuators for example to operate the drive levers, the angle sensors may end up redundant as we are then physically commanding the L/R lever positions and thus can calculate the virtual steering angle from that in the same way, assuming the linear actuators have absolute positioning capability.
I would still like to try the code provided by @Alan.Webb , which then goes back to my suggestion/query about whether this code could or should be merged into the official AOG codebase and offered as a configuration option within AOG, if it’s felt stable enough to work fully.
Whether it would ever be considered for merge would depend entirely on its performance.
Sorry, not been on the forum for months. My code was just an attempt at proof of concept and had many glaring errors in it! It did however work. I did a full days maize drilling with it. Merge worthy it definitely is not, in it’s present form.
I actually had no real need for it but when a prominent developer said IMU WAS emulation would need an expensive IMU and complex code I disagreed and had a go.It needs neither.
We are working on the AiO v5.0 firmware now. Would like to take a look at the code. Do you have a GitHub repo? If not can you send it to me in a PM? Or you can put in a pull request to the active dev repo and we’ll take a look.
It basically created the AOG WAS value input by using a function of angular velocity and speed. Noise is obviously an issue with a bumpy environment. Any sort of filtering that uses averaging is a big no no as it causes latency. I tried filtering out obviously incorrect data and that helped. BUT it is surprising how well AOG accepts a VERY noisy WAS input. In moderately undulating conditions the tractor stayed on line better that with a hardware WAS.
As ive got developer attention… The last video is WAS less curve following. Even with a WAS the latest versions of AOG are nowhere near as good as some of the older versions at following curves. They cut corners and overlap. Older versions like the one in the video were extremely good at this.
This looks great Alan - is all this done Teensy-side, or are you changing AOG as well?
I’ve a JD to look at soon, and local dealer wanting over £800 for an autotrac WAS. Obviously, I’d go the LR route instead, but would love to try this as an alternative if possible?
Is there anything that would prevent this working on articulated or rear-wheel steered machines? Doesn’t sound it, just wondering…
Cheers!
Was this with a dual or single + IMU setup?
Wasn’t even a teensy on this tractor. A lowly Arduino nano and yes, all MCU side. Completely standard AOG. Teensy would be better. My CAN bus Fendt 724 uses a teensy but that uses the Fendt steer system so isn’t really applicable to this idea.
Single F9p with a single BNO085 used for roll and angular velocity.
Back in the keep it simple days, the BNO would have also been connected via i2c
Interesting… Any code we can see perhaps? I’d like to try and adapt for teensy if possible ?
This one I guess
Thanks - added it in, compiles now on Teensy in AIO4.1 Micro firmware. Will see when I can next try this out.
Cool! I am curious how it’ll work for you, or if more tweaks need to be made.
I guess I am the most excited about how this could make AOG installations simpler and more portable.