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

Orbit: Adding orbit yaw behaviours #13426

Merged
merged 3 commits into from
Jul 13, 2020

Conversation

dayjaby
Copy link
Contributor

@dayjaby dayjaby commented Nov 11, 2019

Describe problem solved by this pull request
Implementing the yaw behaviours for orbit flight mode according the current mavlink specification (https://mavlink.io/en/messages/common.html#MAV_CMD_DO_ORBIT) and an additional yaw behaviour as suggested in mavlink/mavlink#1266. This new addition is important if you have a fpv camera installed in the front of the drone and expect the drone to always look forward.

Describe your solution

  • For yaw behaviour equals 0, we keep looking at the centre, like the code did before in all cases.
  • For 1, we do a yaw setpoint to the heading that we had in the beginning of the flight task.
  • For 2, we do no yaw setpoint.
  • For 3, we have the yaw setpoint looking always forward.

Test data / coverage
Tested via QGC (without parameter 3 being set) and via mavros (https://logs.px4.io/plot_app?log=7725a2a3-5af4-4710-a6a6-dbba12f5dd20):
rosservice call /mavros/cmd/command "{broadcast: false, command: 34, confirmation: 0, param1: 50.0, param2: 5.0, param3: 3.0, param4: 0.0, param5: 47.3977449, param6: 8.5465953, param7: 2.5}"

@TSC21 Thank you for your help with the implementation!

TSC21
TSC21 previously approved these changes Nov 11, 2019
@TSC21
Copy link
Member

TSC21 commented Nov 11, 2019

This new addition is important if you have a fpv camera installed in the front of the drone and expect the drone to always look forward.

Also relevant to combine with obstacle avoidance when one has a forward facing sensor and wants to safely execute an orbit around a certain position.

Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

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

Nice! Thanks for looking into it.
I hope my review comments make sense to you. If you're tired of them I can also put a commit somewhere with my suggestion and you check it.

src/lib/FlightTasks/tasks/Orbit/FlightTaskOrbit.cpp Outdated Show resolved Hide resolved
src/lib/FlightTasks/tasks/Orbit/FlightTaskOrbit.cpp Outdated Show resolved Hide resolved
src/lib/FlightTasks/tasks/Orbit/FlightTaskOrbit.cpp Outdated Show resolved Hide resolved
src/lib/FlightTasks/tasks/Orbit/FlightTaskOrbit.cpp Outdated Show resolved Hide resolved
src/lib/FlightTasks/tasks/Orbit/FlightTaskOrbit.hpp Outdated Show resolved Hide resolved
@dayjaby
Copy link
Contributor Author

dayjaby commented Nov 14, 2019

@MaEtUgR Following your advice, please have a look at the most recent commit. I restructured the code a little and created an enum.

Btw, does it make sense to do a setpoint for yawspeed and yaw at the same time?

@TSC21 TSC21 requested a review from MaEtUgR November 18, 2019 23:00
msg/orbit_status.msg Show resolved Hide resolved
@TSC21
Copy link
Member

TSC21 commented Nov 19, 2019

@dayjaby can you rebase on master? git pull --rebase https://github.com/PX4/Firmware.git master

@dayjaby
Copy link
Contributor Author

dayjaby commented Nov 20, 2019

@TSC21 Done. Thanks for the command ;)

@TSC21
Copy link
Member

TSC21 commented Nov 20, 2019

@TSC21 Done. Thanks for the command ;)

Neat! Now it appears without any conflicts :)

@TSC21
Copy link
Member

TSC21 commented Nov 20, 2019

@MaEtUgR all good here for you?

TSC21
TSC21 previously approved these changes Nov 20, 2019
@@ -104,6 +105,10 @@ class FlightTaskOrbit : public FlightTaskManualAltitudeSmooth
const float _velocity_max = 10.f;
const float _acceleration_max = 2.f;

int _yaw_behaviour =
orbit_status_s::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TO_CIRCLE_CENTER; /**< yaw behaviour during the orbit flight according to MAVLink's ORBIT_YAW_BEHAVIOUR enum */
float _initial_heading = 0.f; /**< the heading of the drone when the orbit command was issued */
Copy link
Member

Choose a reason for hiding this comment

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

@dayjaby this is actually the heading of the vehicle when the vehicle command DO_ORBIT gets processed, or when we can say when the MAV_CMD_DO_ORBIT is received and processed in the flight controller.

Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

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

Hey @dayjaby looks a lot better with the enumerated behaviors 👍 Sorry for the remaining complaints but I'd like to keep this clean and since I have to maintain it also according to how it was designed. I really appreciate your implementation of the yaw modes and could help you directly with code suggestions. Just let me know.

@@ -224,5 +231,37 @@ void FlightTaskOrbit::generate_circle_setpoints(Vector2f center_to_position)
_position_setpoint(0) = _position_setpoint(1) = NAN;

// yawspeed feed-forward because we know the necessary angular rate
_yawspeed_setpoint = _v / _r;
_yawspeed_setpoint = NAN; //_v / _r;
Copy link
Member

Choose a reason for hiding this comment

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

Please don't leave commented out code

Comment on lines 247 to 258
case orbit_status_s::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE:
if (_r > 0) {
_yaw_setpoint = atan2f(center_to_position(1), center_to_position(0)) + M_PI_F / 2.f;

} else {
_yaw_setpoint = atan2f(center_to_position(1), center_to_position(0)) - M_PI_F / 2.f;
}

break;

case orbit_status_s::ORBIT_YAW_BEHAVIOUR_RC_CONTROLLED:
Copy link
Member

Choose a reason for hiding this comment

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

For the front tangential and front to center yaw behavior you want a yawspeed feed forward which was there before and is now commented out otherwise the tracking performance in real world scenarios significantly degrades.


// make vehicle front always point towards the center
_yaw_setpoint = atan2f(center_to_position(1), center_to_position(0)) + M_PI_F;
if (start_to_circle.norm() < 0.5f) {
Copy link
Member

Choose a reason for hiding this comment

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

This is overriding the logic of the motion primitive StraightLine _circle_approach_line. I can only guess that according to your taste the approach takes too much time to slow down at the end. But then it's the fault of the StraightLine implementation which we want to fill with the jerk optimized trajectory generation anyways very soon and we should not interfere with its operation locally here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added that not because the slow down took too much time, but because switching from one orbit command to another orbit command made the drone brake down (same orbit center, same radius, but different yaw behaviour). But thinking about it now, this braking down seems reasonable.

_yawspeed_setpoint = _v / _r;
_yawspeed_setpoint = NAN; //_v / _r;

switch (_yaw_behaviour) {
Copy link
Member

Choose a reason for hiding this comment

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

I was asking to put this logic in its own function. Now it's not in the main update anymore but just uses another already existing one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is generate_circle_setpoints not the proper place? Or do you prefer an additional generate_circle_yaw_setpoints function?

@dayjaby dayjaby force-pushed the adding_orbit_yaw_behaviours branch 3 times, most recently from 7152c5f to e454e34 Compare November 27, 2019 04:59
@dayjaby
Copy link
Contributor Author

dayjaby commented Nov 27, 2019

Rebased and addressed your comments @MaEtUgR . Thanks for your help with this!

@stale
Copy link

stale bot commented Feb 27, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Feb 27, 2020
@TSC21
Copy link
Member

TSC21 commented Apr 4, 2020

@dayjaby can you do a last rebase on this? @MaEtUgR maybe a last review as well?

@stale stale bot removed the stale label Apr 4, 2020
@TSC21 TSC21 requested a review from MaEtUgR April 4, 2020 17:13
For the RC controlled yaw behaviour, we do a yaw setpoint according to
the stick expo. The uncontrolled yaw behaviour behaves undefined.
Switching between yaw behaviours makes the drone stand still for a
moment, which probably can be improved.
@dayjaby dayjaby force-pushed the adding_orbit_yaw_behaviours branch from e454e34 to f92f168 Compare April 5, 2020 08:02
@dayjaby
Copy link
Contributor Author

dayjaby commented Apr 5, 2020

@dayjaby can you do a last rebase on this? @MaEtUgR maybe a last review as well?

Done, no conflicts on rebase.

@stale
Copy link

stale bot commented Jul 4, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@MaEtUgR
Copy link
Member

MaEtUgR commented Jul 13, 2020

@dayjaby Hey, thanks a lot for your contribution and patience! I'm so sorry for the slow follow up! I finally went through it in all detail and have some suggestions that I pushed on top here: https://github.com/PX4/Firmware/compare/adding_orbit_yaw_behaviours
Let me know what you think. We can merge your changes first (even before #15292) and I can create a pull request for mine. This is for transparency.

Explanations:

  • If there is a line break in the Doxygen comment anyways we can put it before the declaration.
  • FlightTaskManualAltitude which orbit is inheriting from is already generating yaw setpoints from RC. I know this is confusing and the goal is to move this stuff into libraries such that you can just write "I want the yaw generation from RC" instead of silently inheriting.
  • Your way of calculating start_to_circle is much nicer 👍 I just moved it back into the local scope such that it's only calculated when used. Unrelated I also added some const qualifiers and switched the parameter structs to pass by reference.
  • As a suggestion, I set the initial heading for every new command that arrives which is probably what Orbit: Adding orbit yaw behaviours #13426 (comment) wanted to address. It's up to discussion. I thought if you ran any other yaw behavior first and then command the HOLD_INITIAL_HEADING it should hold what was there at the moment and not when orbit was first commanded. If HOLD_INITIAL_HEADING was already used then it should stay very close to the same yaw.
  • I simplified the HOLD_FRONT_TANGENT_TO_CIRCLE yaw setpoint generation using the sign() function and made it depend on the sign of the velocity and not the radius since inside the task for technical reasons the radius is always positive but the velocity changes sign for the opposite rotation direction.

@stale stale bot removed the stale label Jul 13, 2020
@dayjaby
Copy link
Contributor Author

dayjaby commented Jul 13, 2020

@MaEtUgR I agree with all your changes! Thanks for taking the time.

Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

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

Thanks for the feedback. Let's get it in 👍

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.

3 participants