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

launch: add launch specific idle throttle param #9471

Closed
wants to merge 4 commits into from

Conversation

tstastny
Copy link

@tstastny tstastny commented May 16, 2018

Depending on the platform, fixed-wing hand launches may require non-zero idle throttle while "in hand" and getting a running start (e.g. to push more prop-wash over the control surfaces while running slower than the stall speed). This conflicts with the idle throttle setting engaged after land detection, which, in this case, would then keep idling the motor at that same non-zero value, when for e.g. belly landings this is not desirable (should be set to zero).

This pr adds a pre-takeoff idle throttle for catapult (or hand launch) methods, which differs from the idle throttle set after land detection. It is only active until motors are enabled by the launch detection -- which then as before initiates climb out.

Current implementation seems to work testing outside on the bench. But maybe there are some recommendations on how better to structure the changes in the fw pos ctrl cpp, @dagar ?

@Antiheavy
Copy link
Contributor

@tstastny I'm just curious, do you plan to use this for a hand launched airplane? I definitely agree that throttle during hand launch motion can be critical to hand launch success (our plane is this way), but we use LaunchDetection to start the motor by shaking the vehicle to trip the accelerator, then throw. Do you have a button or something on the vehicle to arm and start the motor?

@tstastny
Copy link
Author

@Antiheavy Yes - we are hand launching. No button currently, we actually had this implemented in an older custom firmware we were using - but at the moment we just flip the switch to auto mode to start the launch detection (and simultaneously the "idle throttle" -- here replaced with a "pre-launch throttle"). Then, exceeding the x-body acceleration threshold triggers full throttle when throwing.

I wouldn't be opposed to an extra launch detection "start" button, just one more layer of safety after flipping to auto. Though I don't know if it is completely necessary in this case.

The new idle throttle however handles the case that full throttle is too much to handle while standing or beginning to run. (I actually have a couple of scars on one hand from a time when I did not properly coordinate with the pilot when it was ok to put full throttle during a hand launch). So shake and throw with full throttle ("motors enabled" in the launch module) is not always an option.

@Antiheavy
Copy link
Contributor

neat. Hand launch controller and vehicle design is harder than most people think. best of luck.

@@ -418,7 +418,7 @@ class FixedwingPositionControl final : public ModuleBase<FixedwingPositionContro
bool control_position(const Vector2f &curr_pos, const Vector2f &ground_speed, const position_setpoint_s &pos_sp_prev,
const position_setpoint_s &pos_sp_curr);
void control_takeoff(const Vector2f &curr_pos, const Vector2f &ground_speed, const position_setpoint_s &pos_sp_prev,
const position_setpoint_s &pos_sp_curr);
const position_setpoint_s &pos_sp_curr, float &pre_takeoff_throttle);
Copy link
Member

Choose a reason for hiding this comment

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

I might not be following this correctly, but why do we need to pass this through to the takeoff routine?

Copy link
Author

Choose a reason for hiding this comment

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

Good point. I'm not sure what my original thought process was there. -- will change it and just call the throttle idle get from launch detection whenever it's needed.

@dagar dagar added this to the Release v1.8.0 milestone May 23, 2018
@philipoe
Copy link
Contributor

philipoe commented Jun 6, 2018

@dagar @tstastny Update? Is this good to merge given that all review comments were addressed?

@philipoe
Copy link
Contributor

@dagar Can we merge, given that checks have passed and this was foreseen for Release 1.8.0 originally?

@dagar
Copy link
Member

dagar commented Jul 3, 2018

Would you be able to share a log showing this working?

@@ -1060,7 +1060,7 @@ FixedwingPositionControl::control_position(const Vector2f &curr_pos, const Vecto
/* making sure again that the correct thrust is used,
* without depending on library calls for safety reasons.
the pre-takeoff throttle and the idle throttle normally map to the same parameter. */
_att_sp.thrust = _parameters.throttle_idle;
_att_sp.thrust = _launchDetector.getThrottleIdle(_parameters.throttle_idle);
Copy link
Member

Choose a reason for hiding this comment

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

Typically the pattern here is to pass the value you'd use in the non-launch detection case, and launch detector would return one or the other depending on if it's enabled.

Copy link
Author

Choose a reason for hiding this comment

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

I believe this is what is happening. Or do I miss something? (at least this is what I intended)

LaunchDetector.cpp#L128

Copy link
Member

Choose a reason for hiding this comment

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

My mistake, that looks correct.

@tstastny tstastny force-pushed the pr-pre_launch_throttle_idle branch from 76d50d6 to 45e1234 Compare July 3, 2018 20:03
@tstastny
Copy link
Author

tstastny commented Jul 3, 2018

the merits for and against forcing LandDector into the Landed state while Launch Detection is running

@Antiheavy right -- this was actually something we just found tonight testing in HIL -- will check if this fix works tomorrow morning, but it seems like quite a few corner cases with the landing state. hopefully this commit works, but of course there are probably other (possibly better) ways to handle this more generally.

@philipoe
Copy link
Contributor

philipoe commented Jul 4, 2018

@dagar @tstastny Log file of this being tested in HIL is here : https://review.px4.io/plot_app?log=0fce0257-dcf2-4982-9777-a612fb2ff807 . Note that this file includes two autolaunches and two autolands!

Settings were:

  • LAUN_THR_IDLE = 0.7
  • FW_THR_IDLE = 2% (just to see the difference to zero percent)
  • FW_THR_MAX = 100%
  • FW_THR_LND_MAX = 0%

In the screenshot below you can see that at t~49:40 the launch throttle is activated, then after the launch was detected the max throttle is activated. During the landing at ca. 55:30, FW_THR_LND_MAX is first activated, and then afterwards after land detector has detected the landing the FW_THR_IDLE is set.

image

@tstastny tstastny force-pushed the pr-pre_launch_throttle_idle branch from 927ced9 to d47de30 Compare July 10, 2018 15:09
@tstastny tstastny changed the title launch: add launch specific idle throttle param [WIP] launch: add launch specific idle throttle param Jul 10, 2018
@tstastny tstastny force-pushed the pr-pre_launch_throttle_idle branch from d47de30 to ed4a6dd Compare July 10, 2018 20:53
@tstastny
Copy link
Author

tstastny commented Jul 10, 2018

missed (didnt add locally) the latter part of the last commit before the last push -- now works as advertised. see https://review.px4.io/plot_app?log=02bd7a15-762f-4118-997b-1b468cce2391 for HITL sim

@philipoe @dagar

@tstastny tstastny changed the title [WIP] launch: add launch specific idle throttle param launch: add launch specific idle throttle param Jul 10, 2018
_control_mode.flag_control_altitude_enabled));
bool in_air_alt_control = ((!_vehicle_land_detected.landed ||
(_launch_detection_state == LAUNCHDETECTION_RES_DETECTED_ENABLEMOTORS
&& mode == tecs_status_s::TECS_MODE_TAKEOFF))
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 a mouthful, should we have a helper function? Same logic could be used for run_tecs above?

Copy link
Author

Choose a reason for hiding this comment

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

e.g. just an extra bool calculated directly above?

bool is_launching = _launch_detection_state == LAUNCHDETECTION_RES_DETECTED_ENABLEMOTORS && mode == tecs_status_s::TECS_MODE_TAKEOFF;
bool in_air_alt_control = !_vehicle_land_detected.landed || is_launching;

or do you mean an encapsulated function call?

bool in_air_alt_control = !_vehicle_land_detected.landed || is_launching();

Copy link
Contributor

Choose a reason for hiding this comment

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

The first one is good, I'd say.

@dagar
Copy link
Member

dagar commented Jul 16, 2018

Instead of completely disregarding land detect in takeoff after launch detect what if we gave it a small window of a few seconds? At that point if there's not a successful transition to flying the land detector would kill the throttle again and the vehicle could even auto disarm. I'm thinking of various failed launch scenarios.

@tstastny
Copy link
Author

Instead of completely disregarding land detect in takeoff after launch detect what if we gave it a small window of a few seconds? At that point if there's not a successful transition to flying the land detector would kill the throttle again and the vehicle could even auto disarm. I'm thinking of various failed launch scenarios.

Sure, it is a valid concern. We actually used to have an additional launch detection initialization command on QGC (a button) on our custom firmware that did something similar. Basically you could switch to auto, but still needed to hit the button to start launch detection (simultaneously spooling up the motors and then ignoring land detection). This could then be coupled with a timeout as you say.

Is there an existing mavlink command that is best used for this purpose? maybe this one: https://mavlink.io/en/messages/common.html#MAV_CMD_NAV_TAKEOFF ? I guess this would require some QGC work as well. Otherwise one would need to flip out of auto and back in to reinitialize the launch detection after a land was detected.

@philipoe
Copy link
Contributor

@dagar @tstastny Update? How shall we proceed here?

@Antiheavy
Copy link
Contributor

A short timer for disabling land detection seems like it might work. I can’t think of a better solution. When would the timer start? Immediately upon LaunchDetect?

We’ve also seen bad effects of LandDetector switching in and out of Landed state during ground handling and leading up to LaunchDetect. I worry about future problems there.

@priseborough
Copy link
Contributor

The linked issue
#10076 indicates that we either need to start running the TECS internal updates when launch is detected rather than wait for onGround to go false, or set pitch angle demand to the min climbout value until onGround goes true.

@fredowski
Copy link
Contributor

Just to support the idea of the launch idle throttle: We use the idle throttle for a hand launch of the X-UAV Mini Talon. Without the idle throttle the switch to 100% throttle via the accelerometer was too late and the launch did not succeed. We did not even think what happens when we land cause we were so happy that the launch worked... We activated the idle throttle (approx. 50%) by switching to mission mode. But of course the throttle should be 0% after landing...

@stale
Copy link

stale bot commented Jan 20, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@Antiheavy
Copy link
Contributor

This improvement still seems worthwhile. Of particular interest to me is the portion that addresses landDetector problems in pre-flight and hand launch.

@stale
Copy link

stale bot commented Jul 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale
Copy link

stale bot commented Oct 13, 2019

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

@LorenzMeier
Copy link
Member

Thanks for your earlier contribution. Unfortunately as the project has overall evolved quite a bit, this change doesn't apply any more. Closing stale pull requests like this one is part of us working aggressively to bring down the PR review time so that we will be able to merge or reject PRs in the future in a much more timely fashion.

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.

8 participants