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

Offboard lost actions with additional timeout #4655

Merged
merged 6 commits into from
Jun 20, 2016
Merged

Conversation

AndreasAntener
Copy link
Member

@AndreasAntener AndreasAntener commented May 27, 2016

Reimplemented offboard lost handling from #3404
@LorenzMeier before I go ahead with this, I'd like some feedback on where the states should switch. Since my earlier version you started to add failsafe handling in the navigator (e.g. here: https://github.com/PX4/Firmware/blob/master/src/modules/navigator/navigator_main.cpp#L570), and now we have 2 places where nav state decisions happen, a duplication of responsibilities. So in contrary of how RC and DL loss got implemented on master, the state switching here is all in state_machine_helper.

@LorenzMeier
Copy link
Member

I like your architectural approach better than the extensions I made. What is the testing state of this - good to go from your side?

@LorenzMeier
Copy link
Member

When do you expect to test this?

@AndreasAntener
Copy link
Member Author

Today

@AndreasAntener AndreasAntener changed the title WIP: offboard lost actions with additional timeout Offboard lost actions with additional timeout Jun 2, 2016
@AndreasAntener
Copy link
Member Author

Fixed the obvious errors.. but testing is difficult, my parameters get reset somehow? (#4722)

@AndreasAntener
Copy link
Member Author

Rebased, tested, ready.

*
* @group Mission
*/
PARAM_DEFINE_INT32(NAV_OBL_ACT, 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this param defined in the navigator space if the implementation is in commander?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, well, ahm, because the others are :). You're right of course, I should already move them to the commander. Then we can also move the rest of the failsafe handling.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's ok to have a param NAV_ if the action is decided in the navigator. In this case clearly all the logic is in commander, so I don't see why it should be COM_.

Copy link
Member Author

@AndreasAntener AndreasAntener Jun 10, 2016

Choose a reason for hiding this comment

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

Of course, I mean moving the handling and params over to the commander, in a later PR

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't it a pain to move the params later? I don't understand.

Copy link
Member Author

Choose a reason for hiding this comment

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

Na I meant other ones, doesn't matter, will do later. Moved mine and rebased.

@AndreasAntener
Copy link
Member Author

Fixed and merged

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.

None yet

3 participants