Orbit approach with a line trajectory library #12664
Conversation
|
@MaEtUgR When this is done, sounds like we might need some more docs; note that I don't fully understand what the change is. It sounds like the vehicle will follow the same path for orbit as before, but just change the way that it accel/decelerates to start the orbit. Docs to consider are http://docs.px4.io/master/en/flight_modes/orbit.html . Depending on how generic this is/what the options are, we might need to create some docs a bit like http://docs.px4.io/master/en/config_mc/mc_slew_rate_type_trajectory.html |
MaEtUgR
force-pushed
the
orbit-approach
branch
from
af52a95 to
1d6f982
Compare
|
I
@hamishwillee Thanks for chiming in. The orbiting itself stays the same but when commanding a new orbit the vehicle approaches the circle in a more controlled less aggressive way on a straight line before starting to rotate. |
|
We just come from successful real-world testing with a big vehicle. The approach is now much more agreeable. I don't say it's perfect but it makes a big difference for the orbit user experience. Improvements of the |
Thanks @MaEtUgR Then IMO no docs are required :-) |
Before it was: - not used anywhere - copied from an old mission implementation version - didn't plan in advance - had a lot of broken cases - dependent on a lot of parameters I'm starting with a new relatively simple implementation that works as expected for a minimum viable implementation and can be improved over time. The first version is used to approach the circle path in Orbit mode to verify the interface and get testing such that it gets eventually used everywhere.
The initial approach to the circle to orbit on was very agressive since it was just the controller trying to stay on the circle reaching the limits. Now there's first an approach phase in which the vehicle reaches the circle trajeectory in a smooth perpendicular line before starting the orbit execution.
The condition that the vehicle is more than 3m away from the circle line was too sloppy. That often happens when the radius is changed by sticks. A reapproach is only necessary when the center is moved and that's only possible through the orbit command.
The yaw pointing towards the center makes sense since that's the approach direction anyways. But with the yaw feed forward results in a weird looking bias when not orbiting yet.
MaEtUgR
force-pushed
the
orbit-approach
branch
from
1d6f982 to
0f1c196
Compare
|
@RomanBapst Since we had review rounds in person, this is well tested, clearly much better than before and had no conflicts. I'm merging as soon as CI ran successfully. |
Describe problem solved by the proposed pull request
As requested by @RomanBapst I'm fixing the initial approach of the vehicle to the circle in orbit mode. This should vastly improve the user experience when using the Orbit mode.
Test data / coverage
SITL tested. @RomanBapst please submit your feedback on user experience.
Describe your preferred solution
The
StraightLinelibrary is supposed to implement a motion primitive to move the vehicle from point A to B on a planned trajectory such that this functionality can be reused where such setpoint generation is useful. The initial approach to the orbit circle is a very good example of such a use case and is now the first client code to test the interface of the library.The
StraightLineimplementation currently does a velocity ramp based on the progress measured in distance between the start and endpoint. It ramps up the velocity for half the way and down the second half. The velocity is then limited to the specified speed e.g. the cruise speed.Describe possible alternatives
The
StraightLineimplementation here is working but not yet optimal. The idea is to have a minimum viable implementation now to set a baseline that can be tested and built on. I would be very interested to bring in @bresch's jerk optimized planning to be reused in this form.