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

VTOL improved RTH #1054

Merged
merged 50 commits into from Feb 2, 2014

Conversation

Projects
None yet
3 participants
@peabody124
Contributor

peabody124 commented Dec 21, 2013

This begins implementing a framework where there are FSMs
defined to achieve certain goals (e.g. fly to location and
land), which provides a layer of indirection between the
PathDesired UAVO and the actual navigation.

This is used to improve RTH so that it initially hovers, then ascends
to a minimum altitude, flies home, hovers, then lands at the home
location.

Here is a demo of doing RTH https://vimeo.com/79603584

It also adds a loiter mode to the VTOL follower. Using this you can
use pitch and roll to move the setpoint while holding.

@guilhermito

This comment has been minimized.

Show comment
Hide comment
@guilhermito

guilhermito Jan 3, 2014

Contributor

This looks good to me

Contributor

guilhermito commented Jan 3, 2014

This looks good to me

@peabody124

This comment has been minimized.

Show comment
Hide comment
@peabody124

peabody124 Jan 5, 2014

Contributor

Here is some video from testing it today
https://vimeo.com/83416006

Contributor

peabody124 commented Jan 5, 2014

Here is some video from testing it today
https://vimeo.com/83416006

@peabody124

This comment has been minimized.

Show comment
Hide comment
@peabody124

peabody124 Jan 11, 2014

Contributor

jenkins: test this please

Contributor

peabody124 commented Jan 11, 2014

jenkins: test this please

@peabody124

This comment has been minimized.

Show comment
Hide comment
Contributor

peabody124 commented Jan 18, 2014

@@ -41,7 +41,7 @@ struct path_status {
float path_direction[2];

This comment has been minimized.

@lilvinz

lilvinz Jan 25, 2014

Contributor

Update file headers

@lilvinz

lilvinz Jan 25, 2014

Contributor

Update file headers

@@ -40,10 +40,14 @@
#include "pathdesired.h"

This comment has been minimized.

@lilvinz

lilvinz Jan 25, 2014

Contributor

Update file header, i won't repeat that for every file.

@lilvinz

lilvinz Jan 25, 2014

Contributor

Update file header, i won't repeat that for every file.

@peabody124

This comment has been minimized.

Show comment
Hide comment
@peabody124

peabody124 Jan 27, 2014

Contributor

More demo video with the path smoothing https://vimeo.com/85122181

Contributor

peabody124 commented Jan 27, 2014

More demo video with the path smoothing https://vimeo.com/85122181

@@ -417,10 +423,9 @@ int32_t transmitter_control_select(bool reset_controller)
altitude_hold_desired(&cmd, lastFlightMode != flightStatus.FlightMode);
break;
case FLIGHTSTATUS_FLIGHTMODE_POSITIONHOLD:
update_path_desired(&cmd, lastFlightMode != flightStatus.FlightMode, false);

This comment has been minimized.

@lilvinz

lilvinz Feb 2, 2014

Contributor

Just a thought: By delegating things to the path planner, does a sanity check have to be extended for the path planner module to be running?

@lilvinz

lilvinz Feb 2, 2014

Contributor

Just a thought: By delegating things to the path planner, does a sanity check have to be extended for the path planner module to be running?

This comment has been minimized.

@peabody124
@peabody124
{
set_manual_control_error(SYSTEMALARMS_MANUALCONTROL_ALTITUDEHOLD);
const float CMD_THRESHOLD = 0.5f;

This comment has been minimized.

@lilvinz

lilvinz Feb 2, 2014

Contributor

Maybe add a comment here that this may never be 1.0f because of division by zero.

@lilvinz

lilvinz Feb 2, 2014

Contributor

Maybe add a comment here that this may never be 1.0f because of division by zero.

-guidanceSettings.HorizontalVelMax, guidanceSettings.HorizontalVelMax, dT);
// Limit the maximum velocity any direction (not north and east separately)
float total_vel = sqrtf(powf(northCommand,2) + powf(eastCommand,2));

This comment has been minimized.

@lilvinz

lilvinz Feb 2, 2014

Contributor

add whitespace

@lilvinz

lilvinz Feb 2, 2014

Contributor

add whitespace

peabody124 added some commits Nov 19, 2013

VTOLPath: enable the PathPlanner functionality
This isn't the most elegant code. When the PathPlanner is enabled
as a flight mode, the follower FSM enters a state that constantly
checks for the latest value of PathDesired and tries to follow it.

The PathPlanner entirely takes care of setting that PathDesired
value, which means that the PathPlanner cannot utilize any of the
sequencing abilities of the PathFollower. In the future it might
be good to add a "Goal" field to the PathDesired which is then
either interpreted as _input_ to the Follower when in path following
mode or set when the PathFollower is being configured by itself (e.g.
when a flight mode is triggering it to run).

So basically there should be a better distinction between exogenous
input (path following) and internally generated input (flight modes
that trigger follower).
VTOLPath: zero the feedforward accel component
This was creating a lot of jitter
Transmitter: add a loiter command and set it
The defaults and max loiter speed are currently hardcoded.

Conflicts:
	flight/targets/flyingf3/fw/UAVObjects.inc
VtolFollower: leash how far we can loiter
Similar to the model in ardupilot, we can only
move the setpoint a certain distance from the current
location to avoid too much windup.
VtolFollower: allow moving loiter target closer
Now if the updated target is closer to the current position
or within the leash radius, allow moving it.
VtolPath: add ascend stage to RTH
Now it will hold at the current altitude for 10 seconds
before climibing to the minimum altitude.
Transmitter: do not enable loiter for CC
Don't initialize the loiter UAVO on CC given that we
cannot use it anyway.
ManualControl: disable LoiterCommand for BGC
Switched to including the complex code whenever GIMBAL
and COPTERCONTROL are not defined. We should probably
go through and remove the few remaining instances of
the REVOLUTION flag in the code as it is no longer
necessary.
VtolPathFollower: support landing in paths
This makes do_path method is now aware of the particular mode for
the current waypoint and can call other methods such as landing.
VtolFollower: landing should stay INPROGRESS
Since landing only makes sense as the last element in
a flight plan there is no sense in setting it complete
hitting the landing location.
VtolFollower: add ability to point heading along path
This looks forward in the direction of the path, provided
the desired velocity is greater than 1 m/s. This should
prevent too much spinning around while hovering. However,
the MaximumRate for Yaw needs to be set to something
reasonable where hitting full stick isn't a problem.
VtolPathFollower: if cannot control this frame set critical error
Having this a warning is unsafe as this condition will result in
no follower. They should definitely not be taking off like this.
VtolPathFollower: use the Altitude Hold control values
This consolidates the parameters (and algorithm) for altitude
hold so that tuning the altitude hold by itself will also tune
the algorithm used during navigation.
PathPlanner: fix definition of activateWaypoint
Strange the compiler was not complaining about this.
GCS: remove old WaypointEditor plugin
The PathPlanner provides its own widget and replaces
this.
VtolPathFollower: optional feedforward accel compensation
When the velocity desired changes, the acceleration required to
achieve this is computed and added as a feeforward component.
This compensation is optional.

peabody124 added a commit that referenced this pull request Feb 2, 2014

@peabody124 peabody124 merged commit a6ecefe into TauLabs:next Feb 2, 2014

1 check passed

default Merged build finished.
Details

@peabody124 peabody124 deleted the peabody124:rth branch Feb 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment