benjmitch's profile - activity

Communication of topics between nodes built on different versions of ROS (e.g. kinetic <--> noetic) seems generall

Policy in ROS versioning is that communication between different versions (e.g. kinetic <--> noetic) ought to work

Policy in ROS versioning is that communication between different versions (e.g. kinetic <--> noetic) ought to work

Policy in ROS versioning is that communication between different versions (e.g. kinetic <--> noetic) ought to work

It's not unreasonable, but - no - you don't fit the profile ;), hence my looking for a way to make it transparent. Thank

Thanks, very helpful to my understanding. A relay node would have to move the signal to a different topic name, right? E

I see. I didn't mean to criticise a lack of documentation to be clear,, just wondered if there was some that I had not f

I see. I didn't mean to criticise a lack of documentation to be clear,, just wondered if there was some that I had not f

Clarification: It is possible to write a client that subscribes to these topics from noetic by providing the kinetic (le

How to receive standard message that has changed format in noetic? Hi, One of our products is built on ROS kinetic and

@jkretz You can then, as described in my question, build your ROS nodes (listeners/subscribers) standalone, and not worr

@jkretz Alas, you credit me with too much organisation. The project has been yocto now for months, and the buildroot con

@jkretz It did work, yes; I've since moved to Yocto, which was a pain, but easier than buildroot for me now it's done. H

I can, yes (I can add this to the question if necessary, the robot in question is a differential drive mobile base with

Is there documented best practice for design of the interface to a robot? Hi, Apologies if this is covered somewhere, b

Hi

I'm aiming to deploy a single ROS node on an embedded platform (buildroot, AM335x) that bridges between the embedded system and the network by publishing a signal or two, and subscribing to one or two more. I have spent the day figuring how to cross-compile the node for the target, mostly involving getting the ros packages to build from source against the target. I've now got a ros node executable that runs on the target (where I've also deployed the ros libs libros*.so and so on). However, it doesn't manage to contact the master on my workstation.

Now, there may be just some silly config problem and that's why the connection is failing. But my question is - is my approach naive? Is there lots more to ROS that would need to be deployed on the target for this to work? Or is the executable and the libros*.so (etc.) all I really need, save for getting the configuration right?

Any high-level advice gratefully received.

FYI, the reason I'm not using an off-the-shelf package is that there isn't one for buildroot. The reason I'm not switching to yocto is that it was hard enough getting buildroot to work correctly with the platform.

Cheers