[ros-users] CAN bus, serial messages

Brian Gerkey gerkey at willowgarage.com
Fri Sep 3 21:44:23 UTC 2010


hi Garratt,

One general downside to this approach, which in Player we called
"opaque messages," is that you lose the ability to introspect the
contents of messages.  That `data` member is a binary blob that, for
example, rostopic can't meaningfully print.

But I assume that your intent is to keep whatever higher-level ROS
interface currently exists (e.g., a PoseStamped target for an
actuator), and add this CAN layer below it, expressly for the purpose
of interacting with the device.  As long as the CAN messages don't
percolate up into other parts of the system, it sounds like a good
idea to me.

In a similar vein, Geoff Biggs wrote the flexiport library, which
provides an abstraction atop serial ports and TCP sockets:
  http://gearbox.sourceforge.net/group__gbx__library__flexiport.html

	brian.

On Fri, Sep 3, 2010 at 2:10 PM, garratt <garrattgallagher at gmail.com> wrote:
> Hi all,
>
> I propose, or call for implementations if they exist, a CAN message
> type. Normally I don't send out an email for every message I make, but
> this relates to decisions that can influence the whole ROS communication
> paradigm, so I though I'd ping the community to see what people think.
>
> The idea is:  most computers don't have CAN (or serial, anymore) port,
> and you usually have to write/adapt a driver to communicate on a CAN
> network.  This driver often gets incorporated into the rosnode of
> whatever device is on the network, meaning that:
> A) the rosnode for the device is not reusable for people with different
> CAN interface
> B) The code has to be re-adapted to use the same CAN interface with
> another device
>
> I know of at least 3 nodes I have personally interacted with that have
> this structure.
>
>
> If we have a can message type, for example:
>    uint64_t timestamp
>    uint32_t id
>    uint32_t datalen
>    uint8_t  data[8]
>
> then we solve both problems.
>
> Now, with some interface types (say for example usb) it would not be
> advisable to have a ros message representing a low level communication,
> due to bandwidth and latency problems, but I don't think this is a
> problem for CAN, since the maximum bandwidth is so low to begin with.
>
> What do you think, ros community?  Is there a reason this hasn't been
> implemented before?
>
> Garratt
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



More information about the ros-users mailing list