One thing about the “log rotation”, is that disarming is important. This is the moment where it closes the log file. Then it opens a new log file when the vehicle is next armed (as per usual). I guess the point is that not all the action happens when the vehicle is armed… some happens at the moment it is disarmed.
yes, I experienced this case. but you can push RC control forward a little bit, then rover keep going. but it was happened for Rover4.2.
Re: Log rotation, it has started working for me now. I changed ARMING_CHECK from 0 to 16 and there’s a chance that that may have solved the problem. Maybe you want to test that on your end?
I do observe noise in the actual speed measurement even with a constant throttle. This graph is from a run with P=0, I=0, D=0, i.e. using a constant throttle output. Logfile here. Note the noise in the actual speed.
Re: ATC_SPEED tuning. I’m using VESC speed controllers. I was using EPRM mode but switched to Duty Cycle mode which (per this post) essentially is a speed control mode. Because of this I eventually concluded that the P term in ATC_SPEED was less impactful on the tuning for my setup (given the feedforward that results from CRUISE_SPEED and CRUISE_THROTTLE, and that the VESC controller attempts to achieve a corresponding speed). I basically didn’t observe any difference in the results between P=0 and P=0.4. The ATC_SPEED I term however did make an improvement. Final run in this logfile. I’m fairly happy with the results. I experimented with the D term and it didn’t reduce overshoot so I set it back to 0. Ended up with ATC_SPEED P=0.1, I=0.5, D=0.
Now on to the steering tuning.
2 Likes
OK, good stuff. As you say, the speed controller seems to be doing well.
Normally it’s good to have a bit of P along with the I but if it’s all working then that’s the important thing. Nice!
@rmackay9 I am back to tuning. (Why did this take a month? last tuning session I experimented with PID terms for the steering controller that caused violent oscillation of about 90 degrees in heading, at about 1 Hz, left and right. On a 205kg rover something had to break… and it did. I had always been wondering what the weakest link in my traction system was, and now I know: the output stage of the 1:108 reduction gearbox will break if turned violently forward and backward. Back to the drawing board… and here I am a month later with a much stronger output stage, and a smaller 1:81 reduction, and some other improvements. cc @Yuri_Rage @ktrussell )
Back to the topic at hand. I think speed controller is tuned well (yes I did adjust Cruise Speed and Cruise Throttle for the new gearbox) with P=0.1 I=0.5 and D=0. Logfile Here.
For tuning the turn controller I use a small mission with several 250-300 degree turns. My read of your instructions here is that if I get good performance with just FF, I can leave P, I, D=0, and I think I am getting that. Do you concur? WP_PIVOT_RATE=60 which is 1.05 rad/sec. Turn Controller Tuning Logfile Here.
Now, how should I best proceed to tune for s-curves? Move straight to POS_POS_P& PSC_VEL_P/I/D using your notes here? Or should I work on ATC_STR_ANG_P and ATC_STR_RAT_FF first?
1 Like
Built another 4 meter AIMy with everything new and this is the best I can get out of her.
I find it strange that the craft is tracking the ‘desired steering’ very well, but the ‘desired’ path is like that of a drunken driver.
My question is: How do we get the desired steering to match the actual flight path?
Log file:-
https://www.dropbox.com/s/obhf7plzjflqo8n/00000027.BIN?dl=0
1 Like
@John_Easton I have the same question. My rover weaves back and forth across the desired path. With the old L1 controller it was cross-track-error and I knew how to tune it. I don’t know what the new equivalent is with the S turn controller. Do you?
1 Like
Unfortunately I do not Chris, I am hoping that Randy hops on here soon and helps me out again. He is very busy, but when he does get a gap he generally sorts my problems out.
The biggest issue I have with Rover 4.3 and S-Curves is repeatability - one day everything is just about perfect and the next the boat is all over the place.
2 Likes
The parameters you are likely most concerned with are PSC_VEL_P, I, and D.
The latest builds zero the I and D terms by default. Try increasing them incrementally. Values less than 0.5 seem to be typical.
I have not yet reviewed your log, so this is a bit of conjecture on my part.
EDIT: removed some misdirected text
1 Like
@Yuri_Rage… whose turn rate controller screenshot do you observe overshoots and oscillation? My post from 3 days ago (displaying a PIDS chart) or John’s post (displaying a STER chart)?
Oops! The pitfalls of using a phone to respond…I scrolled up too far and referenced your chart, mistaking it for part of John’s post.
So, the following paragraph should’ve been addressed to you, @Christopher_Milner,
Reviewing just the screenshot of your turn rate controller reveals some overshoots and oscillation that very likely contribute to the path wandering that you are seeing. You should work to tame that, first (reduce ATC_STR_RAT_FF and/or P, and then increase I and/or D very slightly. It’s also possible that you need to reduce the D term, as there is some increasing amplitude oscillation that may be the result of a runaway D term).
The new position controller is particularly sensitive to poor steering and throttle tuning. There’s a surprising amount of margin in the PSC_VEL_* parameters to achieve good results once the throttle and especially the steering are behaving well.
Thanks @Yuri_Rage for quickly responding. Is it your sense that those errors in PIDS, whose magnitude is roughly 0.05 to .1 rad/sec (i.e. 3-6 degrees/sec difference between target and actual) and whose frequency is roughly 2 Hz really worth tracking down? This was taken when my rover was driving on gravel and I figured it was just the rover bouncing a little bit on the gravel.
On the same topic, what do you think about the errorsin my PIDA loop whose magnitude seems to be about 0.05-0.1 m/s at about 2 Hz in my PIDA chart, here
I think the important takeaway from your steering graph (PIDS) is that there are many instances of what appear to be increasing amplitude oscillations. Contrast that with mine at a similar scale from a run on very uneven terrain (perhaps I could do better with some filtering, but I haven’t dug that deep just yet on this particular tune, and I was surprised at the amount of noise shown here, given the well-behaved steering).
Although the target curve is pretty demanding, the actual output is smoothed by comparison and almost always decreasing in amplitude during any oscillation.
Your throttle is fairly well behaved but it seems like a slight decrease in P and, more importantly, increase in I are warranted based on the tendency to overshoot followed by a slow correction.
Hi @John_Easton,
Thanks for the logs. I had a peek and I think the steering tuning could be improved a bit because we can see that the actual turn rate is overshooting the desired turn rate by about 2x.
If we graph the PIDS (PID output for steering) below it looks to me like FF is doing most of the work. P is zero (this is unusual), I is contributing but it is probably just fighting back against the overshoot caused by FF being too high. D is just adding noise.
So could you try these values to see if it helps?
- reduce ATC_STR_RAT_FF from 0.2 to 0.12
- increase ATC_STR_RAT_P from 0 to 0.05 (same as ATC_STR_RAT_I)
- reduce ATC_STR_RAT_D from 0.05 to 0
The next part is the navigation and path planning which relies on the lower level steering controller working well. Below is a picture of the desired and actual north-south velocity. The DVN (Desired Velocity North) in red is what is coming out of the S-Curves and it is quite sharp. I think the frame (shown in the blue line) can’t actually turn this quickly so we should:
- reduce ATC_ACCEL_MAX from 1.0 to 0.5
I’m happy to do another live tuning session over the next couple of weeks although I’ve got my own boat testing to do Mon Oct 17th ~ Wed Oct 19th so need to avoid those days.
P.S. sorry for the delay, the Japan Innovation Challenge and Google-Summer-of-Code have kept me underwater for the past couple of months.
1 Like
This again shows the sensitivity of the SCurve algorithm to poor tuning. It is imperative to sort the basic throttle and steering tuning before moving on to navigation tuning of the position controller.
@rmackay9 @Yuri_Rage could you take a look at this log and let me know what you think? Latest beta of ardurover. Short mission with some straight segments, a few pivot turns, and a few s-curves.
PIDA and PIDS graphs here for your reference
Thank you Randy, I will most certainly make these adjustments and report back as soon as possible.
If there are still some issues I will appreciate another live on the water tune like we did last time - thank you once again.
1 Like
@Christopher_Milner, your basic tune looks very well behaved overall, though the throttle tune is odd. You have ATC_SPEED_P set to 0.1, while I is set to 0.5, and a graph of the PIDs shows that the I term is doing all of the heavy lifting. I suspect you might see some misbehavior in certain cases with I term buildup. Recommend retuning throttle with an increased P term and reduced I term.
Pivot turn performance looks very nice, and path tracking is excellent in general.
I suspect the issues with non-pivoted turns are acceleration related. Does the vehicle tend to coast quite a bit when slowing or stopping? (now that I look at the speed curves again, I’m not certain that coasting is the problem, though) I apologize that I’m not quite as astute as @rmackay9 at immediately deducing the root cause of path following issues and offering somewhat precise parameter values as fixes. I’d be very curious as to Randy’s insight there, especially when he’s recommending specific values.
If precise path tracking of those short segments is imperative, you may want to reduce PIVOT_ANGLE.
What type of vehicle is this?
1 Like
@Yuri_Rage this is a skidsteer lawn mower. Build photo album here. Traction is bldc electric motors driving wheels through reduction gearboxes. It coasts very little if at all (although part of this mission was down a slight incline; ATT.Pitch is pretty accurate on this rover).
Because it’s a lawn mower, precise tracking is imperative. The path tracking performance is quite good when I force all turns to pivots (by reducing PIVOT_ANGLE to 1).
The big advantage of S-curves to me, if I can get them working, would be performing a 180 degree u-turn at the end of a strip and positioning for the next strip while rolling. This would save a lot of non-mowing time wasted in the (two) decelerate-pivot-accelerate cycles required for the (two) 90-degree turns I’m currently performing at the end of each strip as shown in the following (note, this diagram is not the mission from the logfile I posted earlier today):
Ok, that explains a lot! I assumed it was an electric motored vehicle because of the lack of noise that is inherent in hydrostatic controlled/combustion engined mowers.
I have a few other things going on right now, so in the meantime, have a play with TURN_RADIUS, TURN_MAX_G, ATC_ACCEL, ATC_DECEL, WP_ACCEL, WP_JERK, and WP_RADIUS to see if you can get the turns dialed in a bit better.