Wow its funny, we have some of the same problems just at different scales. I would love to deep dive on this but still having annoying issues. Come to find out ZTR mowers don’t have electronic steer like tractors to interface with :D.
Since the scale I’m working with is much small I’ve been considering offering a service to calculate coverage in an easy to use interface. Basically plot the land you wish to cover, mark any obstacles, and the general direction of passes (N-S, E-W) and let it spit out a plan. Idea being make it so easy a mowing operator can make a plan. BUT still got other things to get working before I get there.
I am also interested in making a system that someone can use to survey a field and then easily direct a tractor to cover it.
If you really want to get into it, there’s quite a bit of research on coverage path planning for agriculture. As you might expect, choosing the right angles can result in some efficiency gains, especially for vehicles that spend more time turning on the ends than your ZTR.
I have a ZTR that I’ve considered automating. I assume it’s just two hydrostatic drives. I controlled a single hydrostatic transmission on Tractobot00 using a linear actuator.
Agreed, I’ve checked out some of the white papers and they show some promising stuff. With a semi-optimal path I think I can also save on fuel cost in the long term better than a human operator. I can’t wait to get this this stuff as it is way more interesting than fighting hardware.
Part of my goals is to build a hardware setup that requires no modifications to the mower other than bypassing sensors. That has turned out to be a bit more tricky than expected.
Also what I find very interesting is I don’t see any modification to your mower.
I suspect there are a lot of people who would enjoy projects like this. I’m looking forward to pulling all of the pieces together in a way that others can easily follow.
Pneumatic cylinders with feedback at a reasonable price are fairly hard to find and the price still approaches what you’d pay for an electric linear actuators with feedback and valves. Servo controllers for linear actuators (which I have tried but do not use) are readily available and make control easy. (There’s no need for steppers.) https://www.servocity.com/html/jrk_12v12_usb_motor_controller.html
I have plenty of pneumatic gear but I have no desire to mess with a compressor on my tractors.
Thank you, Igor. I’m only interested in F/OSS software and I have the parallel driving pretty well worked out. In fact…
I’ve been meaning to update here that I was able to use Tractobot01 to drill a few rounds of soybeans completely autonomously! This video is of the first turn at very slow speed. I did jump in the cab because I thought it was going to hit the fence but by the time I got in, it had started the turn.
I had set the lift point incorrectly (because I hadn’t measured the distance from the GPS antennas on the tractor to the implement). I fixed this and then it went very well. I raised the speed quite a bit (to ~4MPH) and it was a lot of fun to watch. Unfortunately, it was dark by the time I was really running so those videos are not so good.
I tried running it again the next morning and one of the steering cylinders spewed hydraulic fluid. I should have the seals for it today. In tearing apart the steering, I noticed that my steer angle sensor had worked loose. I’m working on a better way to secure it.
The only complaint I have with my GPS-only solution is that it oscillates instead of locking onto the AB line like I’m accustomed to seeing with my Deere equipment. I am sure that using the IMU would help immensely. I just don’t know how to implement it.
Yesterday Tractobot01 drilled on its own for hours. Here are some videos of it in action.
The biggest problem of the day was that I lost RTK several times. I finally got the error handling code right so that it would stop when that happened instead of just drifting off into the sunset. It was still a pain, though. I wasn’t logging data so I don’t know exactly why it happened. I suspect it was an NTRIP issue. I hope to set up my own base station soon.
I mentioned earlier I was working on a mower using the reach and navio2. Here is progress so far, figured someone would get a kick out of it.
Few things to note:
Safety is a big concern so I have the RC manual if AUTO goes crazy, and on board kill switch, and an out of band/independent remote kill switch that cuts all power to entire mower (as in kills motor too).
I’m still working on getting the RTK all ironed out. I got new antennas and quite happy with how they are working, even with the storms coming in. On a sunny day I think I’ll have solid RTK, especially not in a subdivision.
There is a small chance the linear actuators is causing a quick voltage drop that is affecting the active antenna. So still investigating that.
As from the videos the mower still weaves a little and for one reason or another refuses to cut that strip. In a few days taking to a large empty field so I can see how it performs on turns and long parallel cuts. I assume a lot of tweaking to stop that weaving, common with APM rover setups.
One thing I’m a bit worried is if that small tree is altering how the GPS is working, but slight enough not to trigger into float. Call me crazy is this over the top, but not for sure how foliage has an effect on RTK. On linux I’m trying to get a workflow so I can compare planed GPS coordinates against what the Reach is resolving. RTKPlot is awesome but super buggy with Wine on Linux.
Congratulations! You’re about to the point where it’s all a matter of software.
I’m also working on my differential drive project, Tractobot02. I hope to have something to show soon. I’ve reverted to using ROS, as I did with Tractobot00. My (mis)use of ROS resulted in several crashes for Tractobot00 (due to network latency, failures) so I’ll be adding more kill switches for the much larger (300HP) Tractobot02.
One advantage of ROS is being able to capture and plot detailed data more readily. Are you still happy with APM?
Yup I think you are spot on going in the software part.
APM is a love/hate relationship at the moment. There are a lot of things I like about it, APM Planner does a lot of the general graphing and mission planning, but horribly buggy on Linux. To the point that I generate the mission plans outside of APM Planner and only use APM planner to watch live, few graphs, and arming. It does have things like modes, EFK, all interfacing with hardware already done.
BUT I’m now getting to the part where I need certain things like better interfacing with additional sensors, do navigation decisions on the fly vs just sticking to a static plan, and more GPS waypoint than the 128 or w/e supported. The requirements of what I’m needing and what APM can offer are starting to differ.
So about ROS, are you liking it? And what all do you have implemented on it? Are you still interested in opensourcing?
I do like ROS. I have implemented very little on it, though. I just use it for message passing with Tractobot02. I used the joystick node for Tractobot00 but wrote my own joystick node this time. (It publishes data that’s easily digested by the Arduino that runs the steering and transmission.) I want to start integrating IMU, GPS, EKF, etc. and use ROS mapping tools.
APM’s poor handling of many waypoints was one of the reasons I wrote my own Python script for Tractobot01. Although I expect to get back to more waypoint-oriented operation eventually, it is wonderful to be able to code the implement raise/drop as a function of the position, speed, and latency of the implement, all referencing the headland line. And it’s handy to be able to say “Turn around and do the next pass 15’ offset from the last.”
I am definitely interested in supporting a F/OSS solution that moves APM components into ROS as Earle Robotics started to do. I don’t want servo control. I don’t want MAVLINK. I want a node that subscribes to on-course heading, cross-track distance, and IMU, does its fusion/EKF magic, then publishes steering commands. I’ll do the rest.
I expect that I will eventually have to learn about “fusion/EKF magic” so that I can write the code myself.
I’ll have a lot more to say once I get Tractobot02 on automatic guidance. It has vastly finer steering control than my first two projects. I’m excited to see what difference that makes with my dumb 10Hz GPS-only guidance system. If it performs well, I can delay diving into IMU code for a little longer. Also, I might try some basic fusion using my IMU Brick v2.0. It is constantly self-calibrating and returns easily-digested pose information at a high rate.
I can see that Emlid and Earle want people to buy their hardware in order to use APM. But I get the feeling that there are more than a couple of us who want to be able to cobble together our own systems and do things way beyond APM’s scope.
Yeah I’m getting to that point. Also I have a renewed interest in the IMU Brick. Getting good compass has been a real pain and having something that auto calibrates is sooo nice.
If your interested in I’d be happy to contributing to a rover targeted system. In a few weeks I hope to have all my GPS issues hashed out and start working on ROS as I’m already hitting waypoint limitations. There are a few things I still would like, servo control and MAVLINK. I think for remote monitoring its decent and has enough stuff that isn’t directly APM related. They even have a ROS module for it
Other than that I’ll need all the things like EKF and IMU, plus some extra processing to make sure I cover every inch of a lawn aka coverage.
Yesterday I added navigation to Tractobot02 (my MT765).
Today I tweaked the PID and was generally able to stay within a couple inches of my A-B line at 20 MPH.
These results were from my dumb Python scripts (now running under ROS) fed by the dual RTK receiver. 10 Hz. No IMU. No C code. I’ve got some ideas for improvement but at 6 MPH I’m easily accurate enough for planting corn.
I am now confident that I have no need for APM. ROS provides much better infrastructure for what I’m doing. Now I can move on to course planning and higher-level controls.
Dang that is driving very well. I guess the question now is if you are going to run with what you have no or go down the EFK/IMU integration. I’m glad to hear ROS is working so well, I wasn’t for sure if ROS would be low latency enough to do real time driving and corrections, especially at 20mph.
I’m reworking all the electronics for my setup, firing up ROS, and new 5Hz receiver coming in end of the week. So hope to have something to show off in the next week or so.
Also thinking, the last time I drove 20mph on a tractor I essentially broke the tractor in half, feeding 5x5 hay bales on front and back, hit a huge bump that got a little air time, and when the tractor came down things started breaking, motor moved fwd into radiator, bad things.
Yup, that’s pretty much how it was to drive 20 MPH for these tests. I tried to make videos of it several times but I’d drop the camera or drop the joystick (which would sometimes stop it and sometimes command hard turns). And the arm console is unscrewed so it was flapping around. I do not plan on 20 MPH field operations. But it amazed me how well the tractor/guidance performed at high speed.
From my reading, I thought I’d surely need an IMU, EKF, and C code to get decent results. But I can go three times my planting speed using my dumb approach. I don’t see any reason to make major changes.
Dual RTK is the key to my success. Without it, I would have to resort to using an IMU and lots of complicated code. Guidance products sold to farmers often differentiate themselves by offering the ability to run without RTK corrections for X minutes. I will be happy to be able to detect impending failure (loss of updates) and stop the tractor. (Contrast that to my John Deere tractor which gives a subtle little beep before wandering off across the field when it loses RTK.)
I would much rather work on ensuring that I maintain RTK than to deal with more complicated guidance. I get corrections from Indiana DOT right now but I plan to have my own RTK base or two at my farm. That should ensure that the tractor always has corrections available.
Also, I’m improving my antennas. I’m using these Tallysman antennas on ground planes rather than the little patch antennas I used for Tractobot01.
I’ve been neglecting the tractor. I just got back to work on it this weekend. Yesterday I installed a long-range RF remote (carymart.com) and two PWC pull-switches as kill switches. I’m much more comfortable with turning it loose now.
I need to start harvest next week. Today I’m working on adding throttle control. I just got it working on the Arduino and now need to add the cabling, etc.
My goal for this year is to be able to drive the tractor to the middle of the field where it can wait for me to dump into it, then drive back to the end where I can unload it. I’m likely to be waiting for trucks this year, so if I have some time I’ll try to improve it beyond that. I’ll be delighted, however, if it just does this minimal work reliably; I can always make it more complex.
Regarding PID…I used my own PID code at first. I’m fairly sure that I switched to the basic ROS PID node in my current code (which is not at hand). It took awhile for me to make that work. I recall that I needed to do some remapping but once I solved that it was straightforward.
I’ll try to collect my code soon and put it where you can see it. I’ve really been flying by the seat of my pants and it’s time to get serious with the code.
It was all hidden!
