Good night. I am practicing with agopengps in simulator mode, I have recently discovered the program and I really like it.
I am trying to read as many topics as possible, but many times it seems that you are speaking in Chinese, there are terms that I do not understand, I am Spanish and I use the translator to read everything. I would like to mount agopengps on a tractor as simple as possible, just drive in a straight line 300 meters, the terrain is flat, as it is leveled with laser, I would appreciate your help. Thank you very much for all the contributions you make.
One thing i noticed is the frequency of imu access. if you do say 10hz, the heading delta is mostly zeros or just to small to detect. Using 3 or even 4 hz greatly improves the “jumps” which then allows getting a useful number to compare against setpoint.
Either that or a highly stable and very accurate imu with accurate gyro - like what is on my 4WD, no WAS, just single antenna and a pricey canbus imu.
My plan was to try my fiberoptic ring gyro thru the ads. Its a single gyro in a box - that is all it does. The one decimal CMPS won’t cut it.
Checked the BNO085 datasheet, it’s 16 bits for ±2000 deg/s so the gyro resolution is around 0,06 deg/s, something like the Honeywell TARS IMU has a resolution of 0,00875 deg/s so an order of magnitude jump. I guess it’s the huge range of the BNO085 that’s limiting, everything ends up as a 16 bit integer in the end as the TARS range is ±245 
Have been thinking about testing out the Aceinna OpenIMU, bit pricey though but maybe could integrate some of the code directly in the IMU and would go well with my current CAN flair…
I stared testing the idea on a breadboard with just an arduino and the bno085. Initially in gyro mode but now in gameRotationVector and measuring difference over time. Multiplied up for serial plotter visibility, it is possible to get some really smooth responsive output form very slow rotation. Both modes can be run at once so I could alter duration by running gyro output at a different rate than gamerotationvector. GRV delta and gyro do produce a near identical result. Gyro has the advantage of not being affected by small loop time variances.
I’ve only just realised I can run both modes simultaneously! 
Actually not sure if gyro has as high a resolution?? Need to check.
My thinking is I need to filter noise at source, with as little latency as possible. I’m already throwing out high delta’s. I need to remove high accelerations too. Latency is a killer. Literally sending AOG raw GRV delta or gyro velocity (over speed) is miles better than any significant unweighted averaging or Kalman filtering.
1 Like
This, in our environment is a very VERY slow rotation. Given the slip, lash and general noise in our system does it really have to be any better? Could we realistically get this accuracy out of a WAS, bearing in mind it’s heading, not where the wheels are pointing that really matters, and the two are linked by a complex linkage relying on rubber and it’s friction with soil!
Good points, I had the same thought last night (autosteer is starting to enter dreams…) that it should be better than WAS in the sense that it’s controlling where the machine is going rather than where the wheels are pointing, especially on soft ground etc.
Bloody ploughing is eating time from autosteer development 
2 Likes
As I said somewhere up this topic, the key is not just working out what really matters but also what doesn’t.
That was one of the thoughts that started me thinking about this. It is amazing how well it manages to steer with completely unfiltered basically raw rotational velocity adjusted for speed. The key is allowing through the filter what physically can happen (and is happening), whilst blocking what can’t (high velocity or velocity change) without causing any latency.
There is possibly an intrinsic link between yaw noise and high roll velocity, which would be quite easy to factor out. Values that coincide with high roll velocity could simply be discarded for example. My next test area maybe.
Above all else, latency is the killer. It has to be faster reacting than the steer motor.
Perfect roll and pitch don’t affect yaw at all but a pivoting front axle obviously adds yaw to roll. This could actually be factored out with reasonable mathematical accuracy.
I’ve just spent about an hour playing with angular velocity and acceleration limits and the bench output compared to raw is hugely better with practically zero latency. Factoring out roll velocity effects now think.
[edit…]
Actually dumping values corresponding with high lateral acceleration seems to work very well!
I need to get this in the tractor tomorrow!
So you just check for acceleration and discard the yaw values when lateral acc is above the limit?
Heii, big Idea cant believe it as i seen the Video. Really Great. Have you already tried some Ab curves? Maybe also a great Chance to compensate the drift on hilly conditions. Will it help to have a dual Antenna? I dont know whats heading wise better.
That is what I’ve just tried on my bench setup. Seems too work well. I need it in the tractor again now to see how the alterations have affected it. My previous filtering wasn’t fast enough reacting. My hope is by discarding or limiting unrealistic values or values not relating to yaw, I can get away with much less filtering.
As I said above, it might never be good enough for general use but even in its roughest state, the basics of it do work.
I think the biggest issue with dual is a fundamental flaw in how it sees heading. Heading is absolutely NOT where you are facing. It is where you are going. They are not the same.
Deciding whether a concept like this will help takes a bit of thinking about!
3 Likes
Hello
Yes you can ask BNO085 to send multiples repports, very powerfull ! The only limits are:
- A maximum data rates for each repport depending on the processing time of the data
- The bandwith of the interface
I don’t know about the performances we need. Farmtek haven’t share his solution, but what I know from discussions on French telegram is that he used the BNO085 in GRV. So BNO085 performances seems to be enought.
I’m not sure to understand what you mean exactly
Math
Blockquote
I don’t know about the performances we need. Farmtek haven’t share his solution, but what I know from discussions on French telegram is that he used the BNO085 in GRV. So BNO085 performances seems to be enought.
Not sure any of us will ever know what he has done - or even if it is actually just an imu. He is unapologetic to take the source code as his own, not share anything, so who knows what is real and what is not.
3 Likes
I wish some AOG users had the ability to remotely lock their programs with a single button.
I’ve finally managed to get a revised bit of code out in the field tonight. A very VERY wet maize stubble now. Rutted and extremely slippy, with a tractor on near bald tyres!! In these conditions the WAS less steered code easily out performed the WAS standard code. Standard struggled to cope with the considerable side slip and tracking along ruts (in PP. Didn’t try Stanley) whereas the WAS less responded immediately to any unwanted rotation. Even a huge bump didn’t seem upset it.
Not overly easy to see how well it is working from this pretty poor video but it was pulling sideways hard at the start. Roughly 15kmph and no steer hunting either.
What I really need now is some good conditions to test it’s accuracy, and possibly refine the rotation and filtering vs speed.
12 Likes
I would think the slower speed is where the challenges are. Good work !
Just thinking out loud, but just like the imu helps straighten and tame the gps, i wonder if the imu can also tame the steering with a WAS.
1 Like
Yes, you could be right. It finds zero really well too.
It actually works well at lower (say 3-4k) speeds, the issue I’ve had is preventing steer hunting at speeds say 8k+. I’ve gone around in circles with filters and averaging etc. written semi complex algorithms and actually ended up deleting most of it.
If you imagine the data as a box of apples and you obviously want all good apples. I started out sorting the box to reduce the bad ones, but I’ve now ended up not sorting the box at all, just not putting the bad ones in in the first place. Basically zero latency.
My next task is to monitor exactly how many values are being dumped and tweak my parameter limits to get an even cleaner signal.
It uses the BNO085 Gyro output for rotation velocity and acelerometer to check for high lateral acceleration which may affect rotation values. Relatively crude value dumping depending on a maximum rotational velocity, rotation velocity acceleration and lateral acceleration.
If the rotation velocity was a perfectly clean signal, that plus speed is basically all you want.
AOG will actually handle and prefer a very spiky WAS input far better than an inaccurate or even worse delayed one.
What would be handy is if I could tweak AOG to allow the GPS speed to react slightly faster to coming to a standstill. Only a bit. Failing that I could check for low speed and a deceleration rate likely to mean an imminent stop.
Obviously as this relies on speed as an input, I’m using a low speed cut off. 1k I think, at the moment.
5 Likes
11 Likes
There are many factors at play, it only took about 3 years to figure out WAS steering, so it will take some time to figure out WAS_LESS as well.
As soon as you add any sort of filtering there will always be delays. One thing you might consider is not to use the formula for angular velocity as is, but rather make it speed dependent to reduce angular velocity as opposed to increasing angular velocity based on speed. Just like variable ratio steering requires less turn of the wheel as you go faster, the required angVel should decrease rather then increase using traditional velocity formulas.
3 Likes