We’re mowing in straight strips. Here’s a recent mow - about 4 acres.
2 Likes
(@rmackay9 just making sure you saw the question to you from Yuri and me in this thread a few posts back)
Thanks for the log. I’m seeing some issues trying to review it with Mission Planner. I get the message below. I’m not sure what has happened with this log because I don’t see the problem with other 4.5.0 logs.
As a temporary work around I’ve found that if use MP to convert it to a .log file it can then be opened.
In any case, the steering and speed controllers seem to be working pretty well.
Here’s a graph of the steering controller’s desired turn rate vs actual turn rate and we can see they match quite well.
Similarly for the throttle controller the actual speed follows the desired speed well. There’s some noise but these are all small numbers so it’s OK I think.
So the issue (if there is one) is likely in the higher navigation controllers.
The cross track error is pretty small. It’s always less than 20cm and those 20cm offsets are only occurring at the corners.
It’s a skid steering vehicle so it should be able to turn on the spot without the vehicle’s position changing. You can actually test yourself whether the vehicle’s position changes when rotating on the spot but in any case the cause could be:
- when pivoting the inside wheel stops while the outside wheel keeps moving instead of both wheels turning in opposite directions. This issue could be due to the ESCs being used. For example some ESCs don’t support spinning the wheels in reverse at all. I think some ESCs provide current output and that may not be enough to overcome the static friction of the stopped wheel… I’m not really sure about the cause though.
- the GPS position offsets have been set incorrectly.
I’m not sure we have either problem though because the cross track error is very small (only 5cm) on the sharp corner where the vehicle does a pivot turn.
So it’s a bit surprising that the issue only appears on a slow rolling corner.
I think from your comments above you’d like the vehicle to start the corner earlier and I agree that a wider slower corner probably would keep the cross track error smaller. There is a to-do item somewhere on the issues list to use Rover’s minimum turn radius as an input to the SCurve path generator but that hasn’t been done yet.
So to make the corners wider all you can do is increase the speed (maybe not possible with this frame), make WP_RADIUS big (like 5 or even 10 - it probably won’t matter) and then reduce the acceleration (e.g. WP_ACCEL = 0.2). The problem with reducing the acceleration too low is that it also affects the forward-back acceleration so it could take a while to get up to speed.
By the way, I see that ARMING_CHECK = 0. Is there any reason which kept you from leaving it at the default of 1?
Thanks @rmackay9 . On my frame & ESCs I am able to pivot, with the inside wheel turning backwards. So that’s not a problem nor a source of error here. If I set WP_PIVOT to 10 degrees so that all of my turns are pivots, then, the mower tracks well. Also, the GPS Position Offsets are set correctly. The first antenna is at the center of the vehicle (between the traction wheels). The second one is 1.1meters in front of it. I doubt the GPS Position Offsets are a source of a problem otherwise I’d see other problems when doing pivot turn navigation.
I’ll experiment with WP_ACCEL and let you know-
1 Like
@rmackay9 @Yuri_Rage we are making some progress. There seem to be a coupla factors at play.
With WP_SPEED=1.8, WP_ACCEL=0.3 and WP_RADIUS=0.5 the rover cuts a 90 degree turn nicely. See WP2 lower right of this image. It slowed down from 1.8 to about 1.0 or so for the corner, and cut the corner very nicely, seemingly so as to come within WP_RADIUS of the waypoint and landing on the outbound track. Very nice!!
However for a 90 degree turn followed 1.2 meters later with another 90 degree turn (which is my primary case), it didn’t even cut the first 90 degree turn as nicely see WP3 and WP4. It did slow down coming in to WP3, but, doesn’t cut the WP3 corner at all really, instead overshooting that turn slightly, and subsequently also overshooting the WP4 turn.
Any suggestions would be appreciated- Thank y ou
Just for grins, what happens if you move WP4 a little farther away (maybe by 2 x WP_RADIUS or more)…something like this?
Good idea. I tried moving WP4 from 1.2 meters away to 2.4 meters away (i.e. from 2.4x WP_RADIUS to 4.8x WP_RADIUS) and the behavior was about the same. (Perhaps slightly better… hard to tell). As of right now making a rolling uturn by using S-Curves to navigate 2 90-degree corners still seems out of reach for my rover, speeds, and waypoint distances. Sure would be nice if I could get it working because making all those pivot turns takes a lot of time on my mows!
1 Like
Re why putting waypoints closer or further apart has an effect, SCurves has a built in limitation that it only looks two waypoints ahead (e.g. the current waypoint it is driving towards and the one after that). Because of this it will never go so fast as to be unable to stop at the 2nd waypoint. So in short, if the waypoints are closer together the vehicle will tend to drive more slowly. A slower speed also reduces accelerations so the corners will be sharper because SCurves makes the corners as sharp as possible within the acceleration limits of the vehicle which are set by WP_ACCEL or ATC_ACCEL_MAX.
Because the vehicle can do pivot turns well and can also drive in straight lines well, I’m surprised it can’t do slower turns well because, to me, this seems like a middle ground between pivots and straight lines. My only guess is that this is hitting some non-linear response in the motors which appears at low speeds.
Maybe it would be good to go back and check the motor/esc deadzones.
Another random guess is it might be good to reduce some of the speed or steering filter settings. In particular the ATC_SPEED_FLTE could be lowered from 10 to perhaps 2 to reduce responsiveness.
Thanks. I’ll experiment with these changes. We are driving our motors over CAN (not PWM), and the traction motor controllers work quite well at low speeds, down to 0 RPM. The motor controllers are configured with some ramp rate limitations which might be impacting the rover making sharp turns. Do you know if S-Curves constrains path planning to ATC_STR_RAT_MAX (i.e. will S-Curves reduce the sharpness of a planned curve if the curve would exceed ATC_STR_RAT_MAX?). Same question for MOT_SLEWRATE… do you know if S-Curves constrains path planning to stay within MOT_SLEWRATE?
ooh, a very wise question. The answer sadly is “no”. The SCurves path planning only has inputs for starting and ending 3D position, max speed, max acceleration and max jerk. The max turn rate (ATC_STR_RAT_MAX) can be converted to a max acceleration given a speed but the speed of the vehicle changes along the path so it’s tricky and we don’t do that. I think we’d need to modify the SCurves calculation itself to take that as a new input.
In it’s defense though, the older L1 navigation controller that it replaced took even fewer inputs.