Servers by jDrones

Skid Steer Mower Overshooting pivot turns

(rmackay9) #106


The 20% limit on the THR_MIN is enforced here in the AP_MotorsUGV class so increasing that maximum to 60 might work.

It might be necessary to set the parameter from the MP’s Full Parameter List or Full Parameter Tree screen so that the ground station doesn’t try to enforce the 20% limit there as well. You probably already know this part though.

Sounds like you’re on your way to fixing this. Tell me if you have troubles compiling - I could compile up a binary for you if necessary.

(jimovonz) #107

Thanks Randy - I have it compiling now with an increased limit. I am sorry that I sort of hijacked this post but my original intention was only to highlight why my particular issue might help bring to light another problem. I will certainly test my setup with this reduced dead zone and expect that tuning will be more effective now but I believe that the issue of the rover turning unexpectedly when commanded to travel straight will still be there (i.e over shoot pivot turns). I can see no improvement in this issue after already reducing my dead zone from +/-60% down to +/- 25%. I appreciate that I may not be effectively describing what I am experiencing so I will attempt to demonstrate the issue with a log/video

(Kenny Trussell) #108

I think I hijacked it first! I can see how your problem could cause similar issues to mine - very relevant.

I wanted to post that I have uploaded a video of my mower actually cutting grass at

(jimovonz) #109

Kevin_Groba, please let me know if you would rather I posted my own topic…

Here is a graph showing the issue I have. This shows Ch1/3:In/Out as well as the heading of the Rover in Acro mode. It starts off with Ch1:In at full with the throttle at neutral commanding a pivot turn on the spot. The heading of the rover changes at a fairly linear rate during this period as expected. Ch1/3:Out both rise and fall together in unison during this period but of course are absolute values and in reality are in reverse directions due to the servo chanel output as per the motor config. After Ch1 returns to neutral, both Ch1/3:Out return to neutral and stay there for a period of no input where the rover is stationary. After this pause, the throttle (Ch3:In) is raised to full with the intention that the rover travels forward in a straight line (i.e no steering input per Ch1:In). This time CH1/3:Out are NOT in sync with an obvious difference in output levels which causes a continued rotation of the rover in the same direction as the initial stationary turn accumulating another 30+degrees of rotation while supposedly trying to travel forward straight. This is the same behaviour I see during a mission. The effect is the same after every pivot turn and the straight line deviation depends on the previous turn rotation direction.

Dataflash Log:

(rmackay9) #110

Hi Kenny,

nice video! The drunk man driving is something I’m sure we can sort out. I suspect some tuning of the navigation controller will help although i’m not yet an expert on what to do with that. We are getting close to the point where we need to rework the navigation controllers I think… but let’s see how far we can get with the existing ones before we do that.

(RoboBill) #111

Reworking the Nav Control?.. Oh my. but Oh YES Please! So allow me to dream here…

I’m wondering if it would be possible to develop a self tuning algorithm. With various types of centimeter accurate localization systems available today, I’m hoping the magic nav tuning system can be developed. Perhaps in the same way the compass offsets are somehow calculated.

(Now I’m really dreaming/wishing a lot here) I imagine that there would still be 3 basic tuning steps. 1) Various speed tests where the user could refine basic speeds, acceleration and deceleration parameters. 2) Steering tune mode with the user given a figure 8 pattern of known dimensions to Acro steer the rover. 3) Learn Auto Nav mode where the rover is given a simple square/rectangular pattern of know dimensions to travel. Based on the localization data, the Nav system parameters are auto-tuned to eliminate any wobble, reduce waypoint overshoot etc.

A now with some rovers like lawn mowers weighing in well over 300 LBS and 4 feet long and wide, I think that actual physical properties of the rover as parameters in the MP might be helpful.

Again I realize the enormity/complexity of what I I’m just dreaming.


(Kenny Trussell) #112

I am too new to these type of control loops to add much, but I will say that I wish all loops could be simple PID loops but I realize there could be reasons that does not work well. The advantage of PID is that it has been around for over a century and many methods for tuning have been developed (such as Ziegler–Nichols). I do like the cascade loop style with lower-level loops that can be tuned first (steering and throttle) and then the navigation loop built on top. Can the Nav loop be simple PID?

Is there a good description of how the NAV loop works now? I would like to understand better how NAVL1_PERIOD, NAVL1_DAMPING, NAVL1_XTRACK_I work. There are the brief descriptions in Mission Planner. I guess I could try to find the equations in the code. I have not looked.

(rmackay9) #113


Leonard and I have discussed writing an AutoTune mode for Rover so I’ve created an issue here. As you say, it’s a big job but hopefully we will get to it eventually.

(rmackay9) #114


This is the best description we have for Rover’s navigation contoller.

I can’t say whether the navigation controller could be rewritten to be a simpler PID controller but I’m sure the steering and throttle controllers wouldn’t work as well with the FF missing. It’s possible to make it drive with the FF set at zero but I think it will require a very large I term and the response will be slower.

For the steering the controller converts a turn-rate-to-steering-output controller and the FF works well. Perhaps if it was modified to be a turn-rate-to-change-in-steering-output the FF could be dropped but practically speaking, I don’t think there is any advantage to making that kind of change.

(Kevin Groba) #115

Kenny, sorry for the delay. I am uploading my param list if that would help. ParamsAsOf7-10.param (11.6 KB)
I see your video posted of it the rover actually mowing. My rover is very similar but just faster. I have cross track problems and major issues with the compass that happens about 10 minutes into the waypoint plan. It tracks well then the compass drifts for some reason. Mine goes fairly straight along a path with the attached settings. I worked on the decreasing the L1 nav period until the rover goes crazy then back off a little. Same thing with the NAVL1_XTRACK_I by increasing and decreasing til things go well.

(Kenny Trussell) #116

Thanks so much! I have made good improvements in mine over the last few days. I do appreciate the advice on the NAV L1 settings. I have worked on mine until late every night and then I am too tired to post anything. Lol. I have my mower going very slowly because I wanted to tune it for working in waist high weeds in some of my fields. Tonight I mowed probably 2 acres of such weeds. It was a joy to be behold. I had the survey grid set to 1 meter spacing but still had some skips due to tracking errors. I tuned the NAV L1 period and the dampening some and it helped. I will try your trick next time.

I think you said you were going to look into an RTK gps system. After a lot of trial and error, my ublox C94-M8P is working flawlessly. Using LoRa for the RTK communication is really great. Range is incredible. I’ll be glad to share details, code, etc., if you are interested.

(Kenny Trussell) #117

@rmackay9, you once said that if there were any enhancements to ArduRover that would help a mower application to let you know. It would be great for me if a gpio could be set to go high or low when the rover is outside a polygonal geofence. That could be used to kill the engine. I plan to attempt to do this with an arduino or something hanging on the MAVlink bus but it would be a nice feature to be built in imho. I have areas where the zero turn mower will be operating that if a steering actuator linkage broke (my biggest mechanical worry), the mower couldn’t hurt anyone but it could damage itself or drive off into a pond! Really, the chances of a runaway condition is probably small since if one actuator failed, the other would likely still be working and the mower would just go in circles forever. But, the geofence kill feature would be nice I think.

While I am wishing, what would be even better would be a master interlock or kill output that was configurable. If in Mission Planner you could have check boxes for various conditions that all have to be met for the interlock to be active it would be awesome.

I’m sure there are higher priorities but just thinking…

Thanks for all you do!

(rmackay9) #118


Great stuff. I was wondering how the petro motor was being controlled. How about if we controlled that part through ArduPilot as well? So you could start/stop the motor by arming/disarming the vehicle and it might make it easier to implement the vehicle stopping if it goes outside the fence.

Also you (and anyone else for that matter) should feel free to stick enhancement requests into the issues list. They get vetted by other devs too, addings labels, providing some feedback, etc. No pressure though.

(Kenny Trussell) #119

Thanks for the tip on the issues list. I will begin to use it.

I don’t usually arm until after I have the engine running. I guess I could arm prior to cranking if necessary. The signal I would like from the APM would only give a shut-down signal when we were in Auto and were outside the geofence. So, I’m not sure the arm signal would work. I think I will normally load waypoints and a geofence for a particular area to be mowed while the mower is still in the shop (outside the geofence). I will drive it in manual, steering or guided mode to the field. Then I will change to Auto.

Since I have a kill switch that is independent of the PixHawk, I would kill the machine if it went haywire in any mode that I was controlling directly. I am only interested in an unattended shutdown when it is in Auto.

I will post some version of these thoughts on the issues list for consideration.

(doug Wright) #120

Kenny : have you thought of making your own with wiper motors and a pot?
Very strong and fast

(Kenny Trussell) #121

@dwright361 Doug, I have bought a lead screws and electric screwdrivers and 10-turn pots to make my own. At the moment, after I connected a USB cable to the control board for the linear actuators I have and made a change to the parameters, it is much improved as far as drive-ability, so I am just using those. I expect them to fail at some point. I will be able to testify to their worthiness I guess when that happens. So far, so good.

(doug Wright) #122

Kenny: That is Good. I envy your progress. I am just starting and I am havig issues but am working through them. My mower is much simpler and smaller than the ones you and the others are using.
Wish me luck.

30 inch single blade 19.5 Hp 2 cyl B/S engine.
drives are 2x60 Sabertooth controller with a couple of 24volt wheelchair motors
Radiolink AT 10 TRx and a Radiolink Pixhawk Clone.

(Kenny Trussell) #123

That is very nice looking. I would be very interested in understanding the details of your design: motor type, etc. If you decide to post additional info on Youtube, here, or anywhere, please let me know! If I can help in any way, don’t hesitate to ask. I plan to post more videos. I have been sidetracked with a sprinkler system install for a couple of weeks and haven’t done much with my mower. I’m itching to get it back in service with the newest release of Ardurover. It promises to have improved Pivot Turns which should be great.
Wishing you luck! It was a HUGE amount of work for me, but worth it, so don’t get discouraged! Folks on this forum are amazingly helpful.

(doug Wright) #124

Thanks Kenny.
I am using RadioLink equipment but having transmitter to receiver calibration issues in ardurover software. Can get connection right now. I posted pictures and description on the forum a few days ago.

(doug Wright) #125

Kenny: Here are two examples of building high torque actuators .