[BrianTee]

As far as control goes, Matt Reimer used a standard PWM 12V motor controller to drive the two solenoids for his autonomous tractor. PWM on one solenoid to steer in one direction, and the other to steer in the other direction I'm presuming.

I can't remember what valve block Matt was using.

But don't you also have to control the load sense line to get actual flow to start with?

 

[CQuick]

If you've got a spare spool it may be wise to use a standard proportional valve, 3 position, all 4 ports blocked in the centre. Works on older open centre systems too, placed in parallel with the Orbitrol. These are fairly inexpensive (£650).

CCLS systems need a pre-compensated valve with P connected to LS in all positions other than centre. Quite a rare part though I think, spoke to my local hydraulic supplier and even they didn't know where to start! A possible bodge would be to use a separate solenoid valve which fires in tandem with the proportional valve, and connects P to LS when active.

I'm planning to do my testing on an older open centre tractor so I can put the research on the back-burner for a while until I at least have a working autosteer using cheaper components

 

[BrianTee]

If you've got a spare spool it may be wise to use a standard proportional valve, 3 position, all 4 ports blocked in the centre. Works on older open centre systems too, placed in parallel with the Orbitrol. These are fairly inexpensive (£650).

CCLS systems need a pre-compensated valve with P connected to LS in all positions other than centre. Quite a rare part though I think, spoke to my local hydraulic supplier and even they didn't know where to start! A possible bodge would be to use a separate solenoid valve which fires in tandem with the proportional valve, and connects P to LS when active.

I'm planning to do my testing on an older open centre tractor so I can put the research on the back-burner for a while until I at least have a working autosteer using cheaper components

From what i understand the load sense line can be either direction too. Some sense a drain, while others sense pressure. Both end up providing a supply signal to increase pressure.

 

[torriem]

I don't know anything about the load sensing line. Matt has never said anything in his videos about that. From his writings on the diydrones forum, it appears he's just using this PWM motor controller with built-in feedback that he takes from a wheel angle sensor. His schematic only shows two wires controlling the steering valve: 12v for each solenoid. The steering valve he uses is made by Outback.

http://diydrones.com/group/ardurove...r-in-tractor-setup?commentId=705844:Comment:2147639&groupId=705844:Group:903163

 

[BrianTee]

If he is using an Outback valve, then yes, all the complicated stuff is done in there.

Geek chart! Nothing like seeing a picture of what is going on with parameters.....

 

[CQuick]

Initial testing! Couldn't get AOG to output anything useful so sent some 'dummy' data out of the arduino. All completely untuned, as you can see, but the concept works! Note that i the video I said '30 degrees' when I actually mean 30%; where 0% is full left and 100% is full right steer.

Next steps:

GUI - Add sliders for adjustment of parameters e.g. PWM floor (minimum PWM value for the valve to turn on)
Tune parameters such as input and output weights (and maybe tweak the membership functions, rules etc of the fuzzy system)
Remove arduino - for a more streamlined system. Only there because I didn't have time to code all the stuff in Python
Steering movement sensor - Automatic disengagement when steering wheel movement detected. Could possibly do it in code where it detects when it is 'fighting' the operator, although will need some careful programming to avoid disengaging when hitting a bump, etc.

All in all though, I call that a successful first test!

 

[BrianTee]

I've uploaded the latest AgOpen with the Arduino code under steer. It should work. You have to be within 3 or 4 meters of ABLine, and reasonable heading.

Hopefully it will work for you.

The Arduino code is very different in this one. It uses headings calculated based on distance from line, as opposed to a distance only and PID. Its a strange version of feed forward PID with the heading error being the control. That way there should be significantly reduced error by following a changing heading rather then trying to shoot for a line. Wish i had more time to play with this.

Your test looks great.

 

[CQuick]

Sorry Brian, couldn't get that to work either, won't even show the arduino data in the setup window. Not to worry though, i'm going to leave it for a few months until after exams/harvest, and just refine what I've got, maybe get a few boards made up. Hopefully will be able to resume testing in the autumn and winter. Thank you for all the hard work and effort you've put into this!

My code is up on Github if anyone wants to have a look (try not to laugh too hard!)
https://github.com/charlesquick/FuzzySteer

 

[torriem]

What exactly does the R code do? What is the principle by which it operates?

EDIT: Here's a link that describes the general idea, and compares it a bit to PID:
https://en.wikipedia.org/wiki/Fuzzy_control_system

So if I understand your code correctly, the pwm output for the steering valve is currently coming from the Pi, from python, and the steering angle is coming from the arduino, correct? The arduino is passing information from the tablet, combined with the steering angle sensor reading to the Pi over the second serial link, which then does the fuzzy control calculations to determine the desired steering angle, and then outputs PWM to the motor controller board. So really if you had a way of doing analog input on the Pi, you could eliminate the arduino entirely. Did I get that right? Is the Pi Python code real time enough to work reliably

 

[CQuick]

Torriem,
Yes you're absolutely correct. I only used the arduino because I was running out of time and it was easier to use Brian's existing serial code and make use of the Arduino's ADC. The Pi should definitely be fast enough to handle the calculations in real time, this is helped by the fact that the R code runs in a separate thread. The system takes a few seconds to load initially, but after that it seems pretty quick. If you like, I can run some tests to put a number on exactly how fast.

Edit:

You might be wondering how to decipher the .fis file:

Inputs distance, delta and speed are categorised into the relevant membership functions as defined in the 3 [input] sections. For example, distance = -323, delta = 52, speed = 6 will be sorted as follows:

distance only falls under the 'neg_low' membership function, to a degree of around 0.3
delta is 'pos_zero' to a degree 0.5 and 'pos_low' to a very small degree
speed is 0.6 'low' and 0.4 'med'

The [rules] section goes like this: IF (antecedent 1) AND (antecedent 2) AND (antecedent 3) THEN (consequent 1). Zero means undefined (so speed isn't evaluated in most of the rules)

i.e. 1 1 0, 9 (1) : 1 equates to distance, delta, speed, output, weight (always 1), evaluation type (1 = AND, 2 = OR). So it translates to IF (distance is neg_hi) AND (delta is neg_hi) THEN (output is pos_hi).

Evaluate all of these rules to the membership degrees we calculated earlier and then take the centre of the output and out pops your steer value.

I hope this helps you understand what I've done If you search youtube for Fuzzy Logic there's a few good videos on the subject too.

 

[BrianTee]

I believe the pi by itself would do the job. Especially if you ran freeRTOS on it. Much better, faster, and versatile environment then the Arduino.

I would say that the pi not being able to do this isn't the pi's fault, its the technique used. Absolutely, chop the arduino out.

I see an MCP3008 in your very near future

 

[CQuick]

Definitely using the MCP3008, already got some on order
I'm going to keep using Unix on the Pi, as it's also being used as an NTRIP correction receiver, and I really don't like the idea of porting that over to RTOS. The Pi 3 has 4 cores, so assuming my application will make good use of multithreading in the future then there won't be much difference between using Raspbian lite or RTOS?

 

[BrianTee]

Definitely using the MCP3008, already got some on order
I'm going to keep using Unix on the Pi, as it's also being used as an NTRIP correction receiver, and I really don't like the idea of porting that over to RTOS. The Pi 3 has 4 cores, so assuming my application will make good use of multithreading in the future then there won't be much difference between using Raspbian lite or RTOS?

Considering the glacial speed of autosteer, it will have no problem. And since it is such a special app, you can shut off many thing Raspbian is doing in the background.

 

[torriem]

CQuick you could try to run AOG on the pi itself through a system qemu emulation layer and wine. I would be really curious to see how well it works. https://github.com/AlbrechtL/RPi-QEMU-x86-wine . You don't have to implement a full x86 virtual machine. qmemu can just emulate the processor and thunk the system calls through to the actual Pi kernel. I used to use this all the time on my PowerPC laptop to run x86 linux binaries.

 

[BrianTee]

there is a lot of things that can be turned off in AOG. Minimize the graphics, and lots of the display 'nice to haves'.

 

[CQuick]

I'll give it a try!

 

[torriem]

Hmm I've been under the weather these last couple days so I gave it a go. The emulation layer works and I can run a complete debian x86 root just fine, but unfortunately Wine requires a kernel with a 3G/1G memory map split, and the default rasbian kernel is 2G/2G. Apparently you can recompile the kernel on Raspberry Pi 2 to have a 2G/2G split, but if you try it on the Raspberry Pi 3 (which is what I have) it simply won't boot.

There is a proprietary company that makes an emulation layer similar to Qemu that claims to run Wine from a Debian x86 tree, complete with OpenGL pass-through. https://eltechs.com/run-wine-on-raspberry-pi/ . Commercial product here.

 

[Henrique12]

Hello, after getting my AOG working i am now with the autosteer.

I have tested it at home, and it is working. Then I moved to the tractor.
The first time i used it, it wasn't the newest version, i have seen that there are changes in the autosteer in the new version.

After some time adjusting the PIDs and the motor speed at the controller i got it to "work". At pretty low speeds (~4-5km/h) it was doing ok most of the times. Sometimes it was more unstable i think because of the GPS. I am using a ublox M8N, the same i use in my "drone", it works very well there, but i think it isn't enough at all to this application.
At higher speeds it starts oscillating and completely diverges.

Here is my first question, there is any output scaling with the velocity? Reducing the output at higher speeds.

Another problem that i am having is adjusting the PIDs, i understand quite well the P, the I and the D, at least their mathematical functions. But i was having some trouble applying it in real life. I think that the fact that the GPS isn't good was making it even harder.

Test no. 2!
I have access for a few days to an EMLID REACH RTK, didn't have the opportunity to test it in the tractor. But i have kinda tested it in the car and it seems working a lot better now. I used the new AOG version this time.
I think this weekend i will be able to test the RTK in the tractor, so i am really looking for some tips tuning the PIDs.

Another question i have, i am not sure if it belongs here or the AOG thread: There is a video with an IMU, is it already working? Where i live it will make a difference being able to use it. But at this moment it isn't very important.

 

[torriem]

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.

 

[8582]

Don't waste time with the m8n, not accurate enough for this application. I tried to make my lawn tractor autonomous with the pixhawk and it had too much deviation that made pid tunning pretty much impossible. Not to mention it ran over one of the wife's shrubs.