Difficult turn rate tuning of a new rover

Hello to all,
I am building a new rover on a Kraton 8S platform and Rover 4.1.1. I am trying to tune the steering with no sucess so far. I guess that a set of correct values for the ATC_STR_* parameters should work, but after many trials, I see a weird behaviour I cannot explain, any help will be much appreciated!

Basically, The rover works well in manual mode, it does sharp curves and have set ACRO_TURN_RATE to 100 deg/sec.
But in acro mode, steering is too weak. It seems to work at first, but after a few meters, it seems that the angle is lower and lower. I have tried to follow the tunning guide at Tuning Turn Rate — Rover documentation.
First, setting FF parameter higher and higher, up to a value of 2.5 (max is 3). Then I raised P and I values (both up to 0.5) , but still not enough.
In this screenshot of the PIDdesired and PIDachieved values it is clear that the 100deg/sec command is never achieved:

But the weird thing is that, with the stick full to the right or to the left, the angle of the wheels seems to decrease gradually, even with the I parameter having a non-zero value:

I understand that the Integral part of the should try to correct the error if it remains high for a long time.
I have not increased FF, P or I values because I think they are very high and the behaviour does not change. I suspect that I forgot to change some other important parameter, but I don’t know which one it could be.

Any help will be appreciated.
This is the tlog file : 2022-02-13 12-24-00.zip (855.6 KB)
These are the parameters from the log: colina problema steering 00000010.BIN.param (15.4 KB)

Thankyou all in advance.
Adolfo.

Hello again, I am updating the information about this issue with new experiments.
The main problem is that the desired turning rate (100deg/sec) is never achieved in acro mode, and worse yet, it seems to decrease gradually when trying a sharp turn with the stick full to the left or to the right for several seconds.

I noticed that the x,y acceleration at rest was not zero, so made the accelerometer calibration again.

and I also realised that I never tried to change the ATC_TURN_MAX_G parameter, set to a default value of 0.6G, so that could be the problem. after setting this parameter to a value of 2, nothing seems to change.

In this screenshot, the command to a full turn to the left (100deg/sec) is never achieved, and the PIDachieved value goes up and down. this is with a high value of FF=2, P=0.5 and I=0.5

This is the telemetry log: 14feb2022 home 2022-02-14 15-27-08.zip (529.8 KB)
And a link to the dataflash log: Sign in to your account

I understand that some other parameter is limiting the PID output, but I cannot find it.

@rmackay9 I am sorry to bother you but I will really appreciate if you could have a look to this, you seem to do magic when look at the logs :grinning:
Thankyou all in advance.
Adolfo.

@Adolfo_Cobo,

I think maybe the issue could be the classic mistake of having both inputs and outputs reversed. This is normally the issue when the vehicle is working well in Manual modes but other modes don’t work.

The way to know is to test the steering (and throttle) output response using Mission Planner’s Motor Test page Motor and Servo Configuration — Rover documentation

If this ends up being the issue then the fix is normally to reverse some of the channels in the transmitter and also set the SERVO1_REVERSED and/or SERVO3_REVERSED to “1”.

I guess also this vehicle’s motor/ESC doesn’t allow reverse unless the throttle is left at zero for a second or two? AP doesn’t support this kind of ESC behaviour so if you can disable it somehow that would be best. Some ESCs have a setting or a jumper that means negative throttle will make it immediate reverse with no need for the throttle to be left at zero for a second or two.

In the graph below of desired speed (in red) vs actual speed (in green) we can see the desired speed is going very negative but there seems to be no response from the green line (the vehicle isn’t backing up)… then later on it does start backing up but only after the desired has been returned to zero for a bit.

P.S. let’s move this discussion to the 4.1 category.

Thankyou @rmackay9 for your help, I really appreciate it!

I have checked the double reverse hypothesis. The throttle is Ok because the motor test make it rotate forward. For the steering channel, I have done the following:

  • in the MP radio calibration screen, un-click “reverse” in the radio channel 1 (then, in manual mode, the direction was opposite)
  • in the servo calibration screen, check “reverse” in the steering servo 1, now manual mode works ok again.

I have tested the rover in ACRO mode but the problem persist, but PIDdesired and PIDachieved have opposite sign, so I believe that now I have the double reverse problem, not before. In any case, the PIDachieved magnitude is always lower than desired:

So, according to this, I believe that the double reversed is not the problem.

I was thinking that maybe the parameter ATC_TURN_MAX_G = 2 is still too conservative for a turn? I have plotted the acceleration in y axis (ay) and max value are -300 and + 350 (I am guessing the units in the tunning windows are milli-Gs), so it is not achieving the limit of 2G, though.

new tlog (above screenshots are from this): 2022-02-15 15-05-54.zip (892.7 KB)

Thankyou again for your help.
Adolfo.

Hi @Adolfo_Cobo,

Yes, that doesn’t look good.

Can you do the motor test though to make sure the steering is turning in the correct direction? That really is the definitive way to get the outputs moving in the correct direction.

ATC_TURN_MAX_G of 2 is a huge number actually. Most vehicles can’t achieve higher than 0.6. Somewhat confusingly this parameter’s units are Gs but in the logs (and maybe in telemetry) the units are normally m/s/s which means the values appear 10x larger than they really are. Now if it’s appearing as -300 and +350 in the tlogs then I’m not sure what the units are. maybe cm/s/s but I’ll need to check.

Re TLogs vs onboard logs (aka dataflash logs) the onboard logs have so much more information than tlogs.

Hi @rmackay9 ,
I forgot to tell that the RC car has a servo for the steering, not two motors. I have just checked with a servo tester and the vehicle goes to the right for low PWM values, goes to the left for high PWM values. In my original configuration, I had SERVO1_REVERSED=1. Trim value is 1500 and min/max is 1100/1900.
I cannot find in the docs which is the expected setup of the steering servo: low PWM for right, or the opposite, if it is the opposite, it was alredy well configured.
Regarding the lateral acceleration, if 2G is high enough margin, that is not the problem. I don’t want to do very sharp turns, but now I am only able to do a 90deg turn in a 6-meter-wide yard, not enough at all.
I have posted above the dataflash log of one of the test, once I reach a proper configuration for the correct direction, I will have a look to the dataflash logs with more detail.
Thanks again for your help.
Adolfo.

Hi @Adolfo_Cobo,

OK, that certainly sounds like the SERVO1_REVERSED should be “1”.

Sorry to be so pushy but could you confirm the steering direction using MP’s Motor Test page?

I think if you push the “Test B” button with a positive value put into the “throttle” field the steering should turn to the right.

If you push the “Test A” button then the wheels should turn so the vehicle moves forward (elevate it off the ground of course before doing this test!).

Thankyou @rmackay9 again for your reply.
I have tried to test the steering with the motor test page but only motorA (throttle) do anything. motor B-D do nothing. I understand that setting a % value for a motor other than motorA should send a PWM value in a servo channel, but, which one?
In any case, if you say that the software is expecting a high pwm value turning the wheels to the right, I have confirmed that using a servor tester, so now I am pretty confident that the configuration is ok.

However, I did more tests today with another rover, a much smaller RC car that have exactly the same components (other than the chassis, motor and ESC) , and was set up by me in the same way. I have found the same exact behaviour, but interestingly, I have found that the PID error is dependent on speed! I didn’t noticed it with smaller car because it has a much lower power and I tried it mainly in auto mode, at low speed.
The thing is: both cars do sharp curves only at low speed. Changes in the PIDachieved when trying to turn at full stick are owned to changes in speed, for example, this smaller car has ACRO_TURN_RATE=60 deg/sec:

The changes in the PIDachieved were clearly related to changes in speed I was doing with the transmitter. With this new information, I believe that there is a speed/acceleration limit somewhere that is preventing the atc to achieve full turn rate.
Any idea which parameter could be related to that?
Thanks again!
Adolfo.

Update:

I have downloaded the dataflash log and plotted:

  • IMU(0).AccY which I understand is the lateral acceleration
  • PIDS.tar which I understand is the steering PID target value
  • PIDS.act which is the achieved value.

I want to see a relation between the achieved value and the acceleration, so it seems to me that the acceleration is limiting the turn rate. However, maximum value is about 2 m/s/s, 0.2G , and the parameter ATC_TURN_MAX_G is set to the default value of 0.6G , about 6 m/s/s.

Is there any other parameter related to a maximum lateral acceleration? I will try tomorrow to set this parameter to max. value of 10 and see what happen…
Thankyou again for your help!
Adolfo.

dataflash log: Sign in to your account

1 Like

@Adolfo_Cobo,

I’ve just tested MP’s motor test screen and It is working correctly with Rover-4.1.4:

  • “Test Motor A” button caused the wheels to move. Setting “Throttle” to 50% made them move fowards. Setting “Throttle” to -50% made them move backwards.
  • “Test Motor B” button caused the steering to move. “Throttle” of 100% made it move fully to the right. “Throttle” of -100% made it move completely to the left.

Maybe you didn’t change the throttle value? Sorry to keep harping on this but making sure the steering and motors are moving as expected is one of the key steps. If this isn’t working then all the above controllers won’t work either.

In the dataflash log linked immediately above the steering is output on servo1 (SERVO1_FUNCTION = 26) and throttle output is on servo2 (SERVO2_FUNCTION=70).

@Adolfo_Cobo,

The speed control seems to be working quite well at least at the end of the logs. We can see the PIDS achieved is following the desired quite well (the same thing can be see in the THR.DesSpeed vs Speed).

The steering controller is struggling a bit more because we see the Actual is always underperforming vs the desired.

The most important value to change is the feed forward (ATC_STR_RAT_FF) so here are some suggested new values:

  • ATC_STR_RAT_FF 1.4 (was 0.8)
  • ATC_STR_RAT_P 0.4 (was 0.2)
  • ATC_STR_RAT_I 0.4 (was 0.1)

By the way, we did recently find and fix a steering limit bug that affects “ackermann” steering vehicles at low speeds so you could try using our “latest” version of the software by going to MP’s firmware install screen and pressing Ctrl-Q. Then you should see the labels below the icons change to “Rover 4.2.0 DEV” and then you can click on the icon and it should install it to the vehicle. Be a little careful of course because this “latest” version hasn’t gone through beta testing (beta testing of 4.2.0 will start next week).

Thankyou again @rmackay9 !

Just to be clear, my last post and last dataflash log posted was of another vehicle, a much smaller RC car that it is way easiest to play with, this smaller car is a copy of the larger one with just another chassis, I have tried to configure both in the same way. And both has the same problem of low turn rate.
You were right about motor test: I did not apply enough throttle % to motorB, now with 100% throttle, motorB moves the wheels TO THE RIGHT as expected. SERVO1_REVERSED is set to 1 because high pwm values of the servo turn wheels to the left.

Moving on, I have made a new test changing ATC_TURN_MAX_G = 10 (maximum value) and did not found any changes in behaviour: at very low speeds turns are sharp, increasing speed reduces the wheels angle and car goes almost straight, even when the steering stick if full to the right, and PIDdesired and PIDachieved depart. Besides, the “shape” of the PIDachieved in the logs resemble the lateral acceleration.

I believed that this speed-dependent behaviour would lead to a limiting parameter, but I don’t know of any other than ATC_TURN_MAX_G.

I will try to install 4.2.0dev and see if that bug is the cause.
Thankyou very much again.
Adolfo.

1 Like

@Adolfo_Cobo,

I don’t think the ATC_TURN_MAX_G is to blame and that should just be returned to 0.6 (or lower).

When tuning an Ackermann vehicle’s steering controller it’s best to drive it at 1m/s (or faster) and then do the real-time tuning (by setting GCS_PID_MASK = 1 which I think you’ve already done). The most important parameter is the ATC_STR_RAT_FF. In fact, sometimes when initially tuning a vehicle I set ATC_STR_RAT_P and I to 0… tune up ATC_STR_RAT_FF and then finally just set ATC_STR_RAT_P and I to about 20% of FF.

AP Rover scales back the steering response as the vehicle’s speed climbs above MOT_SPD_SCA_BASE. Below this speed the controller’s do not adjust the response based on speed. Most users don’t need to adjust this parameter and I think it is best to leave it as is. If you do choose to change it, in general if you halve this number then you also need to half the ATC_STR_RAT_FF/P/I parameters. If you double MOT_SPD_SCA_BASE then you double the ATC_STR_RAT_FF/P/I parameters.

Maybe you already know this but just in case…
I think it would be good to try increasing ATC_STR_RAT_FF as mentioned above.

1 Like

UPDATE:
I have installed rover 4.2.0dev. I did not noticed any changes, so I guess it is not related to the motor limit bug, this is a screen shot of yet another test:

Then I changed the FF,P,I parameters with the values @rmackay9 suggested, it seems to do better, but still, there are changes in the PIDachieved values up and down related to speed changes.

It seems to do sharper turns, but still, at higher speeds (3 m/s at most) the turns are not so closed.

My question now would be: is it expected the PIDachieved values to change with speed?

Thanks again!
Adolfo.

last dataflash log (4.2.0dev, higher FF,P and I values): Sign in to your account

1 Like

@Adolfo_Cobo,

This log is looking much better!

One issue may just be that at higher speeds, with an ACRO_TURN_RATE of 60 the radius of the turn circle will be much higher. Maybe just try increasing ACRO_TURN_RATE to 90 (and maybe bump up ATC_STR_RAT_MAX to 120)… I wouldn’t expect Acro to feel like Manual mode (where the pilot control the steering angle) on the other hand the vehicle should be easier to drive in a straight line in Acro mode.

I think if you try a mission now it will work OK although it’s possible we may need to adjust NAVL1_PERIOD and/or NAVL1_DAMPING.

1 Like

Thankyou for all your help!! I’l follow your advise.
However, I have now to apply this learning to the larger RC car Kraton 8S, wich was already with much more aggresive PID parameters and never achieved a decent turn rate at all.
I hope to be able to fix it by myself, though
thanks!

1 Like

Just to “close the case”, the problem was mainly due to the MOT_SPD_SCA_BASE parameter, which above 1m/s reduce the steering, and preventing enough turn rate. with a value of 2, everything works fine.
Thanks @rmackay9 a lot!
Adolfo.

2 Likes

Thank you both! I have a similar build (traxxas 2wd rc car with steer servo) running BB Blue Rover. Acro mode tracking on graph was poor and auto mode car going in circles. Going to Rover 4.2 dev fixed that!

Got it running missions for the first time!

Changed a few tuning settings and a few other learnings from this thread. Thanks again!

Those speedy little cars can be tough to tune well. Glad you got it going!