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

AP_Mount: update mount_open servo output to work for all backends #26944

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rohan-pandeyy
Copy link

@rohan-pandeyy rohan-pandeyy commented May 1, 2024


AP_Mount: update mount_open servo output should work for all backends Issue #26892

Changes:

New function in AP_Mount_Backend

  • Added a new protected function control_mount_open_servo() to the AP_Mount_Backend class which checks if the mount_open or mount2_open function is assigned and controls the corresponding servo based on the current mount mode.

Update Backend Update functions

  • Modified the update() function of each mount backend (e.g., AP_Mount_Servo) to call the control_mount_open_servo() function to ensure that the open/close servo is consistently controlled across all backend implementations.

Removed redundant code

  • Removed the code block in AP_Mount_Servo::update() that directly controlled the open servo using move_servo().

The SRV_Channel library had a mount_open and mount2_open functions but they were only used by the Mount_Servo backend.

Moved the little bit of code that controls to servo into a function in AP_Mount_Backend and then called it from every backend as part of the update() call.
@rohan-pandeyy rohan-pandeyy marked this pull request as draft May 1, 2024 13:01
@rmackay9
Copy link
Contributor

rmackay9 commented May 1, 2024

Hi @rohan-pandeyy,

Thanks very much for this change!

Could you modify the commit description to start with "AP_Mount: "? So change it to something like, "AP_Mount: update mount_open servo output to work for all backends"


// get the configured PWM values for open and closed states.
SRV_Channel *channel = SRV_Channels::srv_channel(open_chan);
if (!channel) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: could you change this to check vs nullptr? so something like, "if (channel != nullptr) {". I know they're equivalent so it's not a blocker.

uint16_t pwm_closed = channel->get_output_min();

// determine the desired open state based on the current mode.
bool mount_open = true;
Copy link
Contributor

@rmackay9 rmackay9 May 1, 2024

Choose a reason for hiding this comment

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

this section could be made more concise although it might not actually make the final flash size any smaller.

I wonder if you could put "const" before the local variables that won't change? e.g. "const uint16_t pwm_open = ..."

.. and also maybe use the terniary operator for mount_open similar to what was in the original code (but use true and false instead of "0" and "1" which really wasn't good in the original code).

Comment on lines +143 to +146
// move the servo to the appropriate position.
uint16_t target_pwm = mount_open ? pwm_open : pwm_closed;
SRV_Channels::move_servo(SRV_Channel::Aux_servo_function_t(open_chan),
target_pwm, pwm_closed, pwm_open);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// move the servo to the appropriate position.
uint16_t target_pwm = mount_open ? pwm_open : pwm_closed;
SRV_Channels::move_servo(SRV_Channel::Aux_servo_function_t(open_chan),
target_pwm, pwm_closed, pwm_open);
// move the servo to the appropriate position.
SRV_Channels::set_output_scaled(SRV_Channel::Aux_servo_function_t(open_chan), mount_open ? 1.0 : 0.0; );

Most of the function can be replaced with a set scaled. No need to get the individual output channel and mess about with PWM.

For the set scaled to work you just need to set the servo to a range output in the init somewhere:

SRV_Channels::set_range(SRV_Channel::k_mount_open, 1.0);
SRV_Channels::set_range(SRV_Channel::k_mount2_open, 1.0);

@rohan-pandeyy rohan-pandeyy changed the title update AP_Mount mount_open servo output to work for all backends AP_Mount: update mount_open servo output to work for all backends May 2, 2024
@rohan-pandeyy rohan-pandeyy deleted the update-AP_Mount-servo-output-to-work-for-all-backends branch May 2, 2024 03:54
@rohan-pandeyy rohan-pandeyy restored the update-AP_Mount-servo-output-to-work-for-all-backends branch May 2, 2024 03:56
@rohan-pandeyy rohan-pandeyy deleted the update-AP_Mount-servo-output-to-work-for-all-backends branch May 2, 2024 03:57
@rohan-pandeyy rohan-pandeyy restored the update-AP_Mount-servo-output-to-work-for-all-backends branch May 2, 2024 04:57
@rohan-pandeyy rohan-pandeyy reopened this May 2, 2024
// check if the open function is assigned to a servo channel.
uint8_t open_chan;
if (!SRV_Channels::find_channel(SRV_Channel::k_mount_open, open_chan) &&
!SRV_Channels::find_channel(SRV_Channel::k_mount2_open, open_chan)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If you have two mounts, this will use the same servo channel for both.

Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure I'm getting what this is doing. I'd want both gimbals to move in sync sometimes, but not other times depending on what I'm doing. Is that what this is?

If that's what this is, it's a great idea, but is it optional?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, @nexton-winjeel is right. We should check for k_mount_open or k_mount2_open depending upon the instance of the gimbal.

@rmackay9
Copy link
Contributor

rmackay9 commented May 7, 2024

@rohan-pandeyy,

Are you happy to fixup the issues raised above? If not I can take over. Txs in either case.

@rohan-pandeyy
Copy link
Author

@rmackay9 yes you can take over regarding the issues raised above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants