As far as I know it is not possible to publish out-of-bound values for message fields with ROS nodes/nodelets. E.g. the only possible publish-able range for uint8 message field values is in the range between 0 and 2^8-1. But is it possible to inject out-of-bound values in the full data range of the underlying data type of the ROS client implementation into a message published on a topic? That a subscriber (ROS Python client) to a topic would receive messages with e.g. a message field type of uint8 in the full range of integer data type. Or do clients silently validate and drop such messages if received?
Originally posted by thinwybk on ROS Answers with karma: 468 on 2018-06-01
Post score: 0
Original comments
Comment by jayess on 2018-06-01:
Just a pedantic nitpick, but the range for uint8
is actually 2^8 - 1 = 255, while 2*8 - 1 = 31. So, either this is a typo or if you're publishing values in the range [32, 255] you're actually still in range for uint8
.
Comment by thinwybk on 2018-06-01:
Right. Python 2**8-1. fixed
Comment by gvdhoorn on 2018-06-02:
Another nitpick: are we mixing up the concepts "out of band messaging" and an "out of bounds" problem when representing a value? The former may be possible, depending on how strict you define it and map that to ROS infrastructure. The latter makes a little less sense to me in this context.
Comment by thinwybk on 2018-06-02:
I am not sure if I understand "out of band messaging" in the ROS context. It is about message field values which are inside the range of the underlying Python data type (e.g. Python int) but outside the corresponding ROS data type (e.g. ROS uint8). (E.g. here int with wider value range as uint8).
Comment by gvdhoorn on 2018-06-02:
Your question title says "receive messages [..] which are out-of-bound". That doesn't make sense to me. Fields could potentially have values in the serialised bytestream that are out-of-bounds for their specced types, but this statement cannot apply to complete messages ..
Comment by thinwybk on 2018-06-02:
You are right. I adjusted the question accordingly. :) Sry for the confusion.