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

Misleading assertion error on wrongly typed custom argument to class inheriting from ConditionNode #837

Open
frnyb opened this issue Jun 19, 2024 · 1 comment
Assignees

Comments

@frnyb
Copy link

frnyb commented Jun 19, 2024

First, thanks for a very nice project. I really benefit from it.

Describe the bug
When a class inheriting from CondtionNode has additional custom arguments, asside from node name and NodeConfig, Factory.registerNodeType fails on compile with

error: static assertion failed: [registerNode]: since you have a static method providedPorts(),
you MUST add a constructor with signature:
(const std::string&, const NodeConfig&)

when one of the custom arguments are of the wrong type. I think this is misleading, and it took a while to debug.

How to Reproduce
I have a class:

class TargetProvider : public BT::ConditionNode

With constructor

TargetProvider::TargetProvider(
    const std::string & name,
    const NodeConfig & config,
    rclcpp::Node * node,
    tf2_ros::Buffer::SharedPtr tf_buffer,
    iii_drone::configuration::ParameterBundle::SharedPtr parameter_bundle
) : ConditionNode(
    name,
    config
),  node_(node),
    tf_buffer_(tf_buffer),
    parameter_bundle_(parameter_bundle) { }

as well as providedPorts implemented.

I now register it with the factory:

        factory_.registerNodeType<TargetProvider>(
            "TargetProvider",
            node_,
            tf_buffer_,
            configurator_->GetParameterBundle("target_provider")
        );

where factory is a BehaviorTreeFactory object. node_ was accidentally of the wrong type, and the mentioned assertion error is yielded on compile time. Replacing node_ with an object of the correct type fixes the error.

It took a while to figure out, since the error was misleading. I believe a better error should be printed, as the issue was not due to the constructor being wrong.

Cheers

@facontidavide
Copy link
Collaborator

Which message would you suggest, instead?

@facontidavide facontidavide self-assigned this Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants