I am trying to tune my rover, but I can not get consistent results. For example the rover drives in a straight line with little to no weaving, but if I let it drive the same way in the other direction, it weaves like crazy.
The rover has two driven wheels (225mm diameter) and a pivoting roller. Motors are 510kv sensored brushless running on 2s 4000-16000mAh with a 24:1 reduction gear. It behaves just fine in Acro and Steering mode. I disabled the two external compasses, using only the Pixhawks internal one, which finally resulted in no “bad compass health” or “inconsistent compass” messages. It looks like this:
I suspect the frame is magnetic so mounting the GPS/compass module right on the frame is probably the cause of the bad compass messages. Moving the GPS/compass module away from the metal by even just a few cm could make it a lot better
It is best not to set MAG_ENABLE to 0. Instead compasses should be enabled/disabled using the individual COMPASS_USE1,2,3 parameters. I think you figured this out but just wanted to make sure.
the most important Steering gain to get right is the feed-forward, ATC_STR_RAT_FF. Here is the steering tuning wiki page and it mentions, “tune the FF gain first”. This is really good advice. The other thing that really helps get tuning right is to display the desired and actual turn rate. How to do this is mentioned just a bit lower on the page.
The difference in steering performance when going backwards vs forwards is interesting. The issue really is that the frame responds much differently in forward vs reverse. It’s possible we could add a new parameter to allow setting a different turn rate gain when reversing… that would be an enhancement though so for the moment, the best that could be done is to tune it so that it works adequately in both directions which probably means tuning it in reverse which likely responds faster. Perhaps then setting a higher ATC_STR_RAT_I might help when going forward.
I tuned the rover in Acro and Steering mode as described in the wiki. As I wrote above it is driving well in both modes.
The problem are Guided and Auto mode.
I tested in Guided mode yesterday and the problem was not going forwards or backwards, but driving along the same path in different directions (turning around 180°). One direction NNE always works
better than SSW. NNE is slightly uphill.
I disabled all compasses during my testing through parameters, but I unplugged the external ones at last, just using the internal one. I noticed that sometimes the “Enable Compasses” selection in Missionplanner did not stay enabled after reboot. But I am pretty sure the internal compass was enabled after all.
The frame is made out of aluminium and I used aluminium groundplanes before for the GPS antennas. The rover has a top speed of 2m/s and a high maximum turn rate, one wheel going 2m/s forwards and the other 2m/s backwards.
What really helped was setting the Steering filter from 10Hz to 50Hz.
I previously raised L1 period to 16 and then I got the rover to follow a straight line almost every time in one direction.
it seems I am completly unable to get the steering of my rover tuned right.
I started again from scratch with ardurover 3.4-rc1. I noticed today that with the values I entered the rover is unable to correct for any disturbances. I had ATC_STR_RAT_FF at 0.4 and ATC_STR_RAT_P at 0.08. Even with those low values, pidachived was always much higher than piddesired. I then tried to raise ATC_STR_RAT_P gradually and while driving forwards it worked much better, but going from forwards to stop, caused the rover to do a little left/right wiggle. Going higher with ATC_STR_RAT_P (0.5) improved the forward driving further, but stopping caused the steering to go completly out of control. I now have ATC_STR_RAT_FF at 0.05 and ATC_STR_RAT_P at 0.2 and with those values pidachived follows piddesired for the first time, but ATC_STR_RAT_P is still too low, to counteract small inclines or other disturbances, causing the rover to go left and right in ACRO mode, instead of a straight line. I also tried to add a little ATC_STR_RAT_I, but this is unusable, because the I-term is always running, causing the rover to turn by itself.
I think one problem is, that the my rover has very little resistance against turning, while being quite heavy at 9kg.
Do you have any tips, what I could try to make the rover drive in a straight line without going crazy during stopping?
One thing that just came to my mind is to replace the rear pivot wheel with two polyurethan scooter wheels to give the rover more turning resistance.
Txs for providing the logs. In general it’s doing a decent job of achieving the desired turn rate. We can see from the STER message that the vehicle’s actual turn rate (shown in green) is following the desired turn rate (shown in red) pretty well.
From the graph though we can also see these spikes in the actual turn rate and if we graph the STER.SteerOut and TurnRate we can see that it’s most likely the spikes (in turn rate) are caused by changes in the steering control output (and not caused by disturbances in the environment). In the graph below it may look like the vehicle is turning in the opposite direction from the steering output but actually it’s just that there is a small lag in the response. So the steering is jerking one direction and then back again and the vehicle’s turn rate does the same thing a very short time later.
If we graph the PIDS (steering PID) message we can see the contribution of the FeedForward, P, I and D to the steering output and it’s the P that’s causing these jerks. So the general advice is good in this case, I think FF should probably be increased and P decreased to be below FF. It would be good to increase I as well to help keep the vehicle moving in a straight line.
The throttle control looks pretty good but it might be good to increase the I (ATC_SPEED_I) to 0.2 to help a bit with headwinds and current. In the graph below we can see that the actual speed (green) is following the desired pretty well but it often doesn’t quite get to the desired… this long term error will be reduced if I is higher.
after weeks of sunshine it started to rain today, so I can only test indoors. I now found a steering FF factor of 0.065 (much lower than what I tried before) a P of 0.03 and an I factor of 0.01 let the pidachived follow piddesired quite well. I also noticed that the sensored ESCs I use were set to a deadzone of +/-20us (I guess to compensate for signal jitter of cheap TX/RX sets). That may explain some hard transitions from forward to reverse rotation of the wheels I observed. I now reduced it to +/-2us and change of direction, acceleration, braking is all much smoother now. I think the high deadzone setting made it hard for the pixhawk to control the rover, just like trying to drive straight with a car that has a lot of play in the steering.
I don’t think it’s mentioned on the wiki but the MOT_THR_MIN can be used to set a deadzone for the ESCs. It’s not a perfect solution because it applies to all throttle output. The way I set it is to do this:
connect to the vehicle from the mission planner (other GCSs may work as well)
go to the Flight Data screen’s “Quick” tab and click on one of the numbers and then select “ch3percent” from the window that pops up. in this way the ch3 (i.e. throttle output) percentage will be displayed in real time.
put the vehicle in MANUAL mode and raise the throttle until the wheels start to move.
note the ch3percent and put this into the MOT_THR_MIN value (or maybe reduce a few percentage points).
On the thunder tiger trunk used in my tuning video I actually had to set it quite high… about 25 because there’s apparently a massive deadzone. I’ll add this to the wiki eventually.
I finally got consistent results driving my rover. It seems I managed to build it in a way that was very hard or impossible to tune. The layout with two driven wheels and a free pivoting rear wheel had no directional stability at all. Driving along a small slope would always turn the rover uphill, because the rear wanted to roll downhill.
Small variations in motor rpm would cause a turn which would get tighter and tighter, because there was nothing to stop the rear from swinging around. It required constant control movements in manual mode and was still almost impossible to drive in a straight line. I thought the pixhawk could handle this, but I was wrong.
After a bit of thinking, I came up with a simple solution. I had to make the pivoting wheel favour one direction (straight). I could not use springs, because then the rover would not be able to drive backwards anymore.
So I mounted the base of the rear wheel at 20° angle and therefore also the rotating plane of the wheel. Now the wheel always returns to this position and keeps the rover driving straight. Tuning it was a no brainer now.
The only thing that is not working as expected is the pivot rate limiting. I set it lower and lower (30deg/s now),
but it is still going full speed in pivot turns, almost stripping the drive gears.
It is running 3.4.2 now.
Hi Randy, I just added an active tailwheel to my rover. I do not know if anybody tried this before, but I still had issues with the rover not driving straight. Tilting the mounting plate of the tailwheel worked for the smaller wheel I had mounted to the rover before, but the bigger wheel started to shimmy really bad. So I connected a servo to the tailwheel, but the normal groundsteer output does not reflect the movement of a skid steer vehicle.
As a solution I set the pixhawk to output throttle and steering on Channel 2 and 4 and read the values with an arduino. After a bit of trigonometrie etc. I get a usable output for the tailwheel servo.
Would it be possible to add such a steering type directly to ardurover? If I am the only one using this, please ignore my request.
A picture of my test setup (still waiting for the xlarge servo from hobbyking):
I think we could try and add that steering output even while using a skid-steering rover. The issue will be getting the scaling right because I think it depends upon the steering angle of the servo, length of the vehicle and even the speed of the vehicle. Perhaps we would need one extra parameter added to the motors library…
Best first step is to add an enhancement request to the issues list…
