-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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
Merge vtol mc motor handling methods #9028
Conversation
afc8174
to
84b39f6
Compare
Tiltrotor::set_rear_motor_state() needs review/rethinking. |
After code review this needs bench testing checking |
84b39f6
to
7f20813
Compare
@dagar I'll have a look at this today. |
@dagar Looks good so far. One thing that you could add is to move the set_rear_motor_state() method from the tiltrotor class to the vtol_type class and give it a different name like, e.g. set_motor_state(). Actually now that I think of it we can probably merge all those methods which fiddle with the pwm state of the outputs and use a bitmask (we also already have that for the tiltrotor) to differentiate between the motors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, see comment in conservation about merging with tiltrotor specific motor disable methods.
@dagar If you rebase I can test it on the tiltrotor and we can get it in. |
@dagar I'll take care of this tomorrow. |
7f20813
to
04c5ce7
Compare
Rebased, but still need to think about how tiltrotor is even supposed to function. Might need to keep VT_IDLE_PWM_MC after all. |
04c5ce7
to
a1bdaed
Compare
@dagar I went through this and noticed that there was a fundamental problem. The motors for tiltrotors and tailsitters where shut off in fixed wing flight which is ok for standard vtol but not for the former ones. I've reworked this according to the following requirements:
Proposed solution: which allows to modify the state of a selection of motors (via the parameter VT_FW_MOT_OFFID).
Solution: Important consideration: |
_flag_enable_mc_motors = false; | ||
// in back transition we need to start the MC motors again | ||
if (_motor_state != ENABLED) { | ||
_motor_state = set_motor_state(_motor_state, ENABLED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about passing the VT_FW_MOT_OFFID parameter as another argument here so that it become more clear that this methods sets the state of a motors selection.
I need to go through in detail, but this makes sense for now. We should have some more interesting options to consider once thrust is split x,y,z. |
2920dcd
to
5507d88
Compare
@dagar Could you give this a review please? I tested the behavior with my tiltrotor and it seems to work fine. |
CI failure is real, but otherwise looks good so far. This should work for now, but fundamentally it seems like at a lower level the system should already know which motors belong where. For the shared FW/MC motors in tiltrotor and tailsitter do we need different PWM limits in each state? |
@@ -337,18 +288,21 @@ void Tiltrotor::update_transition_state() | |||
int rear_value = (1.0f - time_since_trans_start / _params_tiltrotor.front_trans_dur_p2) * | |||
(PWM_DEFAULT_MAX - PWM_DEFAULT_MIN) + PWM_DEFAULT_MIN; | |||
|
|||
set_rear_motor_state(VALUE, rear_value); | |||
|
|||
_motor_state = set_motor_state(_motor_state, VALUE, rear_value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is kind of unfortunate, but I guess we should preserve the existing behaviour for now.
return ret == PX4_OK; | ||
} | ||
|
||
bool VtolType::set_idle_fw() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we do this with set_motor_state()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dagar The problem is that these are two different states which need to be tracked separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mainly wanted to share as much of the code that calls that IOCTLS as we could. At a glance it looks like you've done that now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dagar Yep, my last commit does that -only one method is used to do ioctl to the pwm output device.
@@ -263,5 +252,153 @@ void VtolType::check_quadchute_condition() | |||
} | |||
} | |||
} | |||
} | |||
|
|||
bool VtolType::set_idle_mc() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we do this with set_motor_state()?
7d10266
to
936503e
Compare
936503e
to
2613db5
Compare
@dagar I totally agree with you that it's not the best solution when the vtol attitude controller directly alters the pwm limits in order to achieve the desired behavior. |
@PX4/testflights Could you please test this on a standard VTOL? IMPORTANT Please first do a bench test as follows:
There should not be any difference in behavior compared to master. If you succeed with the bench tests I'd appreciate a test flight in which you transition from mc to fw a couple of times successively. |
2613db5
to
8022708
Compare
Flights with Falcon Vertigo Vtol, pixhawk 1 (V2) Good flights, no issues. |
8022708
to
8b46978
Compare
@dagar I tested this again on the tricopter including bailing out of transitions from both mc and fw. |
8b46978
to
cb49650
Compare
@dagar Could you please give this a review if you have some time? I'd like to get it in and it avoids lots of code duplication. |
Probably needs one more pass, but looks good. |
cb49650
to
939744c
Compare
Tested on the tiltrotor once more, no issues found |
939744c
to
f2da086
Compare
@dagar Could you have a look why CI fails, I don't understand it. |
- moved methods used to modify channel maximum pwm value to VtolType class so that the can be shared by the differnt vtol types Signed-off-by: Roman <[email protected]>
to VtolType class Signed-off-by: Roman <[email protected]>
Signed-off-by: Roman <[email protected]>
Signed-off-by: Roman <[email protected]>
Signed-off-by: Roman <[email protected]>
- board config can define PX4_PWM_ALTERNATE_RANGES which needs to be known by the compiler prior to processing this file Signed-off-by: Roman <[email protected]>
- created one method which has access to the pwm output device Signed-off-by: Roman <[email protected]>
Signed-off-by: Roman <[email protected]>
f2da086
to
cfa4d57
Compare
Rebased, please check CI again. |
Currently vtol standard disables MC motors by setting the max to PWM 950us, then re-enables them by setting it to 2000 us. PWM min is also overrides the min set in the interface. This PR changes that behaviour to use the configured PWM disarm value to disable the motors, and the set PWM max when re-enabling.
This was tested in a private branch a long time ago, and I tried to get it in with #8040, but it was never merged. As a result this needs to be carefully reviewed and tested from scratch.
With this in place we should be able to get rid of VT_IDLE_PWM_MC.