Roll compensation issues / questions

After getting setup in the field over the last few weeks, and testing in a levelish field / getting good results, today was a real life test… Having some problems with it following the line on the side of a hill, and a little confused as to what I should be seeing on the screen or shouldnt.

So I am using an MMA on the PCBv2, x axis, and have zero’d it out in the yard on the level… it seems to report very similer angle to the greenstar in the same place, so seem to be working…
However, when running today, A-B lines on the side of the hill, I dont seem to be able to get it to stay on the line, it will always run 30-40 cm to the side. From my understanding, the roll value, is used along with the antenna heigh value, to calculate the amount of sideways movement at the antenna point, which is then added / subtracted to the GPS position to compensate for the fact the tractor is at an angle? So as far as AOG is concerned, level, or side hill, it should still follow the line, and be aiming for 0cm error on the lightbar… Is this correct?

If that is the case, why would I be seeing this problem, it will happily drive a straight line, but sits 30-40cm off to the right, however it doesn’t “attempt” to correct it, so doesn’t seem to be a steering issue, as if you view the steering chart, set point / target are right inline with each other, it just seems to be happy to go along at that point, sometimes will even get 50 -60cm, and then it will flick to next A-B line! and drift again, then flick again, and end up driving diagonally down across the field!

I am using PP, and tried dropping the lookahead a bit, which didnt seem to make much odds, the only setting that did, was the sidehill drift compensation…but I thought this was meant to be to move the tractor PAST the A-B line on purpose, so that the implement would then follow the A-B line to account for drift on the side of a hill? by adjusting that, I could get it to come up to a better position in the outside world, but obviously still appeared off on the screen…

Am i right in thinking that no matter what is going on, AOG should always be aiming to drive the tractor towards the A-B line in all situations on straight track? In which case, what could cause it to happily drive along next to it, but not on it.

Have confimed WAS 0 many times…and when on level ground, it will follow the line +/- 1-2cm normally!

Because of the side draft AOG’s steer to correct the small error isn’t actually correcting it (just balancing it) and because there is no integral function it doesn’t know it’s not correcting you so it sits in a happy equilibrium off line.

Yes, I understand my problem now, nothing to do with roll…Its just side draft being caused by the offset mower, which is alot worse on the side of the hill…And I think because P only PID, it just uses its error, and P value to give output, which under normal conditions is enough for it to correct…but when slipping sideways, or like this, with extra drag to one side, its no longer enough, so just equals it at and drives off line…

Adding an integral I think would fix this? So the error can add up / start to add gain to correct it? is there any reason why I is missing? Assume it probably causes another problem that I havent considered? If not, any chance of adding the I value in a newer version ?

1 Like

Basically the same as having an incorrectly set WAS or a drifting IMU. They all, for differing reasons, produce the same state of equilibrium, off line. Because AOG thinks it’s correcting it but doesn’t know it isn’t.

As i understand, we would need to add integral to the loop in AOG that outputs the requested wheel angle…not the PID in the ino, thats just the Wheel angle loop to meet setpoint, we need AOG to request that setpoint in the first place as there is no problem at all matching the request, its just simply not requesting enough when we are drifting / high draft due to no integral adding up… As i understand anyway

EDIT…but, is it even PID that generates said requested angle? or is that stanley / PP…wish I was more clued up on this stuff…but thinking it is…in which case, how can we add an integral term to this calculation to get better correction when off line?

So sorry for asking a dumb question but are you guys saying that their is a problem with the way AOG is handling a side slope or is it just compensating for side draft?

Yesterday I was planting corn across the slope and AOG was doing quite well. The tractor went perfectly along the line. The problem was only with the trailed type seed drill which slid slightly down the slope.
The tractor is MF 5455, version AOG 4.2, control on cetop valves.
Maybe you should still try to set PWM?
I also think that the compensation compensator that I have installed does its job.

It depends what job you are doing to how much its a problem, for example have been tedding grass lsat couple days, which is center pull, and doesn’t take much to pull, so tractor doesn’t require much steer angle to stay on track, I was rarely over 5cm from line doing that job, even on fair side hill…

However working ground, mowing, or anything that loads the tractor up causes less weight on front wheels, more tyre slip, and just generally requires more steer angle to pull the tractor up on the line, in these jobs I am finding it sits 20-30cm off line, sometimes more…But its not a PWM / PID arduino issue, as wheel angle is perfect in steer chart, its reaching its desired setpoint, the problem is the set point coming from AOG just isnt enough steer angle to get it back on line…

I don’t know if PID i involved in PP / stanley, but i feel where that calculation is done, to determine desired steer angle, there needs to be an integral, So when in a situation where its offline, but its giving it all the angle it can, it builds up / pulls it closer to line by requesting more steer angle…

Its not really a “roll” problem at all, or side slope problem, its just the lack of ability to add anymore steer angle once you start getting further off the line…Technically with huge side load, you would notice it on the level to…It just so happens that on the sidehill, you see these problems… Roll works fine, in terms of, it see’s a slope, and compensates GPS position perfectly (in my case its done in dual GPS), but either way, theres no issue with that, if you have no load on the back, it will follow the exact tractor marks on the side of a hill in both directions…

@BrianTee do you see what im saying / think there is anything we could improove upon for this?

I tried to work with the mower and actually pulls off the line but there is a fairly constant value that can be corrected by moving the 0 steering angle sensor in the right direction and practically going well. Of course, to work with another machine you need to remember to change the sensor.

Yes, This will work, but that kind of re-inforces the problem…obviously this isnt a solution as it depends on condition, implement, slope, etc so no one setting will “fix” the issue…it needs to be able to auto compensate so no matter what, it will always TRY to get back on line, well until you run out of steering lock anyway!

I have to admit that I sometimes correct the 0 steering sensor when I pull the tractor off the rope for various reasons. If by correcting this parameter manually you can maintain the correct path then you may need to add a function that will automatically correct this value. The loop would check for the average error value over a specified distance and add / subtract degrees to the steering angle sensor.
I’m not a programmer and a mathematician, so it’s possible I’m wrong.

Something like this could be possible and would be useful. It would not have to be part of AgOpenGPS to keep AOG as simple as possible.

Our Topcon screen has a pretty complicated calibration wizard built in. Also takes care of roll calibration by driving the same A-B line back and forth and calculating average figures. The screen itself has a magnetic field heading sensor, not sure how it is used but this too gets calibrated.

For AOG I feel the “main features” are the important ones, AOG users likely accept some “manual calibration tasks” if it frees programmers’ time for more important topics.