Will do tomorrow! Thanks.
1 Like
Randy, Sorry for the 3 day delay! I have had some exciting progress. 1. I spent time on my RTK GPS issue and found my problem (bug in my code in the LoRa module 
). I had been ignoring that and focusing on the steering issues but when I was in a waiting mode for parts to build a better actuator, I jumped back on that.
2. The most important for pivot turn issue: I was able to change the behavior of the Actuonix control board for the actuator and get it to work faster when near the PWM position setpoint. I could tell an immediate difference in the driveability of the mower in manual. It is much more like an RC car now in responsiveness - a little sluggish, but way better. So, I went back through the throttle/speed and then steering tuning procedures. Along the way, I set the ATC_ACCEL_MAX parameter to a lower value that seems more correct. Now I am able to have much more controlled pivot turns. I am just now beginning to experiment, but I am hopeful I can tune it.
I didnāt want you to start looking at logs when I was still making progress on my own and things were so fluid. I will be in touch, though, in a few days.
On another note, I cut some real grass yesterday and made a few video snippets. I will be posting them soon. The mower looked like it was being driven by a drunk man, but it got the job done. My motto is now āIt aināt perfect, but I aināt sweating!ā. I was operating in the house!
Just wanted to give an update since I said I would upload logs ātomorrowā!
1 Like
I may have a related issue. I have a skid steer rover that I am in the process of tuning (version 3.4.1 code). In my case my motors+drivers (12v wiper motors + BTS7960 dual half bridge) require 60% input before even starting to move the rover. From this point through to 100% they are quite responsive. Even setting MOT_THST_EXPO to +1 only brings down this threshold to approx 45%. I believe that this is causing quite some problems when it comes to tuning however, it also seems to highlight a possible issue with the skid steer controller. I have found that in acro mode (after tuning throttle and turning as best I can), if I have zero throttle and pivot turn on the spot, there seems to be some carry over of the left/right individual motor drive imbalance when I then attempt to apply the throttle to move forward in a straight line. Even if there is a significant delay between the turn input and the throttle input. In this case, instead of driving both wheels at the same speed, my rover continues to turn in the direction it was previously for up to 90 degrees before the slow wheel catches up - even though I have not given any turn input. I can see this effect also at waypoints where the rover rotates to the correct heading, pauses very briefly then starts moving forward while still turning only having to correct to get back on track. It appears that what ever the code is doing to calculate the differential speed between the left/right wheels during a pivot turn, carries over after the turn has stopped
I guess the 60% throttle required occurs in both forward and reverse directions? Or do the motors only spin in one direction? Our current skid-steering support really expects motors that can spin in both directions.
My initial thought is that it would be best to get better performing motors and/or motor drivers because any changes we do in software will just be masking an underlying hardware issue. In general itās best to get better hardware than the try and fix it in software.
It may be possible to get rid of some of the deadzone by increasing the THR_MIN value. It might also be good to provide a log showing the problems.
Hi Randy, yes the effect is the same in both directions. The rover can travel both forward and backward. Pivot turns are just that - the two wheel both spin at the same speed in opposite directions and the rover spins on the spot. Controlling the rover manually poses no problems. The issue of a large throttle dead zone aside, I believe that the behaviour it is exhibiting after turns is not intended?
The THR_MIN set to its max 20% has reduced the dead zone. With THR_MIN and MOT_THST_EXPO both set to max, the dead zone is now +/- 25%. I might have a look at increasing these limits in the code
Jiimovonz,
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.
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
1 Like
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 https://youtu.be/QkVo6L0TiCg.
1 Like
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: https://drive.google.com/file/d/1r89z4uEUjlAfoPGu99RFZbxKEsjISvrR/view
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.
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.
RoboBill
1 Like
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.
RoboBill,
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.
2 Likes
Kenny,
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.
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.
1 Like
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.
2 Likes
@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!
3 Likes
Kenny,
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.
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.
1 Like
Kenny : have you thought of making your own with wiper motors and a pot?
Very strong and fast
Doug