# Steering a combine via GPS

I’m an arduino noob, and this is my first project using an arduino. I’m using it to read inertial data and control a hydraulic valve, which is used to steer a combine. The machine is a Case IH 2588, which is 285 HP, and weighs about 30,000 lbs. I have a Windows 7 computer in the cab to process the GPS data and calculate steering angles, and the arduino is my IO card. I eventually plan to offload all of the steering calculations to the arduino.

The system uses GPS data, an inclinometer (measures tilt), and a yaw sensor. We want the machine to travel back and fourth across a field in parallel passes. The computer will keep the machine driving straight, within about 3 inches of the desired path. The distance from the path is called cross track error, and I’m seeing an average cross track error of under 1.5 inches.

We are harvesting soybeans in Iowa, traveling 4 to 5 MPH.

More Pictures:
http://lefebure.com/farming/2009/september/

Video:

-Lance

Thats and awesome project! Lots of great shots too - good job man!

I love it, anybody who can see past LEDs and servos with an arduino deserves encouragement. Bravo. :)

Impressive project!

I've done a marine autopilot based on Arduino (using GPS, Gyro and Compass for course keeping) and it would be interesting to know how you achieve an average cross track error of less than 2 inches?

I'm way impressed but I have to ask - what's the failsafe?

To get the cross track error down to this level took some time. Part of it has to do with having a proportional hydraulic valve to get smooth slow steering when needed, and fast response when needed. Part of it has to do with how to get accurate heading data - couple the yaw sensor to the GPS data with a Kalman filter. A steering angle sensor helps, and the steering algorithms were critical to being able to keep the machine smooth. While a 2 inch average cross track error is sweet, my goal is to get that down to the 1/2 inch range.

There are several failsafes built in. The system will not engage or operate at speeds above 6 MPH, the system disengages if the steering wheel is moved, the arduino will close the valve if it doesn't receive any data from the computer for 200ms, and worst case, there is a power switch in the cab to kill the circuit that drives the solenoids on the hydraulic valve.

At the speeds we normally travel at, nothing serious will happen if the system freaks out. At 5 MPH you can stop, shut the system off, back up, and keep going. The critical part is when we're on the road at 20 MPH. While that isn't fast in a car, these machines with rear steering aren't very stable at 20 MPH. When on the road, we flip the lockout switch in the cab so the valve can't possibly open.

-Lance

Nice project. What computers are you using in the cab?

nice application! there are commercial things like this, but making it with a arduino is a lot smoother :)

There are two computers in the cab. One is designed specifically for monitoring the machine and recording data about what it does. The other is a Windows computer for the autosteer system. The motherboard is an Intel D945GCLF2 which has a dual core 1.6 GHz atom processor and 2GB of RAM.

Is that a touchscreen monitor hooked to the computer or do you have a keyboard in mouse that you use? I am looking for a good touchscreen solution for some automotive projects.

It is a 10.4" touchscreen. Just a cheap one from gooddeals18.com which I found via a thread on the MP3Car.com forum. The screen was \$212, and it seems to work fine. Unfortunately, it doesn't have a standard 100mm mounting bracket on the back, so I had to make a bracket to hold it.

Hows the project coming along?

What kind of accuracy are you seeing? Im considering doing something like this for my parents, but I need some pretty extreme accuracy (accurate to 2" at the VERY WORST, preferably 1"). John Deere sells a system that can do this, using DGPS and a portable base station, but the setup is around \$40,000. Have you looked into using DGPS at all?

Project has been untouched since we finished harvesting soybeans. Performance was down to an average cross track error of about 2 inches. I was running a 7 inch overlap between passes without missing anything.

In terms of accuracy, there are two variables. GPS position accuracy and vehicle control accuracy. The GPS accuracy part can be resolved by using a RTK system, which will get you to approximately 1 inch position data. The vehicle control part is my problem. 4 MPH may sound slow, but a lot of things have to happen in order to keep that machine within an inch of some imaginary line, especially when you're on rough ground.

I've used DGPS when using the WAAS correction signal, but it can drift a few feet in an hour. RTK is much more stable.

-Lance

We've got a JD 9550 that we use for corn, beans, and wheat, so I know alllllllllllllll about driving slow ;) I was looking at using some sort of DGPS system to auto-steer a plastic-laying tractor in a straight line; thats all it needs to do. Im not interested in it turning around or doing much, it would just involve the operator lowering the implement, enabling the system, and putting it in gear, and having the auto-steer system keep it in a straight line.

Do you have any insight to share about RTK?

You are a smart man Lance!

nice application! there are commercial things like this, but making it with a arduino is a lot smoother

and a lot smarter and I would reckon a bloody lot cheaper

John Deere sells a system that can do this, using DGPS and a portable base station, but the setup is around \$40,000.

I wonder how much in dollars you have spent and what sort of hours input? How many hours would it take now to put one together? Could we get any pictures of the install?

So there goes the lunchbox heh!

RTK is nice, but everyone charges a lot of money for it. GPS+Glonass is the new thing, which gives you more available satellites. That eliminates those times when you don't have enough GPS satellites to get a RTK fix.

tytower, for the amount of time I have in this, it would have been cheaper to spend my time at a normal job and just buy a system. That wasn't really the motive though. When I started this project, it was partly because I was so disappointed with the user interface of the existing systems. The industry has figured out how to make it work, but hasn't figured out how to make it friendly. I think I have the UI part working well, but the technical part is a bit of a hang up for me. Of course, I didn't go to school for any of this ridiculous math stuff I've had to learn. Google "Kalman filters" if you want a headache. It has been a great learning experience.

There are pictures (and links to more pictures) in the first post of this thread.

Nice. it is this type of innovation people should do and not just repeat simple projects (just look at how many segway arduinos there are). Now you should add obstacle detection and a kill switch (i hope you have it and just didn't mention it).

There is always an operator in the cab, so the obstacle detection is human. There are things such as inactivity timers and using the field perimeter as a virtual fence.

The kill switch is a sensor on the steering wheel, so when steering wheel movement is detected, the automatic system disengages.

Of course the human factor doesn’t work 100% of the time, and sometimes you fall asleep. Then things like this happen:

;D and here I am, worried about getting stuck in the snow.. :D

You've got to let us know how you get it out! Haha. Time to add some boundries in the software, so hopefully you don't run off course.. or at least it'll know there's a stream ahead. :)

That pic isn't one of our machines. We've never had an issue, but I can see how it is possible. You run a machine with autosteer long enough, and you'll find yourself waking up to the end-of-row beeper once in a while.