What's the difference between a wrapper and a driver

1

So I realized the radar which I have bought doesn’t have existing ROS drivers, thus I was wondering about what does it mean to build a driver for a component.
I found this tutorial:

Does this qualify as the driver for a component?
or does writing a driver mean writing code that operates the desired sensor/machine?

2

At a high level a ROS driver would do these things:

  • The ROS driver is a ROS node.
  • In your case you may say that you want this node to output a Radar scan 10 times per sec.
    A ROS driver to do this would ‘publish’ the scan data 10 times a second.
  • Your radar node would have to interface with your hardware and read the hardware perhaps using hardware linux drivers the company supplies or source code you build that hardware level driver from that your ‘radar’ people know works on Ubuntu 16.04 code on a raspberry Pi. The low level hardware driver to ‘read’ or control your Radar knows nothing about ROS.
  • I’m going to take a basic ‘guess’ at the sort of thing you want when I say the following:
    Lets say 10 times a second you pull in the data from your Radar into this new node. You would generally then have to find a suitable ROS message type to convert and package up a given scan into this ros message. You would then publish this message with the single radar scan in its ROS message onto a ROS topic

Other things this node would need would be a ‘ROS launch file’ to start it out as well as it is likely you would want to read in ROS parameters into your node such as how often to publish a radar message or to tell your driver operating parameters needed for your Radar. Thos parameter may be things like the USB port or serial port or device name and so on as well as other configuration parameters unique to your radar.

So back to your question: The term ‘wrapper’ is sometimes used for this case perhaps to mean you have a bunch of C code that accesses the radar. So you put all those routines into the source code for this radar node OR you have a library they supply. One way or another it means you ‘wrap up’ their ‘guts’ that do all the real work of interfacing with the radar and then you have other code to format ROS messages and so on as discussed above.

Mark

1 Like
3

So I did look at the article you posed but only just now after my explanation. That article says what I said but with a great deal more detail and nice pictures. That article looks correct and a good source of info.

Your biggest problem is to really do all this is a lot of ROS specific learning but maybe that organization has other help to help you there.

I have written ROS nodes in 4 hours or in 4 weeks and it all boils down to how involved the ‘real work’ needs to be for that radar of yours.

You will learn a great deal about ROS, quite a project.

Mark

1 Like
4

In a different thread on this forum I have posted a ROS node that is just about as simple as a node gets. This node ‘could’ be used as a sort of starter template for the node for your project.

You would change package name and other things but then would have to do the large task of adding in the radar interfacing code and then conversion of radar data to ROS messages.

this is the simple ‘starter basic code’: https://github.com/UbiquityRobotics/sonar_detector

So the specifics of this node do not apply to the large amount of Radar interfacing nor does it apply to the specific type of ROS message(s) you would output BUT this node shows a lot of the ROS mechanisms you for sure would have to have in your node for basic ROS message processing.

This is a small part of your task, the huge amount of your task is wrapping the radar driver code and then forming meaningful messages to be published.

You would be wise to search for an Existing ROS message that would match your needs and even better a Ros Message that has RVIZ support already. So I suggest you look at sensor_msgs and try to find one that would have the type of output you would want for your Radar and see if it has support in RVIZ. This is up-front homework and time well spent.
do not invent your very own message unless none of the messages in sensor_msgs will hold the type of information you want in your radar.

See and study these messages: http://wiki.ros.org/sensor_msgs

Specifically read up on these messages: Range, LaserScan (2d radar) or the PointCloud ones which can deal with 3d data points

1 Like