Logging macro conditional on a latch/flipflop

[russkel]

Logging macro conditional on a latch/flipflop

[russkel]

Thanks.

I'm curious why not implement it with code instead of relying on log functions? Implementing it by the user would also be simple.

You could say that about all the log macros.

We have ended up implementing many "simple" things throughout our code base in relation to rclcpp functionality and it get tiring writing out the same boilerplate. I intend to follow the same approach here but I wanted to see if it was possible using log macros. If it can, then great I will create a PR, if not, it goes into our private libraries never seeing the light of day.

[Barry-SH]

Currently, the log provides the function RCLCPP_INFO_ONCE(), but it doesn't fully meet your needs.
If you want to implement it, you can refer to the implementation of RCLCPP_INFO_ONCE()

• rclcpp/resource/logging.hpp.em
• rcutils/resource/logging_macros.h.em

I'm curious why not implement it with code instead of relying on log functions? Implementing it by the user would also be simple.

[Barry-SH]

I have no reason to oppose adding such a feature to the log function. It brings convenience to the users. Let's hear the opinions of other community members.

[fujitatomoya]

@russkel thanks for creating issue.

hardware not ready yet
// and finally system swaps over
System in good state, ready.
// and then back again
hardware not ready yet

i guess RCLCPP_INFO_ONCE would not be useful with above use case, that state gets back to the previous state.

maybe there are some constraints, but i would not use topics to share the hardware or sensor state.

instead,

• using service, so that client (user) can know the state anytime they want. (client can ask it when needed, instead of waiting for the topics. this probably conserves the inter-process communication.)
• or parameters? make it read only parameter and read it from the remote nodes, so that client can know the state. besides, using parameter events can be more useful to get the event once the parameter is changed on the device.

[russkel]

maybe there are some constraints, but i would not use topics to share the hardware or sensor state.

This was an example (and it's dealing with the data stream such as serial from a hardware sensor), this is pretty common where sensors will report their state at > 1Hz. There's no publishing in the example.

I imagine there's a few use cases outside of this example too.