[BrianTee]

Brian never got the IMU to work properly unfortunately. The unit he was testing drifted.

Does the ublox M8N do WAAS correction out of the box? Without at least WAAS I don't think it would be accurate enough for steering. RTK is definitely the ticket.

Its a strange little chip. Traveling at any sort of speed the pitch and roll are way off. If you stop, they are correct. Angular velocity works well, never tried any of the dead reckoning stuff. BNO055 was the Imu.

Henrique, pid is a fiddly thing. The code with AOG is a disaster! Its not even alpha version.

 

[CQuick]

Did some bench testing today (procrastinating from exam revision), interestingly the autosteer config window generates sensible data, but it doesn't seem to get sent out the serial port.. If you have any ideas why I'll be interested to know; if you point me to where in the code it is located, i'll try and fix it and submit a pull request.
Learning C# has to be far more interesting than reading about AI search techniques, right??

EDIT:
Just written a GPS -> UDP script to do away with serial into AOG for the input, but having thought about it there is a convincing case to send everything over TCP now as the communication is bidirectional. Although I admit that it would be pointless doing it for just myself, assuming everyone else is going to stay with arduino. What are your thoughts? I think the transmission delay is caused by Nagle's algorithm, which can be avoided by passing an argument with the data.

 

[BrianTee]

Both the UDP and TCP servers are bidirectional. The only thing that is missing is setting up all the framing so each application knows what information contains and from where.

Trouble is, its easy to say what is needed, but is a huge C# writing task. If you write it up, that would be great! Basically the whole program needs a framing style for all input/output. That was going to be next winters project.

Files of concern, TCP.CS, UDP.CS, MODCOMM.CS, FormGPS.CS mainly, but it pretty much involves every aspect of AgOpenGPS including the timing. If you get all that working, you wouldn't be the only one using it, we will all steal it no problem :sFun_mischieviousbi

You would need to write a robust system that can accept literally mixed up - even missing bytes from any source that successfully decodes into solid reliable information. You need to know the start and end of the original message and its source, utilize a CRC for integrity, and prevent hanging should any one of the sources stop midstream.

Have been looking into framing, decoding, NDIS layer 2 protocol and doing raw ethernet framing, but need time to read up more on it.

 

[Henrique12]

Thank you torriem, Beerwiser and Brian.

Yes, I am moving definitely to the EMLID REACH with RTK, as I said, this weekend i hope i can do tests again with the RTK, lets see if i can get a decent tune.

Brian, can you confirm that there isn't any reduction of the output to the steering as the speed increases? If it doesn't exist do you think it is a good idea?

 

[wvca]

reduction in steering speed would be a nessecary in my opinion

 

[BrianTee]

Brian, can you confirm that there isn't any reduction of the output to the steering as the speed increases? If it doesn't exist do you think it is a good idea?

None that i am aware of. Absolutely its a good idea. I also think path planning is the best way to go. A certain backwoods sounding sort of Australian company patented the concept, just have to figure out what is going on.

I'm pretty convinced a basic PID for autosteer is pretty much a non starter even. But love to be proven wrong.

 

[CQuick]

My autosteer supports a reduction in steering severity as speed increases; quite easy to achieve in Fuzzy as you just need to include the rule 'If Speed is High then Steer is Zero', which pulls the centre of gravity of the output fuzzy set closer to zero. Also there are multipliers you can use on the crisp output value to adjust the speed that the steering actually moves to the desired angle.

 

[BrianTee]

Did you get output from AOG for autosteer?

 

[CQuick]

Nope, all I could get out of it was '127'. Looks like it's not iterating (or not got time to iterate) through the byte array?

I'm home for a long weekend so I'm very tempted to go out and play with it again if it can be fixed easily

 

[BrianTee]

Long hours seeding, but i know it works. There is a new version up, but the autosteer part hasn't changed.

Does it look like the pic below?

 

[CQuick]

Afraid not. Just 127 in the output box. Input works fine and I can read the steering sensor and pid values no problem, just the output never seems to work. Section control output works just fine.

On a Switch Alpha 12 if that makes any difference..

 

[BrianTee]

Please take a screen shot of the GPS data window.

 

[CQuick]

Here you go:
In my last reply I misunderstood. I thought you were referring to the comms window, the app does produce the correct data I just can't see it in the comms window.

 

[BrianTee]

In the gps data window it shows what is leaving on that port. Disregard that com window. It shows the start int, section byte, speed times 4, distance, heading.

Its all there.

 

[CQuick]

It all works!! Need to do some significant tuning but the basics are all there.

 

[BrianTee]

https://youtu.be/sM43eoQQDUs

It all works!! Need to do some significant tuning but the basics are all there.

Yes they are lol

 

[CQuick]

Updated the model and ran some more tests. The updated FIS uses gaussian membership functions and an updated rulebase. A lot more tuning is needed as while it is much smoother, it's quite slow to find the line. I think a pid running alongside will help, using it to drive the valve to meet the steering recommendation. I think linearly controlling the valve is holding me back. Also the Universe of Discourse of the FIS is -15000 -> 15000 in Distance and Delta so I think I'll cut that down to +- 5000 to make life easier.

Next steps: Model it all in software and use an automatic tuning approach (maybe even venture into the world of neuro-fuzzy). And change AOG around for TCP comms. I may be some time

 

[teseler]

I there! I've been testing the autosteering today , it has been funny I don't know why but it didn't start correcting until it crossed the reference line, and stop correcting too early. I'll try to model the system with something like player-stage-gazebo. This is awesome

 

[BrianTee]

I there! I've been testing the autosteering today , it has been funny I don't know why but it didn't start correcting until it crossed the reference line, and stop correcting too early. I'll try to model the system with something like player-stage-gazebo. This is awesome

You may have to set a minimum pwm value so the valves start flowing oil as soon as the signal increases/changes.

You've come a long way, pretty cool!

 

[CQuick]

If you're using my system, make sure you're using the GaussAll-ruleset2.fis file. The line anticipation in the other files is not sufficient.

As Brian mentioned, adjust STEER_BASE and STEER_RATE to set a minimum PWM value and a multiplier.

Awesome stuff!!