I’m sure I’m making a bonehead mistake here somewhere, but I nes some help:
I have a skid-steer rover setup with and Emlid edge running rover 3.3.
I have it set up for manual driving well. Controls respond appropriately, arrow on the screen appears to point in the correct direction. But when I try to do waypoint mission (simple rectangle) the rover will start driving about 45 degrees off from the waypoint. It will slowly curve around from this angle until at some point it stops and skid steers toward the waypoint, but it will over correct and point 45ish degree off from the waypoint in the other direction. It proceeds in this manner until it hits the waypoint and then does the same to the next waypoint.
What have I done wrong?? Compass orientation issue? Skid steer setup problem? Emi?
From a quick look at the logs it looks like the turn-rate controller needs tuning. In particular the ATC_STR_RAT_FF should probably be at least 5x higher so maybe increase it to 1.0. Increasing ATC_STR_RAT_P/I and D a little might also be good although it’s not necessary… the FF is the most important.
I see that arming checks have been turned off (ARMING_CHECK = 0), this is normally not a good idea. It’s better to resolve any pre-arm failures if possible instead of disabling the checks. If it’s compass that’s causing problems, it’s probably OK to disable the internal compass (set COMPASS_USE2 = 0, COMPASS_USE3 = 0).
Thanks so much for taking a look. I had originally tried to start with tuning, but became convinced that the fact that it was starting out in the wrong direction was evidence there was a more fundamental problem. But increasing the FF as you suggested did in fact address the problem.
I just went back out to my local test site and spent some more time with it. I started by calibrating the compass again, because id messed with a bunch of things since the last time I did so. I did not turn off the 2nd compass, though. I had seen you recommend that in other threads too and had done it previously until I realized that the Emlid Edge doesn’t (I think) have an internal compass but the external GNSS unit has two. It is really a pain to do the compass calibration with this machine compared to a copter.
I had previously turned off arming checks because in my first setup I couldn’t get it to arm for a variety of reasons. A big one was that I couldn’t get it to arm in my basement where I was setting it up, but needed to be able to drive it to get it back outside because its so big, heavy, and awkward. But at your suggestion I turned arming check back on and WAS able to get it to arm without problem at the field.
I started by changing FF to 1 as you suggested. And the improvement was significant. I let it run its mission slowly around the field and saw that it was still weaving a bit so slowly increased the FF a little at a time which seemed to keep helping. I stopped at 1.45 I think. I will have to go back out and spend another session out there tuning it more, but now I am on the right track.
Great news that it’s working better and nicely done on the tuning. As you’ve found, the ATC_STR_RAT_FF is the most important value (for steering) by far. With the FF as high as 1.45 it’s probably a good idea to raise the ATC_STR_RAT_P and _I as well … I’m pretty sure you could make them 3x higher (i.e 0.6) without any problem. You might find that it doesn’t really make much difference which is good actually.
Cool, I will try it. I wanted to mess with changing the P and I as well, but wasn’t sure if I had adjusted FF sufficiently.
I also wondered how much speed affects the tuning? It is intentionally geared quite low because the sensor it is intended to carry has a maximum speed. So the rover is geared for a top speed of around 2m/s and the mission I was running was, I think, set at 1.5m/s.
Although I fly fixed wings and quads regularly, It was pretty neat to see this large rover quietly running slow straight lines with crisp skid steer turns (when it didnt lose traction and need to be bumped in manual mode in the wet and muddy grass).
The tuning shouldn’t need to be adjusted depending upon speed especially for skid steering rovers like this. For the Ackermann steering vehicles the response depends upon the speed of the vehicle (i.e. a fast moving car will respond very quickly to a small change in the steering angle)… but for skid-steering vehicles the response doesn’t change… so it should be fine.
I want to throw in a “Thanks” to you both for this discussion. I have gone through some of the same issues and don’t really have my mower fully fine tuned, although it is usable. I learned a lot here. For instance, I have had the same question about mission speed’s affect on the tuning.
I had a weird problem today and yesterday when I booted up my rover. Ive been driving it around in manual mode for a while now, and had gotten very used to how it drives. But yesterday and today, once I armed it in manual mode, it was driving really sluggish. Slower top speed (which is already very slow) and it wouldn’t pivot turn. It would try, but didnt seem to be putting the normal amount of power into pivoting. I was going to pack it in, and figured maybe there was a problem with the battery, but when I switched it to auto mode, it went back to normal and was pivoting with the normal amount of Oomph, and driving at the correct speed. What parameter must I have changed to have done this??? Would this be a result of modifying the FF and related parameters? That doesn’t seem right,but I thought that all I altered, before it did this, was the FF, but I must have done something else. Did changing parameters in the “mission start” options in Qgroundcontrol (which I did in my tests yesterday) affect basic manual control?
Ive been trying to run a few grid patterns to see how closely the rover will navigate using the RTK data from the Reach RS onboard. I want this to be running, constantly, with as little cross track error as possible and to minimize cross track error as quickly as possible. Would you take a look at another log and possibly suggest additional tuning directions? When the rover hits the waypoint and pivot turns successfully, it does a pretty good job tracking straight on the line to the next waypoint. But, on the grass field Im driving on, the rover doesn’t always successfully pivot turn, sometimes it starts to pivot turn and then loses traction ad the wheels spin. So I drop into manual and bump it forward or backward and then switch back to auto. When that happens, it is usually starting the next line from a meter or two further away from the starting point than it should, and then it seems to be much slower to come back to the line and weaves more. I raised the P and I terms as you suggested, and bumped the FF just a touch higher. I was also looking at the Nav tuning values, and wondered whether these are coming into play now.
Any help you can give would be, once again, really appreciated! I think this log is somewhat truncated, though. So not sure if it is sufficient. Thanks!
Hmmm, as usual, given enough time, I can figure out where I went wrong.
Of course, as I thought, it wouldnt make sense for the turning rate changes to affect manual mode, since the documentation says this (my emphasis added) about the steering rate PID parameters:
“The Steering Rate controller attempts to achieve the desired turn rate (set by the pilot or autopilot) using a PID controller. All modes except Hold and Manual use this controller.”
So, I did figure out that somehow the calibration on my transmitter was no longer correct in the RC input screen, I don’t know why though. Top speed and pivot speed were down in manual mode because the rover thought I was only giving 30%-40% commands. When I ran RC calibration again the rover immediately became responsive in manual mode and is pivoting as it should. Great. So now I can go back to testing navigation.
I spent some more time trying to tune steering and navigation. Its still getting better, but Im wondering if someone can help me tune it further.
What I want to be doing is running survey grid missions with .5 or 1m spacing. I have the rover setup to use RTK data from a full size Reach RS, and that seems to be working well.
My first problem is that I tend to frequently lose traction in pivot turns and I have to drop it into manual mode and bump it a little forward or backward and then switch back to auto mode. Im trying this in a pretty nicely mowed field, so don’t know how much of a problem this will be in more rugged terrain. But it gets pretty annoying to drop into manual mode at the end of almost every transect. It don’t know if there is some way to improve pivot turns, or this is just going to remain a problem. I tried turning off pivot turns, but it makes such a wide arc to come around that it made everything worse.
Because I noticed that it tended to have extra problems at the start of the next transect if it got too far away as I bumped it forward or back to find good pivoting traction, I tried using “overshoot” a little in the grid generation. If I run 5m or so past the end of the polygon, once it turns around, it has a little time to get lined up for the next transect. This has it working pretty well, but Id like to get it even more dialed in. It still has a pretty slow oscillation, especially as it starts each line.
Your rover has a long wheelbase for a skid steering vehicle. So the wheels have to travel a long way in pivot turns and it requires a greater force to push them sideways. Fullsize skidsteer vehicles with wheels like compact loaders or the sherpa have the wheelbase as short as possible for that reason.
To get more traction you could try to interchange the two rear wheels so the tyre profile points in the other direction to give it more grip when reversing. You could try to lower the tyre pressure too, but that also increases the friction during pivot turns, so it my backfire.
Thanks for posting this. I hadn’t considered the degree to which the frame length was contributing to this, but that makes sense. Unfortunately, the frame length was defined by the payload size that it will carry. But thats an interesting idea to change the direction of the rear wheel. And it would be pretty easy to try lowering the pressure in the tires. I will give these a try.
Thanks for your suggestion. Some combination of reversing the rear wheels, lowering tire pressure, and different soil conditions meant a much better result in my tests today. My rover was running auto missions with only the occasional stop where it lost traction and needed to be nudged in manual mode. Thanks!
Today I finally got out for another tuning session. I was trying to test a bunch of things, including the new ground control station that I finished 3d printing and building, which worked great:
Ive made good progress getting my rover tuned, but it still wanders a bit along transects. The following screenshot is from a few subsequent passes around a simple box pattern:
It seems to tend to start just a little in the wrong direction and then weaves slowly as it travels along the line. Id love to get this just a little more locked in. But I am unsure what to do next. Does this need just a little better tweaking of parameters, and if so what should I be looking at now, or could poor mag data be driving this?
This is a big log from my testing today, which has a bunch of passes around this box in autonomous mode, some manual driving, and then part of a Survey (grid) mission.
It’s unlikely to help but it looks like the vehicle can’t turn very quickly so perhaps reduce the maximum rotation rate to 40deg/sec by setting ATC_STR_RAT_MAX = 40.
I am hoping to get some help from Leonard Hall over the next couple of months to work on the navigation controls.
Thanks for taking a look and responding. That is a bummer not to be able to tune it better at the moment. It is so close to functioning well.
The rover is carrying a Ground Penetrating Radar, and the point is for it to do survey grids to collect accurate and regular GPR data (using an emlid Reach). The Emlid Reach units are passing RTK data to the Edge controller AND to the GPR, so to SOME extent, it is OK that it is not perfectly straight since the GPR data is also accurate and some degree of error can be interpolated.
This past weekend we took it out to a local site that we use to test our geophysical instruments. We were able to run a nice autonomous mission, and get mostly useable data, but it was frustrating that the rover still wove noticeably along each transect rather than driving straight to the next waypoint. This resulted in at least 1 hole in the data that can’t be easily closed.
Here is a screen shot showing how the GPR data points plot out on a mission with .5m transect spacing:
I will try changing the rotation rate, as you suggested. But you think my problem is now with the navigation tuning? I had tried raising the Nav_L1 period, but it didn’t seem to change much, so then wasnt sure if I was still having more fundamental problems with steering. Or if I should, perhaps, try turning off NAVL1_XTRACK_I: L1 which the description also says can cause cross track error oscillation.
Thanks again for taking the time to have a look and respond! I really appreciate it.
Im a bit less concerned about error at the start of a transect as I am about errors along the transect. The former can dealt with by just adding some overshoot and lead in (all of which will still generate some data), but the latter will keep creating holes in the area to be surveyed.
Im hoping to go out for another test session tomorrow (if it doesn’t snow too much today!) so will try the cross track parameter change and messing with the NAVL1_Damping and Period some more.
I have also designed and 3d printed a new mount for the Emlid Edge GNSS that contains the dual mags. It will move the mags a few more cm (7) away from the metal frame (and give it, I hope, a slightly cleaner install). Since I remain paranoid that the mag is still causing problems.
