I set up a grid pattern for a mower. Mine reverses easily, so I have it going in Forward from R to L and reverse from L to R. The mow lines are 0.6m apart and the lines are 30m long. It seems to overshoot and undershoot turning waypoints most times and doesn’t track very well with the correct path. I have a 1 second delay after each turning WP and cut the mower speed by half at waypoints. “Distance to wp” is tight at .02. Anyone suggest some tuning recommendations to get the mower to converge on its track between waypoints faster and tighter? Attached is simulator output. Mower starts at WP 6 and moves to the left, reversing at the left side. Second screenshot is closeup of right side.
I’ve been following the writeup in Mission Planner “Tuning Navigation”. Again, only in the simulator. My speed is .5m/s. The only thing that seems to help get the mower to track is increasing PSC_POS_P from .2 to higher numbers. Attached is set to .4. It still has a huge “S” at the beginning of the run, but does actually try to get back to the track and seems pretty good at the end. If I could get it to the track quicker and with no “S”, that might be OK. It also does a quirky forward, back, forward thing for about 3 meters or so. You can see that in the purple track. I have no idea what is causing that. I have WP_Speed .5 m/s and delay of 1 second at every WP. WP_Radius is 3, Turn_radius is .1.
OK. I’m talking to myself, but this is a good way to document what I’ve been trying. Its throwing darts blindfolded, but… So, in the Navigation Tuning section, it says not to change PSC_POS_P, and leave it at .2. Of course, the range listed in the parm list is .5 to 2. So I cranked it up to 1 to see what would happen. It follows the track much better. Still has the funky glitch of F-R-F over about 3 meters at the ends of each run–still no clue what is causing that. And still an annoying “S” at the beginning of each run. but it does converge much more rapidly to the correct track. I’m now diving headfirst down this rabbit hole. Wish me luck.Attached is PSC_POS_P=1. The PSC_VEL_x’s are all way high as well.
OK. Cranked PSC_POS_P to the max of the range: 2. WP_Radius 1, Turn_Radius .1, WP_Pivot_angle=45. Pivot delay=1.In the attached screen shot, I see that on the right hand side, (the rover is entering the pattern at WP 4), it does its stutter-step F-R-F thing before 4, then pivoted at 4 to align perfected with 5,6&7, delayed one second, THEN it turned hard let and did its “S” toward 8, finally getting where it belongs at 8. But the rest of the rows look good. Then it did the same thing at 26 trying to go home: nice pivot turn to align with next WP and then forced a funky “S”. Also, on the left side, where the rover is moving backwards, the behavior is different. It leaves the WP on the left side straight out, then does the funky “S” to try to get back to its path, but is screwed up for 8-10 meters on the left side before getting back. ANy suggestions from people better than I am at this? (probably everybody…)? So, my question is: what do I have to do to stop the “S” from happening? I cannot turn off the S-curve function, so what parameters do I set to dampen it to near zero?
OK. Its not too bad now. However, some interesting points. 1) S-curves totally DEFEAT pivot turns. At WP4, it did a nice pivot turn, aligned perfectly with the WP7 and then the scurve caused it to point down and do a funky S to get to 7. So, pivot turns are highly desirable in skid steer and I’d hate to see them defeated. 2) the s-curves act differently when moving in forward and reverse. Looks like a sign problem? 3) Minor annoyance is that I cannot get MP to re-run a mission. I have to get totally out of MP, reload, redo sim, reload WP’s and then restart. The buttons “Start Mission”, “restart” “resume” do nothing. arm/disarm, auto, all nothing. It slows the process.
On the left side, where it goes from R-L forward, then reverses at 8, 16 and 23 to go L-R in reverse. On the top (WP 8), the rover goes far left, then tried to make a turn and come back to the next row and s-curve defeats it. Middle (WP 16), it turns at WP15 and goes to the next row, then reverses and comes out straight. In the bottom (WP 23), the wp23 is between the two mowing rows. Both the bottom two would work. The top one is defeated by the s-curve and would not work.
You’re pretty off the rails here. Follow the documentation for tuning. I’m not entirely sure how to help at this point, though I’m glad you’re making progress.
S-Curves have exactly nothing to do with pivot turns. S-Curve navigation simply refers to a means of connecting two legs of a mission with a smooth curve (turn), such that the vehicle turns short of a waypoint to align with the next leg.
If a pivot turn occurs at a waypoint, there is no S-Curve.
I’m confused. Thanks for the insight. In my plot, the mower is coming down to WP 4, it does a pivot turn, lines up perfectly with 7, pauses 1 second, then turns left again and does the curved path you see to get to 7. What might cause that? Adding and subtracting WPs between 4 and 7 does not change anything except slightly change the shape of the curve. It does the same thing at 27 on the way home: pivots to line up with home, pauses, then turns to the right and does a curve to get back up.
It’s pivoting short of WP4, aggressively trying to get back on course, overshooting, and oscillating until on course. That’s not S-Curve behavior; it’s oscillation as a result of poor configuration.
It needs to pivot at the waypoint (not before or after).
The steering tune is likely poor.
The navigation tune is likely out of whack as a result of attempting to tune navigation before the steering tune is good.
You’re trying to correct all the problems by driving the PSC controller gains through the roof. Wrong approach (and in violation of the documentation regarding PSC_POS_P). Again, follow the documentation.
It might be a valid exercise to try and tune the SITL models, but I’m not sure how valuable it really is for you, especially given that you’re making strange assumptions and failing to follow established procedure.
So perhaps going back to defaults on everything but PCS_POS_P (=2). Then re-run it and see if the oscillation goes away. What would you recommend for WP radius and Turn radius? Currently I have 1.0 and 0.1 respectively. I think you are saying it is pivoting 1m before 4, then trying agressively to get back to 4? or to 5? Interesting. I’m learning more every time.
Neither matter when the pivot controller is in use.
We do have a bit of a known issue regarding pivot controller performance near the waypoint. In present firmware, it’s a bit difficult to perfectly nail the waypoint for a pivot turn. The accel and decel parameters play a much bigger role in that than much of anything else the user can control.
OK. A lot of insight here. Thanks. I set WP radius to 0, left everything else the same. Figured I might get rid of the funky behavior at 4. It did. This time it apparently went totally to WP4, pivoted, then my agressive (bad) tuning caused some oscillation, but it did head MOL directly to 7. It did stop dead on the next row, and not sure why. Its been several minutes with no movement. Delay is set at 1 second. Never stopped before.
I think I’ll take your advice and move the tuning parameters back to default. But I might need PCS_POS_P=2 to get it to track directly to next WP without wandering or staying well off the path. Unless you have some insight on better way to make it stay on track.
So, with the current firmware, what’s the best idea to get it to properly do a pivot? Change accel/decel parameters? Just take it as it is?
PSC_POS_P should be left at 0.2 (the default). This converts the position error into a desired velocity. Higher values will lead to the vehicle trying to drive back to the line more quickly but if raised too high may lead to oscillation
Read the documentation. Please. Please. Please.
And you are misunderstanding the effect of WP_RADIUS. It didn’t affect the WP4 behavior at all, but rather, made it so that it HAS to cross WP 5. Putting that many waypoints in a straight line is a great way to get red herring results. Don’t do it. Setting WP_RADIUS=0 is also a bad idea. Don’t do that either.
OK. I’ll go back to defaults. When I do that, though, it will not follow the line to the next waypoint. it drifts perhaps .3m off the line and stays there. What is the simplest way to force it to just follow the waypoints and stay on line to the next one?
BTW, are the right side end points, where it goes from reverse to forward, considered by MP to be a pivot point? Its been stopping dead at these points.
So I got rid of intermediate waypoints between 4 and 7 and went back to tuning defaults, including POS_P to .2. All PSC’s to default. Pivot angle is 45 degrees, WP radius is .1, turnradius is .1, Speed is .5m/s. Tuning parameters default of the sim. It no longer follows the path from waypoint to waypoint. Again, its off by .3m or so. Pivots nicely at 4, though.
and the rest of it:
To me, this will not work for my mower.
You’re tuning something that isn’t your mower, so conclusions here are to be taken with a grain of salt, though I think you’re at least learning a bit.
Also, this is default SITL behavior for the rover-skid model, which I should think would be adequate performance for ANY mower…
2 Likes
So, how did you get that performance from the skid-steer? That is pretty good, depending on the scale. In mine, the rows are 1m apart or less; the width of a yellow line is perhaps a couple inches. What is the divergence in your plot? If also a couple inches, it is wonderful and would be certainly great. If those are cars in the upper right, maybe not. Looks like 6-12" of divergence…
So I did a complete wipe and back to defaults on a 1m grid. At reduced zoom, looks pretty good. Zoomed up, its probably 4" diverged from the yellow line. Can I do better? Or is this the best I should anticipate?
I left everything at defaults. My pattern is maybe 1.2m wide (I just eyeballed something like a mower might do). It overshoots the pivots by about a foot and then maintains within 6" on the straights.
You can likely do a little better than that, but 3-4 inches of crosstrack error is likely the practical limit, especially in turf where the terrain is not perfectly flat.
Just now, I got SITL to behave quite admirably by changing only the following:
GPS_POS1_X,-0.22 # (accounts for GPS antenna position aft of the pivot center)
PSC_VEL_P,1.2
PSC_VEL_I,0.24
PSC_VEL_D,0.005
ATC_STR_ANG_P,2.66
WP_PIVOT_ANGLE,10
I arrived at those values by following the basic configuration and tuning documentation. There is no magic there.