oyssolbo / anafi_mission_planning Goto Github PK

PDDL did not like to track helipad within the same tracking function.
Use another tracking-function specifically for the helipad?

Must be able to replan with the same goals, and not just when the state of the fsm changes.

Actions are not properly cancelled

Fuck!!!!!!!!!!!!!!!!!!!!!!!!!!

Currently, the olympe-messages are included in the anafi_uav_interface / anafi_uav_msgs in the ros1-bridge. May want to:

• split into separate packages
• add more messages taylored for our use case
• delete some messages left over from M.F.

@simenallum Any thoughts on this problem? Currently there is no selection of emergency priority. Could either continue the rescue and potentially lose the drone, but possible save a life, or it could abort the rescue and potentially save the drone, but possible lose someone's life

Bugs:

• executor crashes with message "[plansys2_node-1] ===> [(tracking d1 h1)] [plansys2_node-1] plansys2_node: /home/killah/colcon_ws/src/ros2_planning_system/plansys2_executor/src/plansys2_executor/BTBuilder.cpp:521: plansys2::Graph::Ptr plansys2::BTBuilder::get_graph(const Plan&): Assertion `at_start_requirements.empty()' failed."

• tracking incorrect for drop and land-actions, which must run after tracking and not during

Concurrent read/write can create race-conditions
Be careful!

Tried to avoid duplicating the code (see branches), but linker-problems, so I "gave up".
TODO

Testing shows that Plansys2 struggles with multiple goals. As such, using the for-loop for setting goals iteratively may be wrong, as the last goal may overwrite the previous ones.

Possible solution for setting goals: Use a simple for-loop for appending goals to a string, and set said goals via the problem-expert

Possible problem: If the theory is correct, the save_remaining_goal-function is wrong!

A goal is never cleared when the state machine transitions into another state

Currently, the implementations are inside the nodes that are called by the executor. This forces some hacky code, and reduces the node-frequency. It would be better to implement the actions as their own package, using ros2-actions to start/stop the functions

Using over-all conditions will trigger issues with at-start or at-end conditions for other actions. Testing shows that the behaviour-tree from plansys2 is incorrect, and likely linked to the issue observed in issue 211 at the plansys2-github repo.

PlanSys2/ros2_planning_system#211

May want some form of monitoring about the battery usage within the actions.
For example, that the move action estimates the expected battery drain based on the distance and the estimated battery usage. Checking this in the preconditions allows the system to abort the move or similar