Roadmap

[captain-yoshi]

A reminder of things to do before releasing a 1.0.0 release.

TODO:

• Finish implementing MTC stages
• Make stage properties configurable (set + configureInitFrom + exposeTo)
• Implement pick and place demo
• Implement other demo's
• Add usefull callbacks
• Remove constexpr port names. It is more verbose to directly use the string.
• No need to enforce every blackboard variables with a shared_ptr.
• Refactor namespace
• Refactor some classes with templates
• Properly set BT Ports
• Convert TreeNodes into plugins. See plugin example.
• Connect Stage: add multiple GroupPlannerVector in the BT. Or create a new class.
• Add Gtests, convert current examples to tests. Keep the demo's in example folder.
• Add CI
• Test: make sure that the shared pointer is removed from the blackboard.
• Reorganize/Modify the API.
• Add all complex blackboard params thread-safe. Documentation.
• Find a way to halt the BT PlanMTCTask by checking the isHaltRequested. Documentation. Probably needs a PR in MTC to add a callback in the plan method.
• Ask BehaviorTree.CPP if we can minimize specific node parameters in Groot2
• Add documentation

---

Namespace

I would propose these changes to better align with BehaviorTree.CPP:

namespace BT {
namespace MTC {

template <typename T = Any>
class SetMTCProperties : public SyncActionNode
{
public:
  SetMTCProperties(const std::string& name, const NodeConfig& config)
    : SyncActionNode(name, config) {}

  NodeStatus tick() override {}

  static PortsList providedPorts() {}
};
} // namespace MTC

template <>
inline MTC::SharedProperty<int> convertFromString<MTC::SharedProperty<int>>(StringView str)
{
  MTC::SharedProperty<int> output = std::make_shared<int>(convertFromString<int>(str));

  return output;
}


} // namespace BT

BT Ports

When moving a stage is it an Input or a Bidirectional Port ? Because the blackboard value is set to nullptr we should set the port to Bidirectional.

Halting an MTC Task::plan()

This PlanMTCTask BT node is derived from the ThreadedAction which makes planning in another thread. To be reactive, the plan must hbe preemptable. To this end, 2 PR's where submitted/merged to reduce the time it takes to preempt a task. But there are still some cases where an MTC stage is planning something long where it cannot be preempted.

[captain-yoshi]

If this PR get's merged BehaviorTree/BehaviorTree.CPP#944, we will be able to remove a lot of boilerplate code for manipulating stages and properties. For this library as well as user XML code.

// all of this
factory.registerNodeType<StageMove<moveit::task_constructor::Stage, moveit::task_constructor::ContainerBase>>("MoveStageToContainer");
factory.registerNodeType<StageMove<moveit::task_constructor::Stage, moveit::task_constructor::Task>>("MoveStageToTask");
factory.registerNodeType<StageMove<moveit::task_constructor::ContainerBase, moveit::task_constructor::ContainerBase>>("MoveContainerToContainer");
factory.registerNodeType<StageMove<moveit::task_constructor::ContainerBase, moveit::task_constructor::Task>>("MoveContainerToTask");

// would be simplified to
factory.registerNodeType<StageMove>("MoveStage");