Monthly Archives: December 2022

Lidar Failing to Start – ROS2 and RaspberryPi

Hi everyone,

I’m messing around with a diff-drive robot and have been hitting an intermittent issue with my Lidar:

[INFO] [rplidar_composition-1]: process started with pid [5959]
[rplidar_composition-1] [INFO] [1672456772.854599418] [rplidar_node]: RPLIDAR running on ROS 2 package rplidar_ros. SDK Version: '1.12.0'
[rplidar_composition-1] [INFO] [1672456775.375585284] [rplidar_node]: RPLIDAR S/N: CD8EED93C0EA98C7A0E69BF55D504560
[rplidar_composition-1] [INFO] [1672456775.375837134] [rplidar_node]: Firmware Ver: 1.29
[rplidar_composition-1] [INFO] [1672456775.375932041] [rplidar_node]: Hardware Rev: 7
[rplidar_composition-1] [INFO] [1672456775.377533563] [rplidar_node]: RPLidar health status : '0'
[rplidar_composition-1] [ERROR] [1672456777.925797978] [rplidar_node]: Cannot start scan: '80008000'

This turned out to be a low power issue. The Pi’s voltage had been dropping to about 4.5v as my 12v battery grew a little flat. Recharging the battery immediately fixed the issue.

For a more permanent fix I will switch to a larger battery. Alternatively, using a USB hub with its own power supply would also work.

Thanks to this github thread for the help.

Wheel Going in the Wrong Direction – RVIZ2 and FoxGlove

Hi everyone,

I hope you’re having a good break! I’m currently following this tutorial and messing around with a diffdrive robot. After making a few changes I noticed that my simulations were playing up. Strangely, the robot itself was still working perfectly fine.

The problem I was having was that even though my robot was driving forward the simulations seemed to think that the left wheel was going backwards. Initially I suspected this was an issue with my robot’s definition but even when returning to a known working state the issue persisted.

Eventually, I realised that this meant it had to be a hardware issue. I am using an Arduino and two L298N motor controllers for the motors that run my wheels. The arduino then publishes my encoding counts over serial.

To debug this setup, I used miniterm to communicate with the arduino and view the serial output. To get this going I had to track down which serial port had the arduino connected:

ubuntu@ubuntu:~/robot_ws$ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Alternatively, ls /dev/ttyUSB* would also work. I also needed the baud rate which is set to 57600. This allowed me to connect, move the motors forward and also see the encoding counts:

ubuntu@ubuntu:~/robot_ws$ miniterm -e /dev/ttyUSB0 57600
--- Miniterm on /dev/ttyUSB0 57600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
0 0
o 255 255
-5531 5572
-8120 8222
-8120 8222

The issue became obvious with the left wheel outputting a negative value. The fix for this was pretty simple. Reversing the pins outputting the encoding count for the left wheel reverses the counter. Re-running the miniterm test showed both wheels with a positive count:

ubuntu@ubuntu:~/robot_ws$ miniterm -e /dev/ttyUSB0 57600
--- Miniterm on /dev/ttyUSB0 57600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
0 0
o 255 255
8146 8211

ros2 controller manager not available – articubot tutorials

Hey everyone,
I’m currently working through a great tutorial series on youtube for ROS2. Unfortunately, I ran into a bit of an issue with a race condition in a launch file. The controller managers were timing out before Gazebo was able to launch.

Controller manager not available

The author offers a suggestion to try using OnProcessExit to work around this but unfortunately it did not work for me. The comments on the video seem to suggest that a few others also hit this problem.

I did a bit of Googling and found an alternative way to add a delay on startup using TimerAction. Using the following code as a replacement for the original launch actions seems to work:

import os

from ament_index_python.packages import get_package_share_directory

from launch import LaunchDescription
from launch.actions import IncludeLaunchDescription
from launch.actions import TimerAction
from launch.launch_description_sources import PythonLaunchDescriptionSource
from launch.actions import RegisterEventHandler
from launch.event_handlers import OnProcessExit

from launch_ros.actions import Node

def generate_launch_description():

    # Include the robot_state_publisher launch file, provided by our own package. Force sim time to be enabled

    package_name='my_bot' #<--- CHANGE ME

    rsp = IncludeLaunchDescription(
                )]), launch_arguments={'use_sim_time': 'true'}.items()

    # Include the Gazebo launch file, provided by the gazebo_ros package
    gazebo = IncludeLaunchDescription(
                    get_package_share_directory('gazebo_ros'), 'launch', '')]),

    # Run the spawner node from the gazebo_ros package. The entity name doesn't really matter if you only have a single robot.
    spawn_entity = Node(package='gazebo_ros', executable='',
                        arguments=['-topic', 'robot_description',
                                   '-entity', 'my_bot'],

    # This helps to address race conditions on startup for the 
    # controller managers. Note that we are exporting delayed_controller_manager_spawner
    # instead of just diff_drive_spawner.
    delayed_controller_manager_spawner = TimerAction(

    # Launch them all!
    return LaunchDescription([

This Github link has a good example of how to do this for another similar project:

RaspberryPi Camera not detected – Ubuntu 20.04.5 LTS

Hi everyone,

I ran into a bit of an issue with a RaspberryPi 4 running Ubuntu 20.04.5 this morning. Running vcgencmd get_camera should have returned supported=1 detected=1 but instead I was getting supported=0 detected=0.

This was a bit of a hard one to track down with Google but I eventually came across a stackoverflow post suggesting the following:

  • Run sudo nano /boot/firmware/config.txt
  • Add start_x=1 at the end
  • Reboot

Check out this post for more info:

If you’re using a new camera you may also run into this error:

mmal: Cannot read camera info, keeping the defaults for OV5647
mmal: mmal_vc_component_create: failed to create component '' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component '' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Only 76M of gpu_mem is configured. Try running "sudo raspi-config" and ensure that "memory_split" has a value of 128 or greater

The fix for this one is to simply append another line to /boot/firmware/config.txt. All you’ll need is gpu_mem=128.

Another issue you might run into is VHCI initialization failed. Generally, that just means you need to add your current user to the video group.

# Check your current user's groups.

# Add your user to the video group.
sudo usermod -aG video <username>

Once you’ve added the group, rebooting should be enough to get past that error.