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

WIP: Omnibus MC only #10531

Closed
wants to merge 1 commit into from
Closed

WIP: Omnibus MC only #10531

wants to merge 1 commit into from

Conversation

dagar
Copy link
Member

@dagar dagar commented Sep 20, 2018

Needed to unblock #10355, but this is also a good excuse to fix these bogus dependencies.

Navigator is currently dependant on the VTOL parameters VT_B_DEC_MSS and VT_B_REV_DEL. Let's either handle this with the VTOL controller publishing a status message, or falling back to the old param API.

I'd vote for an orb based solution if @RomanBapst could assist. I'll be mostly unavailable until next week.

Similar to the way the FW position controller publishes position_controller_status for the L1 distance that's used by navigator as the acceptance radius, we could have the vtol controller publish an appropriate acceptance distance for back transition (how VT_B_DEC_MSS and VT_B_REV_DEL are used). https://github.com/PX4/Firmware/blob/master/src/modules/navigator/mission_block.cpp#L291-L305

Going forward I think we should strictly enforce parameter module boundaries with only a few global exceptions (SYS and CAL?).

@dagar
Copy link
Member Author

dagar commented Sep 20, 2018

@bkueng
Copy link
Member

bkueng commented Oct 26, 2018

I went for the simple solution (C-API) in #10738 to unblock things.

@bkueng bkueng closed this Oct 26, 2018
@MaEtUgR MaEtUgR deleted the pr-omnibus_MC_only branch October 30, 2018 12:18
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.

3 participants