Why wouldn’t setting WP_RADIUS to a low value (though 0 might cause issues) make it not turn early? Or is it an issue with the fact that it is a zero turn and so when the front of the mower gets to the waypoint, it turns, which ends up being early?
To clarify the rover is not turning too early. The problem happens after reaching the waypoint and the rover performs a nice and controlled pivot turn that is within a few degrees heading of the following waypoint. The rover will pause for about half a second and then accelerate out of the pivot and turn in the same direction of the pivot. Sometimes up to 30 degrees and sometimes only a few. My issue could be configuration or mechanical. I feel like slowing the acceleration would correct the turning tendency.
The picture below shows what I think the issue is with the vehicle turning as it accelerates away from the last waypoint.
The blue line shows where the vehicle’s heading is after it completes the pivot turn - it’s pointing at the next waypoint. The problem is that it is not right on the line between the waypoints though so it immediately tries to get back on that line which means turning in some direction (red arrow).
This theory doesn’t totally fit with Kevin’s description because Kevin says, “turn in the same direction as the pivot” while the illustration below would lead to the vehicle turning in the opposite direction of the pivot.
Your theory could still fit if the rover is passing the waypoint from inertia instead of turning short of it. And in combination with the excess acceleration it makes sense as well with what I am seeing. The rover is aiming to get back on course but overshoots it with the aggressive acceleration. Were you able to find anything on the acceleration issue? To me by looking in the looks it just jumps to full output ignoring throttle slew rates and ATC_ACCEL_MAX.
Also, Randy feel free to use the video for the blog. Thanks again for all your help.
Watching the video, rmackay9 your graphic is fairly accurate.
except it appears to be overshooting and bouncing around the desired ground track. In some cases it is undershooting the turn and others overshooting. Then aggressively trying to get back on track, it overshoots.
Also in a few instances it is under turning. almost like a accelleration/decelleration factor isn’t high enough to get it moving during that instance.
I wonder if when it reaches the waypoint, and just then begins to stop, it will be overshooting the waypoint a few feet. Then when it starts moving again it hard turns to get back on the ground track.
Blue shows the actual track. Red shows the “come to stop” overshooting after the first waypoint is reached. Sorry not as pretty as @rmackay9’s artistry.
You’ve found another bug!
In your log there are indeed times where desired speed is immediately jumping from 0 to 1.6m/s. Sometimes it’s accelerating smoothly and sometimes it’s not. I’m pretty sure the issue is related to this bit of code in AR_AttitudeControl’s get_desired_speed_accel_limited.
If the speed controller hasn’t been run in a while, the desired speed is allowed to immediately jump to the new value. In these cases what we should do instead is limit the movement of the desired speed from the vehicle’s current speed.
I’ve raised an issue here.
EDIT: created a PR to fix the issue, probably will take a day or two to be reviewed, then we will push it out with Rover-3.3.1-rc3.
Not a bad graphic :-). Yes, you may be right about it overshooting the waypoint. It makes sense that would could it to turn in the other direction…
I’m curious can you provide the waypoint file so it can be compared with the path?
Looking at this from the dataflash, it clearly looks as though it is passing the waypoint before stopping, as clear by the ground track it eventually settles on between the two waypoints
Waypoint File is Here. I believe your are correct and it is overshooting waypoints. This is something I am also trying to get correct by setting the correct WP_Radius. I am struggling if the WP Radius in the mission plan or the WP Radius in the Nav Tunning takes is applied. Also, I believe but can confirm that I changed the WP_Radius in the mission plan to 1M prior to writing the plan to the AP.
Certainly a “simple” option might be too create a “slow down point” right before every turn point. That should reduce your overshooting. Not pretty. My assumption is the WP_Radius parameter is the default if it isn’t specifically called out in the mission. Probably with using that is, many factors are in play to how fast the mower stops. Grass height, speed, on a hill, etc
@Kevin_Groba I found X8r in your photo, do you use X8r receiver and mRobotic SiK radio together.
Thanks for the suggestions. I think there are some parameters that should slow the river as it approaches the waypoint but I am not sure. Using the insight about what is going on I plan on experiment with wp radius to try and get it to turn at the correct time.
Yes… But I am not sending any telemetry to the radio. Is there some reason they should not work together?
Thanks Kevin for your response.
Actually I do not know how to connect X8r and SiK radio together on Pixhawd 2.1,
I am using transmitter X7 with X8r that work fine, I also want to Guided mode via SiK radio to control rover on Mission Plan.
Can you tell me which port to connect to SiK radio?
I’m not as far along as Kevin in my project. Still picking out some systems, and mechanics to get what I’m looking for.
I am looking for someone to write some code. I’m not sure if there is some canned code for the basics or not.
I know nothing about code writing. I’m more of an application/systems guy.
I plugged it into telem 1 port.
I have not specifically tested but it should not overshoot the waypoint if the ATC_ACCEL_MAX parameter is set appropriately for the frame. What should happen is it should slow down before reaching the waypoint, then when it reaches it, it should slow to a stop, rotate and then once it’s pointing at the next waypoint it should begin accelerating towards it.
Looking at Kevin’s logs though it’s pretty clear that it’s not doing this. Ammarf from elab.co.jp (my main sponsor) has a new PR that allows settings a separate deceleration limit so I’ll likely give this a test in the simulator and make sure it works.
Great thread guys!
I’ve just finished “upgrading” a ZTM for a customer. Still having some issues with the servos that actuate the hydraulic drive pump valves, but that will be sorted shortly.
Now that I’ve seen this I’ll upload Rover-3.3.1-rc3 and re-test as I was having some of the issues mentioned here as well when testing the system the other week.
We’re also thinking of putting together a Cube carrier board specifically for zero-turn mowers with relays for; starter, ignition, fuel valve and PTO, and connections for RC receiver, telemetry and GPS. I think this would greatly simplify the setup of systems like this.