Change event messages to hold the old and new state

[Marcus Liebhardt]

Currently each program receiving event messages needs to store the old state of the sensor(s) internally to understand what has changed. This means each of them needs to implement this logic to parse the message, store the old state and compare it with the new sate.

Let's move this logic into the kobuki_node and always publish the old and new state to make the life easier for developers creating apps/programs on top of Kobuki (node).

Also, let's use this change to design new messages, which are more suitable for general use, so that they may get integrated into standard ROS message packages in the future (or at least serve as a design seed).

[Marcus Liebhardt]

Here is a proposal for general state messages, which could be used for the bumper, cliff and wheel drop events.:

BoolStateChange

bool UNSET = 0
bool SET   = 1

bool new_state
bool old_state

BoolStateChangeStamped

# contains time stamp of the message creation (ideally state data creation)
# and frame_id holds the object's name, which we are tracking
# (ideally corresponds with the tf frame name)
std_msgs/Header header

bool UNSET = 0
bool SET   = 1

bool new_state
bool old_state

BoolStatesChange

BoolStateChange[] state_changes

BoolStatesChangeStamped

BoolStateChangeStamped[] state_changes

[Daniel Stonier]

I suspect if you make arrays of msgs like this though, you won't get bit packing. Is that important to us?

The roswiki has a decent page about how different data types are handled. Probably what is important to note there is that message arrays won't be bit packed, but for c++, bool[] won't even be bit packed (defaults to std::vector<uint8_t>).

So, if we wanted bit packing, the only way you'd get that is if you represented the plurality of those sensors with int32 or similar and parsed them as bitfields.

[Marcus Liebhardt]

I suspect if you make arrays of msgs like this though, you won't get bit packing. Is that important to us?

Only except in cases in which you like to track a huge amount of states, e.g. track the state of a building's 18932 light bulbs. Also, when using the stamped versions, the strings are the heavy part.

I guess, the slim versions would be:

BoolStateChanges (slim)

bool UNSET = 0
bool SET   = 1

Int64 new_state # or Bool, Byte, Int8, Int32,...
Int64 old_state # or Bool, Byte, Int8, Int32,...

BoolStateChangesStamped (slim)

bool UNSET = 0
bool SET   = 1

Time[] stamps 
String[] object_names
Int64 new_state # or Bool, Byte, Int8, Int32,...
Int64 old_state # or Bool, Byte, Int8, Int32,...

Time array is used for case in which the each object's state change may happen at a different time (e.g. message used for low frequency updates).

[Jorge Santos Simón]

I'm uneasy with the idea.

• First because the old state of a boolean sounds estrange, if we receive these messages to signal events (because are booleans, no bit-masks, right?.
• Second, the BoolStatesChange array don't tell you who's state changes, so you need to check the code or documentation.

Am I missing something?