Skip to content

Tree Execution Error When Setting InputPort Value to Empty String with std::optional<T> Default Value as std::nullopt After Commit 789ce6ea0ad3627923bd2389b8fb9199ffab6d84 #768

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

Closed
KentaKato opened this issue Feb 13, 2024 · 3 comments

Comments

@KentaKato
Copy link

Following the changes made in commit 789ce6e, an error occurs during tree execution when std::nullopt is set as the default value for an InputPort of type std::optional<T>, and the InputPort's value is subsequently set to an empty string ("").

This issue is exemplified when T is set to std::optional<geometry_msgs::Pose>, resulting in the following error message:

You (maybe indirectly) called BT::convertFromString() for type [std::optional<geometry_msgs::Pose_<std::allocator<void> > >], but I can't find the template specialization.

[ERROR] [1707813348.400082594]: [port_utils::getInput] Failed to get input 'poses': You didn't implement the template specialization of convertFromString for this type: std::optional<geometry_msgs::Pose_<std::allocator<void> > >
[ERROR] [1707813348.400098635]: [BT][InputTest][InputTest](UID 1): failed to get inputs

In Groot2, when an InputPort doesn't explicitly have a value assigned by the user, the system automatically assigns an empty string (""). However, this automatic assignment leads to runtime errors when the InputPort is of type std::optional with std::nullopt set as its default value. Ideally, the system should detect when an empty string is auto-assigned to such InputPorts and instead utilize the user-defined std::nullopt default value to prevent these runtime errors.

@facontidavide
Copy link
Collaborator

I Will look into this

facontidavide added a commit that referenced this issue Feb 13, 2024
@facontidavide
Copy link
Collaborator

Check 83fce13

If the problem persists, please tell me how to extend the unit test Default_Issues_767_768 to cover your case.

@KentaKato
Copy link
Author

@facontidavide
Thank you for your prompt response. However, the issue still persists. I have implemented a unit test to reproduce it and submitted a pull request #773.

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