Additional properties for flexbe states

[Squelsh]

Hi Phillipp,
first of all: Thanks for you efforts in creating / maintaining such a helpful project!

Now for my question: I would like to add additional properties to states, so that they get parsed, when a behavior is loaded (in the GUI as well as onboard for execution).
The result should be a list of the properties of all states in the behavior.
The idea is to build a coarse "semantic" check, to decide if a behavior can be executed on robot A or if it requires skills of robot B.

Could you give me a short hint, where to start implementing such a feature? Flexbe has quite some source files and I was hoping that I do not have to analyze all your (nicely documented) code...

Thanks! Andy

[Squelsh]

As far as I analyzed your code now, I would try to add a function collect_skill_requirements() to the Behavior base class and also a get_skill_requirements() to the EventState or OperatableState (which one would you suggest?).

[pschillinger]

Sounds very useful, likely also for others. I agree with your suggestion regarding behaviors, although I would let the behavior merely delegate collecting the properties to the root state machine and actually implement it there. This better reflects the hierarchical character in the case of embedded state machines. Regarding the states (and also state machines) my concept was adding different features by inheritance, ie the EventState adds event functionality, the OperatableState adds operator interaction functionality, etc. As such, I would recommend to add a new class like PropertyState with a static method as you suggested to be overwritten by state implementations. I would put it between the OperatableState and the PreemptableState, ie inherit from PreemptableState and let OperatableState inherit from PropertyState. The same for state machines. Yes, sorry for the documentation... Did you take a look into my Master Thesis? It is for example linked on the FlexBE homepage. Of course it is not meant as documentation, but it gives some overview and might be helpful. Of course, let me know if you have further questions and thanks for your effort and interest!

[Squelsh]

Thanks for you reply. I will have a look into your thesis, especially as I am not yet completely familiar with what is transfered between GUI and onBoard and over which protocol (file-system vs. ROS msg).

...merely delegate collecting the properties to the root state machine...

Thats actually exactly what I already did. Works so far.
I will also follow your advice and add a new base-class to inherit the property requirements.
So I think I can handle the Python side.

But now for the GUI: I learned to hate this Java stuff from previous projects (:
I crawled your Chrome-code to understand what is going on there.
To make the property requirements editable from the GUI, I think I have to come up with a RegEx to match the property class variable of the states.
Then fiddle in an input field, similar to the states "Parameters". And then I have to understand, how you actually write the stuff back into the original code file on the disk.
==> I am sure, I will have more detailed questions soon.