Best practices for writing low level drivers with ROS wrappers? [closed]

asked 2020-06-17 09:10:48 -0500

peterpolidoro gravatar image

Does anyone have examples or advice for the best way to write and organize low level driver libraries so they may be run in as many environments as possible with ROS interfaces wrapped around them?

For example, I enjoy finding nice IC chips and using the datasheets to write C++ interfaces to them for Arduino boards. What is the best way to generalize an Arduino library so that in addition to the bare metal environment, the same code also runs on an RTOS, for use with micro-ROS, and on regular or embedded Linux, for use with ROS on say a RaspberryPi with wiringpi? The code like SPI calls can be broken out into board support packages. Should those BSP files be located in the same repository as the driver library or in separate repositories that will be dependencies for the driver libraries? Can C++ be used for such a general driver or should it be written in C? Are there examples of low level drivers that handle this in an elegant way that we can use as reference?

Are there ways to structure a low level driver to make it easier to write the ROS interface? Could it be possible to write it in such a way that a ROS interface could be automatically generated, with say topics for each public setter method and services for each getter method? Are there examples of ROS interfaces to low level drivers that are nice enough to use as references?

How can the flexibility of being able to modify both the low level driver and the ROS interface be used to create a nicer combination of the two than simply having to write a ROS interface to an existing driver?

edit retag flag offensive reopen merge delete

Closed for the following reason Question does not follow our guidelines for questions. Please see: http://wiki.ros.org/Support for more details. by peterpolidoro
close date 2020-06-18 09:29:18.065993

Comments

Some observations:

  • you mix multiple (sub)questions in a single post, this is not a good idea on ROS Answers
  • "with say topics for each public setter method and services for each getter method?" regardless of whether this would be possible, I would not do this. Setters and getters exist to be able to enforce entry and exit conditions and invariants. Subscriptions are a one-way channel, and completely decoupled. There is no way to provide any feedback to publishers. Services could work, but there is a difference between a remote procedure object (as you seem to describe) and a ROS service.
gvdhoorn gravatar image gvdhoorn  ( 2020-06-17 15:39:58 -0500 )edit

Maybe ros discourse would be the best place to post this question.

Teo Cardoso gravatar image Teo Cardoso  ( 2020-06-17 18:48:32 -0500 )edit

@Teo Cardoso Please don't suggest asking questions on ROS Discourse. That's clearly not recommended in our Support Guidelines The advice from @gvdhoorn is to restructure the question, and separate it into different questions that can be more concretely answered. That will provide direct answers to this question as well as be easier for future users to discover the same/similar question and the appropriate answer. With compound questions like this with many open ends effectively take an essay to answer and that both takes a lot of time as well as requires the person to have a very broad knowlege of the topic(s). If they're skilled in one topic but not the other they either have to give a half answer or need to take time to research the other elements, or often enough they will give up and walk away because it's more time ...(more)

tfoote gravatar image tfoote  ( 2020-06-17 19:00:17 -0500 )edit
1

Thanks, you are right, sorry, I did turn that into a compound set of open-ended questions. I will close this question and separate it into more specific questions.

peterpolidoro gravatar image peterpolidoro  ( 2020-06-18 09:28:31 -0500 )edit