I am contacting you today with a project I have been working on for the last 3 years.
It is an autonomous seeder which I want to use on my farm to cultivate the fields with solar energy.
Here are a few technical data:
Motor: 2x 400W BLDC motor with 60 to 1 gearbox
Controller: 2x Odrive Pro
Battery: 48V 5kWh solar storage
Solar power: 1,5kw
Maximum speed: 0.2 meters per second
Weight: 1.3 tons
Approx. dimensions: 2x3x2 meters
As you can see in the following video, I have already been able to tune the rover very well so that it can follow the rows very precisely, that was with Rover 3.3:
A lot has happened since then and there have also been longer pauses. I have now installed Rover 4.4 and can’t get any further with the tuning.
The new S curves have changed a few things and it no longer seems to be compatible with my tuning from 3.3
I have tried the Quick Tuning function, but unfortunately the system always seems to hang at the same point in an endless loop:
The quick tune doesn’t seem to be made for such large and slow machines, any ideas on what I could change to make it run through all the quick tune processes?
Would you say it is better to tune manually here, if so which values should I change first in relation to my parameter file?
Even if I follow the normal manual tuning process, I can no longer get to the point where the rover can follow a line very precisely. I can control the rover very well and precisely in manual mode.
So now I need help from the community, does anyone have an idea what I am doing wrong? Enclosed you will find my parameters
The circle radius needs to be smaller for QuikTune to work. Try decreasing CIRC_RADIUS. You may find that you can’t achieve a steering rate tight enough with that big, presumably slow vehicle, but it’s worth a try.
Thanks for your reply, I have managed to successfully complete the quick tune with a smaller radius, but the rover no longer manages to drive in circles after the tuning, it constantly changes from left to right and drives in serpentine lines, before the tuning it was better.
Would it be helpful if I posted a log here? The rover is also accessible via UDP if someone wants to connect and watch the whole thing live, it is on the field and can be driven
Hi @Jens_Weber1
Pay attention to the open AOG project. Two years ago, I also wanted to do something similar based on Ardupilot. But Ardupilot is only good for toys, not for work. Well, or you really have a lot of time
After trying to set up the autopilot and activate the attachments, I came to the conclusion that the Ardupilot is just a toy, for RC toys it is of course perfectly suitable. There is absolutely no need for agro navigation.
Now I have several Kubota mini tractors working on the basis of AOG. Remote Network Access (UDP) is used.Full autonomy has been achieved, the most important plus is the simplicity of settings (there are no dozens of parameters like in Ardupilot). It can be used as one large board or several modules connected over a UDP(network) or USB. A minimum of components are also used, which are cheap and simple. for example, setting up RTK simply boils down to connecting a PC and selecting a function (rover, move base, etc.). There is no need to go through the settings in U-blox and the like.
There is ISOBUS support, RTK, hydraulic control and other specific agro functions. All information and management takes place from a Windows-based PC.
I also have an autopilot project based on Raspberry 4 in Russia, while it is being tested, but it has shown itself well. The video is just a simulation, there is an Android app, it is compatible with AOG. Transmission of information over UDP.
I have been able to greatly improve the tuning through further testing, but for my application it is necessary for the rover to be able to drive with an accuracy of 2 cm. I have already confirmed that it is possible with the video of Rover 3.3, but I don’t know if it is possible again with 4.4
For my application it is necessary that the rover can drive with an accuracy of 2cm. I have already achieved this with an older version of Ardupilot, but it is actually difficult to set all the parameters correctly
The AgOpen project looks to me as if it was developed for tractors, but for the rover I am looking for a system that is intended for autonomous rover vehicles, but I have to confirm that I feel that the steering systems for tractors are more precise than ArduRover. Therefore I ask myself the question up to which precision ArduRover can work at all with the right tuning?
Kind of wrong state about what ardupilot is and what AOG is .
Would be really cool to make ardupilot working with AOG as typically, our hardware is way more trustable that what is on AOG and ArduPilot would have a simple frontend to do agro stuff.
An no, ardupilot isn’t only for toys, but we clearly lack specialized interface for non flying stuff.
First, to say that AP is relegated to toys is a bold, uninformed statement. I know several folks who rather quickly converted ag equipment to ArduRover and are regularly mowing/spraying 10+ acres. AgOpen is an admirable project, and if that suits you, so be it. A confluence of AgOpen and ArduPilot, as @khancyr suggests would be quite interesting, for sure!
Speed/throttle looks well enough tuned. You can probably just leave that alone.
The parameters you’ve achieved by the end of log 17 are pretty good but still show some small magnitude overshoots that exceed your desired performance threshold.
I think these overshoots are likely caused by a bit of an aggressive steering tune, and I would first focus on refining ATC_STR_RAT_FF and then ATC_STR_RAT_P (in particular, reducing ATC_STR_RAT_FF to reduce the overshoots you can see in green on the plot below). The data from log 17 below is quite noisy, but it averages out to an overshooting tendency.
I’m curious if @rmackay9 would have a look and offer some further insight. He’s usually excellent at picking details that I sometimes miss. He may also be interested in the lack of suitability you found with QuikTune.
Also, your observations regarding the old firmware vs new are interesting, and something I experienced, myself.
The NAVL1 controller used in previous versions could be easier to tune at times, and I achieved outstanding results with it. However, my best results were actually a “poor tune,” where (like your steering tune), my steering tune was overly aggressive, and then I essentially made the NAVL1 controller fight with the steering controller to result in a low overall crosstrack error in AUTO mode, if that makes sense.
The poorness of the tune became evident in ACRO mode, where steering could be very twitchy. I almost never use ACRO mode, so my conveniently offsetting mistakes weren’t apparent until I began alpha/beta testing the newer controller/firmware and started recognizing the shortfalls I had created.
The newer position controller SHOULD be capable of better results, but, as you’re finding, it can be a little tricky, especially with non-linear and/or sluggish responses.
The point about “non-linear” is interesting and it’s something that I’ve thought about as well. I had thought that we could perhaps create a Lua script that checks 10% increments of the steering output and then measures the resulting turn rate to at least gather data before we add some kind of scaling parameter to compensate.
… anyway, this part of the discussion probably belongs somewhere in the 4.5 category but just wanted to post a note.
The accuracy of AOG is exactly as good as in Ardupilot (it all depends on the accuracy of GNSS receivers). I think you are using ublox F9P, which is also supported by AOG. AOG uses a “simple” and accurate method based on the wheel angle sensor, there is also an IMU (used to account for/compensate for tilt) that is not used if you have two GNSS receivers, or one (UM982) with two antennas. To be honest, I don’t see much difference between a rover and a tractor. AOG can be used with Ardupilot if desired, there are no big difficulties, I did it but I did not see much benefit.
This doesn’t exist on a skid steered vehicle like the one pictured in the opening post. I don’t see an option in the AOG ecosystem to control a skid steered vehicle. Unless there is one, your points here are fairly moot.
AOG is simple, it runs on the same “Chinese” hardware as the AP. The only difference is that the equipment for the AP is made by those who paid for the “certification". I have a Holybro H-RTK F9P that costs about $ 400 and a Chinese ubolox f9p board that costs $ 110 and an antenna about $50. The accuracy of both is absolutely identical, both sets have been working for more than a year without problems.
Of course, AP is out of competition for gliders and quadrocopters. Although INAV is much more convenient to set up, it is an excellent setup application.
I have built many excellent projects of boats for bathymetry based on AP, there are no competitors from AP. This is my personal opinion based on my personal experience.
Such steering is needed in construction machinery, but not agro.
In the picture I see the usual control using a linear actuator, the wheel itself rotates accordingly. And this type of reversal is not particularly necessary, after passing one “line” you move on to the next, or even skip one line.
IMHO
I understand agricultural steering strategies. But this is a skid steered vehicle with ThrottleLeft and ThrottleRight outputs. It makes pivot turns at the end of the rows.
You are not moving the conversation forward productively at this point.
