Add support for one-time takeoff/landing

[christophebedard]

Puisque le takeoff et le landing ne sont effectués qu'une seule fois chacun (au début/à la fin), il faut pouvoir débuter absolument par le takeoff, poursuivre avec le reste, et finir (en espérant) avec le landing.

L'option que j'envisage :

Un genre de init() appelé au tout début de la Strategy : le premier Behaviour est alors un genre de TakeoffBehaviour qui gère la TakeoffCommand. Lorsque le takeoff est terminé, on poursuit avec la boucle update() infinie pour le switch d'autres Behaviour. Le landing serait appelé par une méthode land() de Strategy, qui changerait pour un genre de LandingBehaviour/Command.

Aussi, comme failsafe additionnel, land() pourrait être appelée aussi après la boucle ros::ok() et/ou dans le destructeur de Strategy (mais je sais pas trop si c'est une bonne idée), au cas où ROS plante.

Ce qui me tracasse, c'est que cette option fait en sorte que Strategy gère (presque) directement la commande de takeoff/landing, ce qui casse un peu le principe strategy/behaviour/command. Toutefois, Strategy est le seul objet qui ne va pas être remplacé par un autre objet (ce que Behaviour et Command font), alors ce serait une place facile où mettre le "flag" de takeoff/landing.

@lajoiepy conseils/commentaires?

[lajoiepy]

Est-ce qu'il va être possible de faire une stratégie sans takeoff? Sinon ça me semble bon Le 2018-04-28 15:59, "Chris" <[email protected]> a écrit :

…

Puisque le takeoff et le landing ne sont effectués qu'une seule fois chacun (au début/à la fin), il faut pouvoir débuter absolument par le takeoff, poursuivre avec le reste, et finir (en espérant) avec le landing. L'option que j'envisage : Un genre de init() appelé au tout début de la Strategy : le premier Behaviour est alors un genre de TakeoffBehaviour qui gère la TakeoffCommand. Lorsque le takeoff est terminé, on poursuit avec la boucle update() infinie pour le switch d'autres Behaviour. Le landing serait appelé par une méthode land() de Strategy, qui changerait pour un genre de LandingBehaviour/Command. Aussi, comme failsafe additionnel, land() pourrait être appelée aussi après la boucle ros::ok() et/ou dans le destructeur de Strategy (mais je sais pas trop si c'est une bonne idée), au cas où ROS plante. Ce qui me tracasse, c'est que cette option fait en sorte que Strategy gère (presque) directement la commande de takeoff/landing, ce qui casse un peu le principe strategy/behaviour/command. Toutefois, Strategy est le seul objet qui ne va pas être remplacé par un autre objet (ce que Behaviour et Command font), alors ce serait une place facile où mettre le "flag" de takeoff/landing. @lajoiepy <https://github.com/lajoiepy> conseils/commentaires? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJgR16zARE5mfHAk14fNOnBDPNrEWL-qks5ttMoogaJpZM4Tri6g> .

[christophebedard]

hmmm I guess que non 🤔