Tractor installation advice welcome

Navio / Edge Project share
1

I bought a Navio+ awhile ago (before the Navio2) and now i want to put it to use on my current tractor project. I’ve been wading through the documentation and forums. I suspect that there’s a lot that I’m going to have to learn the hard way but I’ll welcome pointers that will speed me along.

My first (23HP) tractor controller was initially an Arduino with local analog joystick, and then a BeagleBone running ROS. I used SwiftNav Piksi RTK GPS for positioning and my own (really bad) code to attempt to control it without an IMU. (I tried using a RAZOR but didn’t isolate it from vibration sufficiently.)

For this (140HP) tractor, I decided to use hardware I can easily run from my laptop for testing. I’m using a LabJack (U3-HV) to control the hydraulic steering and electric clutch. This has been great for quickly trying new algorithms to make steering control more precise. For testing, I’m using a Tinkerforge IMU Brick 2.0 as a compass. I’m running ROS with my own (bad) code again, but it’s been a lot of fun to be able to input a direction and have it turn and track. (The continuously self-calibrated compass output of the IMU Brick 2.0 is incredibly solid. It’s amazing to watch after using the RAZOR.)

The H-bridge I was using for my clutch could not handle the high current. I just received a new one that should handle it easily, and I have a three-day weekend to work on this project. I want to make some major progress but I’d also like to get started with the Navio+, which still intimidates me.

I have a couple of NVS-08C dual RTK GPS receivers. I have not played with them much at all yet. I also have an account with Indiana DOT to receive RTCM.

So…here are the issues I hope to tackle this weekend:

  1. I don’t want or need servo output. Speed control is simply engaging/disengaging the clutch. (Throttle comes later.) Steering is non-trivial control of the (open-center) hydraulic valve with feedback from a position sensor.

Can I simply ignore the servo outputs and push their values somewhere else? Publishing them to ROS would be easy. Then I could run the clutch and steering nodes on the Navio+ to communicate with the LabJack. It looks like the CCtronics firmware might provide all that I need.

Is there another way to get the speed/steer data without changing the Navio+ code? I suspect I could constantly getPWM() to see what the PCA9685 is doing but that seems horribly inefficient.

If I can’t do this, I might ditch the Labjack and put the control code in an Arduino, controlled by the servo outputs. It’s a reasonable solution but I’d much rather have all my code in the Pi.

  1. Do I have to have a radio control? I do have a FlySky FS-GT2B but it does not appear to have PPM output. It looks like SBUS is the way to go if I buy a new radio but I’d have to toss out my Navio+ and get a Navio2 to handle that. I’d rather just avoid R/C altogether.

  2. Must I use telemetry? I do have a couple of 3DR radios (for the Piksis) but I want to run everything off IP. (And I need miles of range.) It looks like APM can run over UDP (“TCP or UDP can be used instead of serial ports”) so I’m hoping this is straightforward.

Eventually I’ll want to add a bunch more controls: engine start/stop, PTO, hydraulics, etc. And there will be cameras. I’m inclined to run everything through ROS

  1. I have the Navio+ mounted to a Pi 2 but I also have a Pi 3. I got the rainbow screen trying to use the current Emlid image on the Pi 3. Then I found the requests for Pi 3 support in the forum. I trust that it will come soon. I’m tempted to try updating the current image to make it work. I’d like to have the extra power for the other stuff I want to run on the Pi.

  2. Can I easily push data from my own RTK GPS? I want to eventually get a bunch of the REACH receivers but I’d like to use what I have right now. The built-in GPS should be sufficient for my current needs but next year I need centimeter accuracy.

  3. What’s the best overall design for communication? Do I really need to use MAVLink at all (over the air) or should I use ROS for everything (with a MAVLink bridge on the Pi)? I’ll have a lot of other controls (engine start/stop, throttle, transmission, PTO, hydraulics, …). I’d like to handle them consistently. Could MAVLink do it all?

My goals for this weekend:
A. Install my new clutch controller. (I just want to be sure that all of the hardware is working properly.)

B. Fire up the Pi 2 and Navio+ using the Emlid image.

C. Get steering and speed control values somewhere I can use them. (ROS, ideally)

D. Control the Navio+ with MAVProxy over IP.

4 Likes
2

I’m in a similar position but with a tractor, using zero turn radio mowers. Currently I’m working with a reach and pixhawk but looking to ditch it as I’m more comfortable with a linux setup vs embedded. A lot of the same question you have I too have. So if you make any progress please post them!

Self Plug: http://mr337.com/blog/unmaned_robotic_mower-navigation/
https://twitter.com/mister_337/status/716429771979141121

3

Well, my weekend wasn’t quite as productive as I’d hoped. I did get the clutch controller installed. (The IBT-2 is a nice hefty H-bridge with lousy documentation.) I did an ultra-low-speed “unmanned” test with a compass-only square pattern.


(Deathly boring but it points out that I need to make a “kill rope” that’s less enticing to the dogs.)

Next I tried firing up the Navio+ in the tractor without connecting it to anything. GPS worked well enough but the compass sucked. It seemed to work well if I rotated it by hand, but when I left it as the tractor turned, the compass wouldn’t change much at all.

I decided to switch my effort to getting my NVS NV08C-RTK-A receivers working. I was able to get RTCM into them from a (free!) NTRIP server, and get RTCM out of them. They also provide GPS-based pose and an IMU, so I’m thinking I’ll just use them completely.

Since neither APM nor ROS support the NV08C, I’m leaning toward just writing my own software right now. I don’t need anything fancy - simple line following. Advice will be welcome.

–kyler

4

:clap: This is an achievement! My ZTR mower I still drive just for fun but my SO looked at it once and went back in the house.

You might need to check but a lot of setups (pixhawk/navio) have the option for an external compass. From what I have read it seems to be pretty common to use an external one away from the electronics which produce RF noise.

I’m also interested in the Tinkerforge IMU Brick 2.0. That and shipping to US is a bit high. Can you recommend an alternative?

5

Cool! An external compass should really help. I think that we should be able to determine heading in moving baseline mode on Reach. Will have a look into it. Really exciting application!

6

Holy smokes! This is awesome. I’m actually looking to start a farm project in Africa with automation in the next 2 ish years, I’ll follow your projects closesly

7

[I wrote the first part of this last week. I realize that this is drifting away from the Navio+. Please tell me if I should take the discussion elsewhere.]

I have played with the RAZOR, Navio+, and IMU Brick 2.0. The constant calibration of the IMU Brick 2.0 is amazing. The others didn’t work well at all in my situation but the Brick is solid.

The NVS NV08C-RTK-A gives heading within 0.5 degrees and there’s supposed to be a way to increase the refresh rate (from 10) to 20Hz using the built-in IMU. I upgraded the firmware on it (a couple revisions) and it’s working well. I’m feeling more and more comfortable with using it as my only sensor.

I bought a couple of Red Bricks which can run Python. I’m leaning toward writing a monolithic autopilot in Python that I can easily run anywhere. I don’t need superfast refresh rates, and a Python program would make experimentation so easy.

[time elapsed…]

This weekend I decided to work on my Python-only solution. I started by writing the code for getting data from my NVS-NV08C-RTK-A to my Pi3. So far, I have only used compass navigation. Now that I have the heading from the dual RTK, I don’t expect to use a compass at all.

The last piece of the (initial) puzzle is using this data to navigate. I’ve been thinking about how an autopilot should work for months and I finally found an article that has the details I needed. (https://uni-obuda.hu/journal/Stojcsics_56.pdf) It fits with what I’ve been imagining so I implemented (a variation of) it. I tested it a little by driving my truck back and forth across the line I defined. Simple summary: when far from the the line, drive perpendicular toward it. As you get closer, decrease the angle. It’s stateless - no PID involved. I am confident that I will soon learn that doing it well requires a lot more complexity, but this will get me started.

When I get some time, I’ll integrate my code for steering and clutch control. Then I get to roll the tractor again and see how it works.

Some thoughts…

  1. I really like the dual RTK (moving baseline) of the NVS-NV08C-RTK-A. I always get my heading within a half degree. But the IMU Brick V2.0 also gives a fairly robust heading so I’m willing to believe I don’t need dual receivers. Any chance of a dual REACH?

  2. APM overwhelms me. It does so much that I don’t want/can’t use (like servo control). I wish that there was a simple Python MAVLink client that I could work from. I expect that I’ll need to write it.

  3. APM limits me. I’m already thinking about how to incorporate multiple receivers. I’ll need to, for example, navigate so that the implement trailing 20’ behind me tracks perfectly. (I expect to put a GPS receiver or two on each implement.) That’s not something I’d expect APM to support.

  4. I like the visualization I get in APMPlanner2. For defining simple paths, it’s great. (I’m just using it to make a waypoints file.) Eventually, however, I will need to do much more complicated things than it (directly) supports. I expect that I will need to write something farm-specific.

  5. I know that I really should use Robot Operating System (ROS) for everything (and before this weekend, I had) but I’m enjoying having everything in Python right now. Long ago I was involved with Pyro Robotics. I wonder if a simple Python framework for a rover would help get more people started on projects.

8

Big success today. I’ll be happy to answer questions.

3 Likes
9

Kyler

You have done a very good job getting your tractor to be guided so well, in so little time.

The GPS you’re using is not RTK so considering the accuracy of the GPS receiver your getting very good results.

Now it’s time to use a Reach with a CORS system if you have one in your area.

You can get a nice parallel GPS mission planning with Mission Planner by creating photo mission for a field.

I’ll send you a private message on how to get the mission.

Larry

10

Thank you, Larry. I’ve been thinking about whether or not to use Mission Planner for grid computation. It certainly would be helpful to be able to visualize it. I plan to mount another GPS on my ATV and drive the perimeter of each field soon. That will give me much better precision for planning, especially for the location of poles and fences. (I’ll want to plant within a few inches of such obstacles.)

My plan was to work directly from the mission.txt file and essentially ignore the short end paths connecting the rows of the grid. (The tractor pretty much needs to turn full stop on the ends and head for the next line.) Am I likely to run into accuracy limits? I realize that an inch here and there don’t matter so much for an aerial survey but those inches are important to me.

Also note that I’m using dual RTK receivers fed with RTCM from Indiana DOT. I used Piksis for my first (little) tractor but it makes a world of difference to be able to get GPS heading information. The receiver also has an IMU and is supposed to be able to use it to double the data rate to 20Hz but that feature is not yet available. At slow speeds (~4 MPH) I can keep cross track distance below a couple inches. At high speed (~8 MPH) it can start oscillating. I spent quite awhile last night trying to tune the navigation PID to avoid it, but I suspect that the 10Hz updates are limiting me.

If REACH gets built-in fusion so that I can get both position and heading information with the precision I now get from GPS alone but at faster rates, I’ll jump on it. (A reach costs about half of what I’d pay for a dual RTK.)

Or maybe there will be a dual receiver REACH someday…

11

KyIer

I should not read forums when its past my bedtime. I now realize that you’re using two RTKs like the old AG Leader ParaDyme dual antenna roof mounted system.

I’ve been looking into the new GNSS Galileo satellites and I see the they make a big difference for GNSS in the near future for people all over the world.

Keep up the good work.

Larry

12

Great work.
How exactly are you controlling the steering and acceleration?

13

Steering is controlled by a hydraulic valve and monitored by a hall-effect rotary position sensor. (It’s a GM ride height sensor - much more robust and much less expensive than the linear potentiometer I used for my first project.)

Acceleration is only controlled by the clutch for now. It uses a linear actuator with feedback and limit switches. (I ignore the feedback now.) Either the linear actuator or the pedal can activate the clutch. That helps a lot when things go wrong.

Eventually I want to control the transmission and throttle. My next project, however, is to raise/lower a trailing implement. Then I can use it to disk and drill.

14

Very cool project!!!

I’m working on something very similar for use with a snow grooming machine. I started with a Reach feeding an Arduino Due and the Due ran the ECEF conversion and nav code. It was cheap and easy but creating a nice GUI proved a total pain. Right now I’m in the early stages of moving the nav code directly onto the Edison that is on the Reach. The GUi will interface with the Reach and the Reach will command the micro controller to drive the machine. For implement (Blade) control I’m having the nav code look forward on the path based on travel speed. The blade functions on a snowcat are not very fast so this way it knows where the blade should be when it actually gets there. The snow has melted here so I’m back to trials on a simple tracked rover in the local park but I may be back in a cat working on Mt Hood later this summer.

15

Tractobot01 is becoming useful.


By next weekend, I should have implement control added so I don’t have to sit in the cab.

Eric, I am very interested in your code. I was just about to sit down with a couple GPS logs and try to add some look-ahead code. I’m using nvector (Python) for my geographic calculations. My plan is to use the course over ground and speed over ground to extrapolate a position. I’ll test it against my logs to see if it’s reasonable.

I also have steer angle data logged so the next step would be to develop a kinematic model to predict future positions. I suspect that a Kalman filter is in my future.

Is the heading that you get from REACH robust? I have been appreciating the stable and accurate heading I get from dual GPS. I’m hesitant to think about reverting to a single GPS.

16

I’m just getting started with python so thanks for the tip about nvector…looks like I have some reading to do.

Basically what I’m doing is using RTK to aid in building ski/snowboard freestyle venues like what you see in the Xgames. I’ve been doing this for going on 20yrs. Not much has changed in that time with only a tiny few guys using rtk. Currently its all by eye or feel other than a few grade markers placed by rtk in the early build stages. For the most part lots of tape measures, bubble/laser levels and a boat of experience for those you have been it as long.

So far everything I have done is in arduino. For my application I’ve converted everything to earth centered xyz coords. My code is a work in progress aka…a mess so when I get it cleaned up I’ll share it.

By using ECEF I can draw shapes for the jumps and various snow slopes in an xyz system in the gui rather easily and then track the implement against those desired shapes and grades. It’s really simple plane and vector line math in the gui to show how far off the implement is to where it needs to be when pushing up these features . Sometimes they contain over a million cubic ft of snow and take 400+ machine hours so it’s worth it to get it right the first time. For example a super pipe is 600ft long, is two parallel walls snow 25ft wide, 25ft tall, each following an 18deg grade 65ft apart and they have to match to within 3in to be safe and function properly.

Here are some pics of my snow farming! more plus some videos @ instagram.com/helinerd

canvas.png792×792 880 KB

pipe1.png1026×1536 1.35 MB

pipe3.png792×792 686 KB

park.png792×792 577 KB

2 Likes
17

Thanks for the details, Eric! It’s good to see that someone else is working on an application that’s definitely not going to be handled by APM.

Have you considered using a Pi as your controller? I like the thought of using the Edison on the REACH but a Pi is so handy, especially if you want a GUI.

Other ag. systems use latitude and longitude and that’s what my GPS emits so I’ve been trying to stick with that for most of my calculations. I get anxious about doing a lot of conversions because I don’t know enough to realize when I’ve introduced significant error. So far, I’ve been able to do almost all of my calculations in nvector and I trust it more than my own code.

I suspect there are more people like us who would like a modular system that we can easily integrate into our projects. I’m especially interested in a Python-based solution; I work on this project on the weekends and a lot of my coding is in the tractor cab. Python makes it easy for me to whip up a new feature and try it. Yesterday, for example, I coded some very basic A-B line navigation and by the end of the day (and the end of disking my pasture), it was working remarkably well. I was modifying it as I went.

I would be willing to put some money toward a common code base that would be useful for projects that don’t fit typical “drone” missions.

Also, let me know if you want to discuss hydraulic controls. I have some formal hydraulics education from decades ago, but I have learned a lot on my projects so far.

18

I’m now getting to the point of the mower where the hardware/mower interfacing is stable. I’m now beginning to to evaluate APM and the more I look the more I think I’m in the same boat.

I too would be interested in a common code base, is this something you are planning on doing yourself @kylerlaird or hiring it out?

19

Also doing some more thinking, I’m not too for sure if a Python codebase would be ideal. I’ve worked on a few other projects that originally started out Python but needed to meet strict timing requirements and ended up going c or c++ in the end. One that sicks in mind is RTS2, RTS1 was in python :D.

Also another thing to consider is http://www.ros.org/. Haven’t gave it a shake yet but been on my list if APM didn’t work out.

20

I originally used ROS but it was just for message passing and joystick interface. While I like the idea of using ROS, it was mostly getting in my way.

I’m going to use Python until there’s an obvious reason why it’s not sufficient. At some point I’d like to have IMU-handling code in C, but I doubt there will be any reason to migrate other code. It would be wonderful if IMU/GPS fusion would be done in REACH.

Tractobot01 has been in the shop. I decided it was time to fix the transmission before it got worse. I’ve been planting with my JD 8285R. I’ve been even more aware of its automation this year. It’s remarkable how well it tracks a line, even at high speeds (15+ MPH). I want that.

I would gladly pay for high-quality motion control code that would give me similar capabilities. I contacted several companies and individuals to do that before I decided to see what I could do first. I’m glad I did it myself but I know I need help moving to the next level.

Before I took Tractobot01 to the shop, I tried navigating based on some very simple (and dumb) forecasting of its position. It had promise. I’m sure APM does something like this very well. I wish I could pluck such pieces of APM out and use them in ROS/ROS2.

Earle Robotics has done some work on exactly that. I just now messaged ER to discuss filling in the gaps. That would allow me to handle high-level controls in Python and still get sufficiently realtime motion control.

BTW, I’ve also been working on coverage planning. I use APM Planner 2 to mark the perimeter of a field, save the waypoints, and then run a simple program to make a new set of (many) waypoints for all of the passes I need to cover that area. I think this might already be a feature in one of the other (MS-only?) planners but I’m eventually going to need to go well beyond this - calculating headlands, avoiding obstacles, etc.