Integrating Hardware-Components (Param updates, custom proto msgs, 'service' callbacks)

Hi there,

I have a couple of questions on how to integrate sensor hardware properly into ISAAC or how you would ideally like to see it integrated (in terms of style and quality).

  1. A post of another user from last summer suggests that custom proto messages are currently not “possible”. However, as some sensors deliver information than for example a flatScan message, custom messages are required. Could you please give me guidance how to compile own messages (given I have already setup my own captn proto msgs)?

  2. ISAAC_PARAM allows dynamic manipulation of parameters via web-gui but it seems this mechanism at the codlet does not offer callbacks or dirty-flags I would have to check for each param at each tick if they have been modified, thus duplicating the updatable variable set with previous values (to compare against). Unfortunately, sending the parameter-set (this ‘reconfiguring’) unconditionally at each tick to the sensor is too expensive. So basically my question is whether there is a mechanism I have overseen or if this implementation is as it would be expected.

  3. Is there a request-response-equivalent (like in ROS Services) currently available in ISAAC?

Thank you very much in advance!

Hi again,

regarding question (1) it turned out not to be so difficult by replicating some structure of the global //messages/BUILD and messages.bzl into the local folder and using the capnp tool to generate some IDs for custom proto schemes (even though they might actually collide by chance with the already given ones), writing some dummy To/From-Proto converter class and calling ISAAC_ALICE_REGISTER_PROTO(…).

I need to test if that really works , though :)

Hi Martin,
Can you give a little bit more details in what you are trying to accomplish so we can guide you in the best direction?

For 2) are you looking for a general mechanism to know when a configuration value has changed? Or are you looking for a way to change a specific configuration parameter from your custom code? What is your specific use-case?

For 3), we don’t have a generic protocol for that although you can accomplish it by message passing communication. For reference, it is similar to what we do in the communication between the backend and the WebSight.
Are you looking to implement a custom request-reply service specifically for WebSight <-> Backend or for general component communication?

1 Like

Hi @TeresaC ,

  1. yep, I am looking for some indication (a flag, or a function to ask with boolean return value like paramsHaveChanged()) to use within each tick()-call to react to parameter changes and send out a new sensor-config. Currently, I have implemented a struct that duplicates the the relevant subset of ISAAC_PARAM’s previous values to compute whether there was a change or not. A really simple thing but it kind of bloats up the code and makes errors in maintaining the code more likely.

  2. For general component-to-component communication; but you are right with a request/response message its easy to implement.

1 Like

Hi @schulze762gr,

His name is @TeresaC.

Thanks for the modification. :)

Thanks for the clarification,
We have not implemented this feature so far but thanks for the feedback!

As a workaround, since the configuration backend is open-source you may try to implement this within its workflow. For instance, when a parameter is set you can set a specific flag or implement your own Bridge/Service to check for parameter update.

While implementing this however, you should be aware that generally the configuration is not immediately updated on the component.

To give you a general idea on how it works:

  • ISAAC_PARAM is implemented via a Config Hook.
  • When you set a parameter it is stored in the cache of each Config Hook (local to each node).
  • This Config Hook is also marked as “dirty”. “Dirty hooks” are updated before each component’s tick().
  • This means that generally if you change a configuration, it won’t be visible until the next tick(). This way you can assure that in a certain tick the component configuration is immutable.
  • There are cases where the update can be “forced” but simpler would be for you to not assume this

For reference you can go through some of the code to try to better understand it:
//engine/alice/hooks/config_hook.hpp & config_hook.cpp
//engine/alice/components/Config.hpp & Config.cpp
/engine/alice/backend/config_backend.hpp & config_backend.cpp

Also, have a look at the Configuration Bridge used for the WebSight - Backend communication: //engine/alice/components/ConfigBridge.cpp

1 Like