Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make speed changes during missions obey WPNAV_ACCEL #12821

Merged
merged 2 commits into from
Feb 21, 2020

Conversation

bnsgeyer
Copy link
Contributor

This PR is following up on what @ChristopherOlson did in PR #11068 which was closed for some reason. It fixes issue #11048. This PR is slightly different than Chris' PR in that it slews the WP speed both for increases in speed and decreases in speed.

Still uncertain why when the max XY accel is being passed to the position controller, it doesn't abide by that max accel parameter. This fixes the issue by slewing the wp speed changes passed to the position controller in accordance with the max wp accel.

@bnsgeyer
Copy link
Contributor Author

@rmackay9 and @peterbarker I have made the requested changes. I did my best to streamline the update wp speed function. I couldn't do a simple if (wp_desired_speed == wp_current_speed) because both variables are floats and the compiler chewed me out for comparing floats. So I put the else statement which I think works just as well.
Randy, do you need me to put a backport in for copter 4.0?

@peterbarker
Copy link
Contributor

peterbarker commented Nov 12, 2019 via email

@bnsgeyer
Copy link
Contributor Author

I knew there was a function like that. I tried iszero() and it looks like i got the syntax wrong. thanks for the tips!

@bnsgeyer
Copy link
Contributor Author

@rmackay9 and @peterbarker I made the requested change and sqaushed the changes. I don't understand why I am getting the error in CI.

@peterbarker
Copy link
Contributor

@bnsgeyer One failure was just travis failing to bring up a VM.

The second appears to be a result of recent sub tuning changes - that's going to be intermittent, sadly.

I've kicked both of them over.

@bnsgeyer
Copy link
Contributor Author

@peterbarker thanks for the help.
@rmackay9 all checks have passed. Ready for merging.

@rmackay9
Copy link
Contributor

rmackay9 commented Dec 3, 2019

as discussed on the dev call I'll review this..

@rmackay9
Copy link
Contributor

rmackay9 commented Dec 3, 2019

Looking pretty good but I think maybe we need to set _wp_current_speed_cms within wp_and_spline_init().

Here's the situation where I think it could go wrong:

  • upload a mission with a long-ish leg in it
  • param set WP_SPEED 200 (a low speed)
  • Loiter
  • arm throttle
  • rc 3 1500
  • let the vehicle fly for a bit until it's up to 2m/s
  • setspeed 50 (and let the vehicle get up to maybe 15m/s)
  • Loiter (and let the vehicle slow to a stop)
  • Auto

I think what we will see is the vehicle will speed up to something like 10m/s but then slow down again to 2m/s (the default speed).

We can discuss whether when the mission restarts it should go back to the default 2m/s or to the 50m/s but the way master works at the moment it will return to the default... but the way it is it initially climbs up to a high-ish speed and then returns to 2m/s which users will find confusing

@bnsgeyer
Copy link
Contributor Author

bnsgeyer commented Feb 5, 2020

@rmackay9 I have made a change that has it retain the desired speed once a mission is started. If the mission is stopped and then started again, it updates the current wp speed to the actual aircraft speed and it will accel to the desired speed. See what you think and I will take it to next weeks dev call if you are happy with that logic.

@bnsgeyer
Copy link
Contributor Author

bnsgeyer commented Feb 6, 2020

@rmackay9 not sure why I got an error with Travis CI. Any help would be appreciated.

@peterbarker
Copy link
Contributor

@bnsgeyer The Rover tests failing were just travis sucking.

The Copter test may be showing a regression.

The test appears to set the RTL_SPEED to 4m/s and ensure the vehicle sticks to that number. This has been a regression before - thus the explicit test for it :-)

My guess is you've failed to take into account that we have a separate speed when doing an RTL. Just guessing, haven't reviewed this PR :-)

You can run the test locally yourself:

./Tools/autotest/autotest.py build.ArduCopter fly.ArduCopter.RTLSpeed

@bnsgeyer
Copy link
Contributor Author

bnsgeyer commented Feb 7, 2020

@peterbarker and @rmackay9 So I have changed the logic to always set the wpnav speed to wp_speed_cms when it initializes. That seemed to make the autotest happy. I'm assuming that is how we want it to work. anyway, I also have the wpnav take the current speed and set the variable current speed variable in wpnav so it increases/decreases the speed to the desired at the specified accel. if you are happy with this, I will clean up the code and squash the commits.

@bnsgeyer
Copy link
Contributor Author

@lthall I have finished making changes and feel it is ready to be merged if you think this is the right approach.

Copy link
Contributor

@lthall lthall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all checks out and is ready to go in. Sorry for the delay!

// initialise the current wp speed to current speed along the track
const Vector3f &curr_vel = _inav.get_velocity();
// get speed along track (note: we convert vertical speed into horizontal speed equivalent)
_wp_current_speed_cms = curr_vel.x * _pos_delta_unit.x + curr_vel.y * _pos_delta_unit.y;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have a valid _pos_delta_unit at the time that wp_and_spline_init() is called so I think this is using the previous track to initialise the _wp_current_speed_cms...

@bnsgeyer
Copy link
Contributor Author

@rmackay9 check my latest commit. is this what you had in mind? I haven't tested it yet but i think this will behave how we want.

@rmackay9
Copy link
Contributor

rmackay9 commented Feb 19, 2020

@bnsgeyer,

I had a play around with this today and unfortunately my advice didn't work out well (not that the original solution didn't have problems either of course). I found that in a simple back-and-forth mission, as the vehicle came close to the next waypoint (within the leash length's distance of the waypoint) the vehicle would suddenly stop, then it would start again towards the waypoint.

I've rebased this PR on master and then added a couple of changes here: https://github.com/rmackay9/rmackay9-ardupilot/commits/bnsgeyer-obey-wpnav-accel

I think the approach in this new branch is correct but it includes a couple of changes that you may or may not like:

  • PosControl now accepts very small (less than 1cm/s) changes in the maximum speed. The 1cm minimum change requirement was apparently added 5years ago before we had the float::is_equal() method. This change does eat a bit of extra CPU though as we will recalculate the leash about 4000 times over a few seconds. The leash calculation is not that expensive however but perhaps we should discuss this with @lthall.
  • I've removed the "_wp_current_speed_cms" because I think it was always the same as the pos controller's maximum speed. My guess is that it was added to get around the issue mentioned above.
  • I've renamed, "_wp_desired_speed_cms" to "_wp_desired_speed_xy_cms" just to clarify that it's only meant for the xy axis and not z.

@bnsgeyer
Copy link
Contributor Author

bnsgeyer commented Feb 20, 2020

@rmackay9 the current waypoint speed was added to track the progression of the waypoint’s speed to the desired waypoint speed. I’ve never thought about tracking out through the position controllers max speed. I am a little concerned that if the position controller max speed is written by another caller then you could see the position controller violate the wp accel but I guess the wp library would catch it on the next loop. Otherwise I like this implementation. I will pull it into my branch and test it tonight. Thanks for the help!!

rmackay9 and others added 2 commits February 20, 2020 23:04
also small changes in max speed for z-axis
Includes commits by rmackay9
AC_WPNav: fixup max speed acceleration
AC_WPNav: simplify the initialisation of poscontrol's max speed
          Changed at Leonard's request to keep things simpler
@bnsgeyer
Copy link
Contributor Author

@rmackay9 I checked pulled your commits into my branch and did a quick check of the speed changes and moving in and out of auto. I think this will work fine. thanks for the assist. I rebased and squashed the commits.

@rmackay9 rmackay9 merged commit 593ff68 into ArduPilot:master Feb 21, 2020
@rmackay9
Copy link
Contributor

Merged, thanks!

@rmackay9
Copy link
Contributor

rmackay9 commented May 6, 2020

this is included in Copter-4.0.4-rc1

@bnsgeyer bnsgeyer deleted the pr-wpnav-obey-wpaccel branch March 30, 2022 02:58
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants