Page tree
Skip to end of metadata
Go to start of metadata

Hardware setup:

There are 2 connections coming out of the LIDAR:  Power and Data

    The data connection is just a USB cable.  Confirm that it is plugged into *any* available USB port on the robot's computer
    The power cable provides 12V to the LIDAR.  Plug the LIDAR's 12V power cable into an available 12V power cable coming out of the top plate of the Robot.  Each power cable coming out of the robot should be labeled with a sharpie marker indicating its voltage (e.g. 5V, 9V, 12V), usually on the white-colored connector.  

    Plug an available ethernet cable into either of the Robot's PC ethernet ports (not your laptop).  
    Confirm that your robot now has internet access by typing ifconfig and making sure that you have an IP starting with 172.20 on either eth0 or eth1


SSH into the Robot (e.g. ssh -X frl@p0) to open a terminal window on the robot

Don't continue if you're not SSH'd into the Robot.

Install the Hokuyo Node package on the Robot
sudo apt-get install ros-indigo-hokuyo-node

Configure the LIDAR device for access
sudo chmod a+rw /dev/ttyACM0

Tell the ROS hokuyo node what device name your LIDAR uses (e.g. /dev/ttyACM0)
rosparam set hokuyo_node/port /dev/ttyACM0

Tell the ROS hokuyo node to change this param to enable faster startup
rosparam set hokuyo_node/calibrate_time false

Do a test run of the hokuyo node and confirm it can talk to the LIDAR hardware:
rosrun hokuyo_node hokuyo_node

You should see something like this:
[ INFO] 1256687975.743438000: Connected to device with ID: H0807344

Hit Ctrl-C once to quit that process.

While still SSH'd into the robot, we need to edit the base_pioneer.launch file.
Type this:
    nano ~/catkin_ws/src/nre_p3at/launch/base_pioneer.launch

add this text block on a set of blank lines, anywhere between the lines that indicate our group namespace.  In other words, between the line that starts with <group ns ...>  and the line </group>:

  <node pkg="hokuyo_node" type="hokuyo_node" name="my_lidar" respawn="true">
      <param name="frame_id" value="$(optenv HNAME)/base_link"/>

The text block above will automatically execute everytime the robot boots up.  It will launch a hokuyo_node node from the hokuyo_node package.  Also, that text block specifies that our distance readings should be designated as in the base_link frame.  The text "$(optenv HNAME)" simply prepends our robot's hostname (which is also our namespace) to the frame. In my case, it resulted in a frame_id value of /p0/base_link

reboot the robot's computer by typing:
    sudo reboot now

close your SSH window

open a new terminal window

make sure that the multimaster sync file has been launched and is configured to sync with the robot you just installed the LIDAR package on.

Open another terminal window and type:

rostopic list

if you were using robot p0, you should see a topic labeled /p0/scan

Confirm that the frame_id reflects the changes we made to the base_pioneer.launch file earlier by doing this:

    [once you type the below command, just hit ctrl-c to stop the stream of data from printing]
    rostopic echo /p0/scan    [note, this would be different if were not using the p0 robot]

You should have seen a large amount of data printing out.  Confirm that the section labeled HEADER contains the frame_id we set earlier (e.g. p0/base_link)

      seq: 190680
        secs: 1495828591
        nsecs: 366420500
      frame_id: p0/base_link
    angle_min: -1.57079637051
    angle_max: 1.56643295288
    angle_increment: 0.00436332309619
    time_increment: 1.73611115315e-05
    scan_time: 0.0250000003725
    range_min: 0.0230000000447
    range_max: 60.0
    ranges: [6.716000080108643, 6.7170000076293945, 6.7179999351501465, 6.7179999351501465, 6.715000152587891, 6.715000152587891, 6.735000133514404, 6.735000133514404, 6.738999843597412, 6.742000102996826, 6.75, 6.763000011444092, 6.75, 5.177999973297119, 5.060999870300293, 4.943999767303467, 4.818999767303467, 4.701000213623047, 4.583000183105469, 4.468999862670898, 4.380000114440918.........

Visualize the LIDAR in realtime by launching rviz.  Change p0 below to whatever robot you've been using
    roslaunch nre_p3at rviz_waypoint_two.launch leader:=p0

in rviz:
    click Add
    click By Topic
    click the LaserScan option
    click OK

In rviz, you should now see realtime LIDAR data represented as small points surrounding the robot

To use the LIDAR data in your assignments, you'll have to parse the LaserScan messages.

To determine the message type used by the LIDAR on roboto p0, type
    rostopic info /p0/scan

You should see;
    Type: sensor_msgs/LaserScan

To figure out how to break out the data you want from this message, get the message format by typing:
    rosmsg show sensor_msgs/LaserScan

This should show:
    std_msgs/Header header
      uint32 seq
      time stamp
      string frame_id
    float32 angle_min
    float32 angle_max
    float32 angle_increment
    float32 time_increment
    float32 scan_time
    float32 range_min
    float32 range_max
    float32[] ranges
    float32[] intensities

Note the [] brackets on field named ranges and the field named intensities.  These are arrays of distances (and intensity readings) from the LIDAR, indicating that *each* LaserScan message contains an entire array of different distance measurements taken at different bearings.  

You can manually transform the points into your robot frame using the data provided in the header.  For instance, the header specifies the scan swath in the values for angle_min and angle_max.  Further, it provides the change in angle between each scan in the "ranges" array, namely in the angle_increment value.  So, if angle_min was -90 and angle_max was 90, that would mean the LIDAR did a 180 degree scan.  Further, if the angle_increment were 5, that would mean that each distance reading in the array named ranges would correspond to the distances measured at -90 deg, -85 deg, -80 deg, -75 deg.....85 deg, 90 deg.
There is also a ROS function that does the transformation for you from laser frame to robot frame.  See here:


The LIDAR attempts to use the device name /dev/ttyACM0.  If there is already a device using /dev/ttyACM0 when the LIDAR is turned on, it will likely use /dev/ttyACM1.  Setting up a udev rule is a way to reliably force a hardware device to use a specific device name. 

setup udev

Using udev to Give Hokuyos Consistent Device Names
The getID program can be used to get the hardware ID of a Hokuyo device given its port. Combined with udev, this allows a consistent device name to be given to each device, even if the order in which they are plugged in varies. The following udev rule should work universally on any ROS system:

KERNEL=="ttyACM[0-9]*", ACTION=="add", ATTRS{idVendor}=="15d1", MODE="0666", GROUP="dialout", PROGRAM="/opt/ros/hydro/ rosrun hokuyo_node getID %N q", SYMLINK+="sensors/hokuyo_%c"
This udev rule sets up a device name that is based on the Hokuyo's hardware ID.

$ ls -l /etc/ros/sensors/base_hokuyo
lrwxrwxrwx 1 root root 28 2010-01-12 15:53 /etc/ros/sensors/base_hokuyo -> /dev/sensors/hokuyo_H0902620
$ ls -l /dev/sensors/hokuyo_H0902620
lrwxrwxrwx 1 root root 10 2010-04-12 12:34 /dev/sensors/hokuyo_H0902620 -> ../ttyACM1  

  • No labels


  1. Once we get a 12V splitter and can run all 3 devices at once (LIDAR, IMU, RFID), we determine whether the LIDAR conflicts with either the RFID reader or IMU on /dev/ttACM0, but I think it will. If so, we'll probably need to use a udev rule per above. 

  2. We might include the port and calibrate_time parameters into the launch file.  I believe this would look something like...

    <node pkg="hokuyo_node" type="hokuyo_node" name="my_lidar" respawn="true">
    	<param name="frame_id" value="$(optenv HNAME)/base_link"/>
    	<param name="port" value="/dev/ttyACM0"/>
    	<param name="calibrate_time" value="false"/>

    I haven't testing this, and the hokoyu_node parameters are dynamically reconfigurable, but I'm assuming they can still be specified as normal ROS parameters

  3. As for the udev rule, I think we may want to simplify this so that the scanners on the robots always get a generic device name rather than a device name that changes for each ID number.  The reason for this is that I don't expect to have multiple scanners on a single pioneer and it makes maintaining multiple robots simpler if all the names are consistent.  If the device names are different for each robot (since they each have a scanner with a different ID number) then the the launch file for each robot will have to be slightly different since the port parameter will be different for each robot.  

    Instead we could make a udev rule so all the scanners show up as something like /dev/hokoyu so that we can use the same launch file for all the robots.  I believe the resulting udev rule would look like...

    SUBSYSTEM=="tty", ATTRS{idVendor}=="15d1", SYMLINK+="hokuyo"

    To implement this rule, you need to add a new file in \etc\udev\rules.d with a name such as 98-hokoyu.rules.  This file would have simply the one line above.  Then when the Hokoyu USB is plugged in, a symbolic link of /dev/hokuyo should be created that points to the serial port.

    This should prevent conflicts with other USB-to-serial device such as the thingmagic RFID tag reader ThingMagic USB Pro RFID Reader, Pioneer Integration.  The Microstrain IMU/GPS should not be a problem since it is a native serial (RS232) device, not a USB-to-serial device.