Introduction

LEGO Technic 42203 is a charming construction truck with a flatbed that can carry a large load. It features doors that open to reveal the cabin’s cozy interior. It’s a great choice for building a robot car. The flatbed is perfect for holding computer gear, and the flat top can be used as a lidar sensor mount. Plus, the cabin has plenty of space for a camera.

What makes a Motorized Car

To make a motorized car move, we need both a steering system and a drive system. The driving and steering gears I have are from the LEGO Technic 42160 Audi RS Q e-tron. They’re much bigger and more complex than the cute little construction truck!

Here is the top-down, under-the-hood view of the simple construction truck:

Here are the guts of the Audi rally car. I placed the truck’s tires next to the monster Audi rally car’s tires. How much smaller the truck’s tires are! I’ll design a new driving and steering system for the truck, reuse the motors and hub from the LEGO Audi, and keep the truck’s form factor.

Gear Rack with a Double Bevel Gear for Steering

After some research, I developed this steering system for the truck. It uses a 1x7 Gear Rack with a 12-tooth Double Bevel Gear. The Gear Rack has axle holes and pin holes that can be attached to connectors to form joints for movement. The Double Bevel Gear’s axle connects to the motor. Here’s a closer look at how the connectors and pins work together.

Bevel Gears are conical gears with angled, rounded teeth designed to transfer torque at 90-degree angles.

The beige-colored axles are commonly used as the motor output. They have segments shaped like “+” to lock the axle to the motor and the gearwheel, while the smooth segment allows the axle to spin in the separator with minimal friction.

Here’s a snapshot of how it looks when it’s set up on the truck. I used the same-length front beam to keep the dimensions and shape consistent, so the upgraded truck frame can still fit under the same truck head.

Differential Gear for Propulsion

A differential is a gear mechanism that allows the left and right wheels to rotate at different speeds while still being powered by the same motor.

This is very important when a vehicle turns because the outside wheel travels a longer distance than the inside wheel. Therefore, the outside wheel must spin faster than the inside wheel. Without a differential, the wheels fight each other, and turning becomes jerky.

My LEGO Technic Differential Gear has:

• A round housing with five small 12-tooth Bevel Gears inside and a 28-tooth bright yellow Bevel Gear on the outside as the “lid”
• One input gear in the center, which is a 14-tooth bright yellow Bevel Gear that transfers motion at a 90-degree angle
• Two axle outputs for the wheels

In my truck, the motor sits a bit higher than the Differential’s input. To transfer the rotation downward, I vertically aligned two Spur Gears on the motor’s output shaft. A Spur Gear is a flat gear with straight teeth.

Putting All Together

Here’s the base frame for the upgraded truck! I removed the original gear set that lifts and lowers the cargo bed and used the space for the two motors and the Differential Gear.

Here is the truck’s original base frame for reference:

Show Time

Here is how the upgraded truck looks. You won’t notice much difference at first glance, except for the power supply in the trunk. Keeping the same look is my goal. :)

Enjoy a quick demo of the construction truck driving autonomously using a ROS2 script!

For information on how to control a LEGO motorized car using a gamepad or autonomously, please check out my earlier post on ROS2 Control of the LEGO Audi e-tron.

Cheers!

Introduction

After building a differential robot (Robot Auto Mapping using Nav2 SLAM Toolbox) using mechanical parts from OSEPP, I am looking to build a more durable mobile robot with stronger motors and a more attractive look.

I started with RC cars. However, to modify an RC car for ROS2 Control, I would have to discard many of its original RC parts, which is not very economical. Besides, the modified RC car does not look good.

I grew up as a LEGO fan and am now an AFOL (Adult Fan of LEGO). LEGO is the ultimate building block. I can take the blocks and build anything I want. Thanks to LEGO® Technic™, which releases model rally cars with real motors and hubs.

LEGO® Technic™ 42160

The LEGO Audi RS Q e-tron (Technic™ 42160) is a model of the 2022 Audi RS Q e-tron Dakar rally car. It features many realistic details, including individual suspension on each of the car’s 4 wheels and wheel elements that reflect the full-sized Audi’s wheel design.

Like a real-world rally car, the LEGO Audi e-tron has front-wheel steering and all-wheel drive. The model car is powered by three Technic™ motors, connected to the ports of the Technic™ Hub.

The LEGO Audi e-tron can be controlled via LEGO’s Control+ iOS and Android apps, but I want to control it with ROS2 and ROS2 Control so it can integrate with the larger ecosystem and do more than just drive. :)

ROS2 Controlled LEGO Car

What and Why ROS2 Control

ros2_control is a robot control framework in ROS 2 that provides a hardware abstraction layer for controlling robot actuators, sensors, and hardware interfaces in a modular and efficient way.

ros2_control enhances performance and offers real-time capabilities by avoiding multiple processes that collaborate via messages and topics. Besides, it promotes standardization and modular robot control. It supports various hardware interfaces through a hardware abstraction layer and enables a seamless transition between simulation and different hardware implementations with minimal code changes.

Developers can reuse existing controllers instead of writing their own from scratch. In fact, much of the robot control logic has already been developed by others, so the pre-built ROS2 controllers can be utilized as is in most use cases.

ROS2 Controllers for Wheeled Mobile Robots

For wheeled mobile robots, ros2_control framework offers the following types of controllers.

• Differential Drive Controller:
  • Controller for mobile robots with differential drive, which has two wheels, each of which is driven independently.
• Steering Controllers:
  • Bicycle - with the front wheel(s) steerable and the traction wheel(s) at the rear.
  • Tricycle - with a steerable front wheel and two independent traction wheels at the rear.
  • Ackermann - with two independent steering wheels at the front and two independent traction wheels at the rear.
• Mecanum Drive Controllers:
  • Controller for a mobile robot with four mecanum wheels, allowing the robot to move sideways, spin, and drive in any direction by controlling each wheel independently.

For more information about the ROS2 Steering Controller, please see the documentation on control.ros.org and steering_controllers. The second article provides detailed information on the controller’s command and state interfaces, parameters, and subscribed and published topics.

Bicycle Steering Controllers for LEGO Audi e-tron

This LEGO Audi e-tron is a car-like robot. It has steerable front wheels and all-wheel drive. The two front wheels work together to steer the car, and all wheels provide the same traction and forward and backward motion to propel it.

This resembles the Bicycle Steering model. Therefore, a bicycle steering controller is used for this LEGO car, utilizing two joints, virtual_rear_wheel_joint and virtual_front_wheel_joint, to control its movement.

Architecture

Here is the architecture diagram for a ROS2-controlled LEGO car, where the Controller Manager connects the controllers and the hardware abstraction of the ros2_control framework. On the one hand, the Controller Manager manages controllers (e.g., loading, activating, deactivating, and unloading them). On the other hand, it accesses the hardware components via the Resource Manager.

The control loop is managed by the Controller Manager’s update() method. It reads data from the hardware components, updates the outputs of all active controllers, and writes the results back to the components.

The Resource Manager loads the hardware component, manages its lifecycle, and exposes its command and state interfaces. During control loop execution, the Resource Manager’s read() and write() methods communicate with the hardware component.

To support the LEGO car, we need to implement the LEGO hardware component, which is the driver program for the physical LEGO car. The remaining components in the diagram are provided by the ros2_control framework.

ros2_control LEGO Hardware Component

There are three basic types of hardware components:

• Actuator: Simple 1-DOF (Degrees of Freedom) robotic hardware, such as motors and valves. An actuator implementation is related to only one joint.
• System: Multi-DOF robotic hardware such as industrial robots. This component has reading and writing capabilities and can have multiple joints.
• Sensor: Robotic hardware used for sensing its environment.

I use the “System” type for the LEGO hardware component because it has 2-DOF and uses two joints, virtual_rear_wheel_joint and virtual_front_wheel_joint, for steering and traction.

Hardware Description in URDF

The ros2_control framework uses the <ros2_control> tag in the robot’s URDF file to describe the components and the hardware setup. Here is my ros2_control.xacro:

<?xml version="1.0"?>
<robot xmlns:xacro="http://www.ros.org/wiki/xacro">
  <xacro:macro name="carlikebot_ros2_control" params="name prefix">

    <ros2_control name="${name}" type="system">
      <hardware>
        <plugin>audi_etron/CarlikeBotSystemHardware</plugin>
        <!-- LEGO Motor Control Parameters -->
        <!-- Maximum power for traction motors (0-100), default 80  -->
        <param name="max_traction_power">90.0</param>
        <!-- Maximum power for traction motors (0-100), default 50  -->
        <param name="max_steering_power">50.0</param>
        <!-- Maximum velocity command for scaling (rad/s) -->
        <param name="max_traction_velocity">25.0</param>
        <!-- Maximum steering position for scaling (rad), default 0.4 (~22.9 degrees)
             Must match URDF joint limits. Turning radius at max ~0.57m (wheelbase 0.24m) -->
        <param name="max_steering_position">0.4</param>
        <param name="steering_deadzone">0.05</param>
        <!-- Hub name pattern to search for during BLE scan, default "Technic" -->
        <param name="hub_name">Technic</param>
      </hardware>
      <joint name="${prefix}virtual_front_wheel_joint">
        <command_interface name="position"/>
        <state_interface name="position"/>
      </joint>
      <joint name="${prefix}virtual_rear_wheel_joint">
        <command_interface name="velocity"/>
        <state_interface name="velocity"/>
        <state_interface name="position"/>
      </joint>
    </ros2_control>

  </xacro:macro>
</robot>

Among the LEGO Motor Control parameters, the max_steering_power limits the power sent to the steering motor. It defaults to 50% for the following reasons:

1. Steering requires smooth, precise control, and lower power reduces jerky movements.
2. Lower steering power provides mechanical protection because steering components are typically more delicate; limiting power reduces stress.
3. Steering only turns the front wheels, which requires less torque than driving the car.

Hardware Component Class

The hardware component is a ROS2 package written in C++ with ament_cmake as the build type. A helpful command for creating the package is ros2 pkg create. After creating the package, add .hpp and .cpp for the hardware component implementation. Mine is `carlikebocarlikebot_system.hpp` and `carlikebot_system.cpp`.

The hardware_interface class must implement LifecycleNodeInterface’s on_configure, on_cleanup, on_shutdown, on_activate, on_deactivate, on_error methods; and overriding SystemInterface’s on_init, export_state_interfaces, export_command_interfaces, read, write.

For my LEGO CarlikeBotSystemHardware class, the LEGO motor’s control parameters are initialized in the on_init method. The on_activate method connects to the LEGO Technic Hub, and the on_deactivate method disconnects.

Code snippet from carlikebot_system.cpp:

hardware_interface::CallbackReturn CarlikeBotSystemHardware::on_activate(
  const rclcpp_lifecycle::State & /*previous_state*/)
{
  RCLCPP_INFO(get_logger(), "Activating hardware...");

  // Connect to LEGO Technic Hub
  RCLCPP_INFO(get_logger(), "Connecting to LEGO Technic Hub...");
  if (!lego_motor_controller_->connect(hub_name_)) {
    RCLCPP_ERROR(get_logger(), "Failed to connect to LEGO Technic Hub");
    return hardware_interface::CallbackReturn::ERROR;
  }

  for (auto & joint : hw_interfaces_)
  {
    joint.second.state.position = 0.0;

    if (joint.first == "traction")
    {
      joint.second.state.velocity = 0.0;
      joint.second.command.velocity = 0.0;
    }

    else if (joint.first == "steering")
    {
      joint.second.command.position = 0.0;
    }
  }

  // Ensure all motors are stopped initially
  lego_motor_controller_->stop_all_motors();

  RCLCPP_INFO(get_logger(), "Successfully activated!");

  return hardware_interface::CallbackReturn::SUCCESS;
}

The class’s write method converts the traction velocity into traction_power and the steering position into steering_power, enabling forward/backward motion and steering.

hardware_interface::return_type audi_etron::CarlikeBotSystemHardware::write(
  const rclcpp::Time & /*time*/, const rclcpp::Duration & /*period*/)
{
  // Check if motor controller is connected
  if (!lego_motor_controller_ || !lego_motor_controller_->is_connected()) {
    RCLCPP_WARN_THROTTLE(get_logger(), *get_clock(), 1000, "LEGO motor controller not connected");
    return hardware_interface::return_type::OK;
  }

  // Convert traction velocity command to motor power (needed to determine direction for steering)
  double traction_velocity = hw_interfaces_["traction"].command.velocity;

  // Convert steering position command to motor power
  double steering_command = hw_interfaces_["steering"].command.position;
  
  // Apply deadzone: if command is within deadzone threshold, force to zero to actively center steering
  if (std::abs(steering_command) < steering_deadzone_) {
    steering_command = 0.0;
  }
  
  // Scale steering position (-max_steering_position to max_steering_position) to power (-max_steering_power to max_steering_power)
  double steering_power_raw = 0.0;
  if (max_steering_position_ > 0.0) {
    steering_power_raw = (steering_command / max_steering_position_) * max_steering_power_;
  }
  // Clamp to valid range
  steering_power_raw = std::max(-max_steering_power_, std::min(max_steering_power_, steering_power_raw));
  int8_t steering_power = static_cast<int8_t>(std::round(steering_power_raw));
  
  // Negate steering only when moving backward or stationary (forward motion doesn't need negation)
  // When velocity > 0 (forward): negate (to fix opposite direction)
  // When velocity <= 0 (backward/stationary): don't negate (steering is already correct)
  int8_t steering_power_to_send = (traction_velocity > 0.0) ? -steering_power : steering_power;
  
  // Send steering command to PORT_D
  lego_motor_controller_->set_motor_power(LegoPort::PORT_D, steering_power_to_send);
  // Scale velocity (-max_traction_velocity to max_traction_velocity) to power (-max_traction_power to max_traction_power)
  double traction_power_raw = 0.0;
  if (max_traction_velocity_ > 0.0) {
    traction_power_raw = (traction_velocity / max_traction_velocity_) * max_traction_power_;
  }
  // Clamp to valid range
  traction_power_raw = std::max(-max_traction_power_, std::min(max_traction_power_, traction_power_raw));
  int8_t traction_power = static_cast<int8_t>(std::round(traction_power_raw));

  // Send traction commands to PORT_A and PORT_B (both wheels)
  lego_motor_controller_->set_motor_power(LegoPort::PORT_A, traction_power);
  lego_motor_controller_->set_motor_power(LegoPort::PORT_B, traction_power);


  return hardware_interface::return_type::OK;
}

I have a separate LegoMotorController class that handles all communication with the Technic™ Hub via the SimpleBLE library. The main methods in LegoMotorController are set_motor_power, connect, disconnect, and stop_all_motors. SimpleBLE is a cross-platform library for Bluetooth Low Energy (BLE) with C++ and other language support.

For more information about creating a new ros2_control hardware component, please see the documentation on control.ros.org

The source code repository for this LEGO car’s ros2_control hardware component is: https://github.com/jiayihoffman/lego_audi_etron.

Build the project

When running ROS2 robots, I prefer using a ROS2 Docker container because it provides a complete ROS2 environment with all dependencies and can run on any environment. I have a Dockerfile prepared for this project, located in the project’s docker folder.

To build the Docker image:

docker build -t lego_audi_etron -f "./docker/Dockerfile" .

Let the Robot March

Start the robot on Raspberry Pi

To start the robot, I start the “lego_audi_etron” Docker container. The container’s launch file loads and initializes the ROS2 hardware and the controllers.

I turn on the LEGO car’s Hub immediately after starting the Docker container. This is because the ROS2 control manager needs to connect to the Hub upon activation.

docker run -it --rm \
    --network=host \
    --privileged \
    -v /var/run/dbus:/var/run/dbus \
    "lego_audi_etron"   

Explaining the docker run command:

• --privileged: Required to bypass AppArmor restrictions and access D-Bus/Bluetooth hardware
• -v /var/run/dbus:/var/run/dbus: Mounts the host’s D-Bus socket so SimpleBLE can communicate with BlueZ

SimpleBLE uses D-Bus to communicate with the BlueZ daemon for Bluetooth Low Energy operations

In the command line, when I see the following messages, it means the ROS2 control manager is able to activate the LEGO car via the ROS2 control hardware interface:

[ros2_control_node-1] [INFO] [1768345118.037541315] [controller_manager.resource_manager.hardware_component.system.CarlikeBot]: Connecting to LEGO Technic Hub...
[ros2_control_node-1] [INFO] [1768345121.052584207] [controller_manager.resource_manager.hardware_component.system.CarlikeBot]: Found Technic Hub: Technic Hub (Address: ...)
[ros2_control_node-1] [INFO] [1768345121.052596873] [controller_manager.resource_manager.hardware_component.system.CarlikeBot]: Connecting to hub...
[ros2_control_node-1] [INFO] [1768345123.247685785] [controller_manager.resource_manager.hardware_component.system.CarlikeBot]: Successfully connected to LEGO Technic Hub!
[ros2_control_node-1] [INFO] [1768345123.498398953] [controller_manager.resource_manager.hardware_component.system.CarlikeBot]: Successfully activated!

I then wait for the messages of the bicycle_steering_controller and joint_state_broadcaster being loaded and configured:

[ros2_control_node-1] [INFO] [1768345123.647514626] [controller_manager]: Loading controller 'bicycle_steering_controller'
[spawner-3] [INFO] [1768345123.792577584] [spawner_bicycle_steering_controller]: Loaded bicycle_steering_controller
[ros2_control_node-1] [INFO] [1768345123.794617367] [controller_manager]: Configuring controller 'bicycle_steering_controller'
[ros2_control_node-1] [INFO] [1768345123.794807106] [bicycle_steering_controller]: bicycle odometry configure successful
[ros2_control_node-1] [INFO] [1768345123.803230163] [bicycle_steering_controller]: configure successful
[spawner-3] [INFO] [1768345124.718624417] [spawner_bicycle_steering_controller]: Configured and activated bicycle_steering_controller
[ros2_control_node-1] [INFO] [1768345125.248599089] [controller_manager]: Loading controller 'joint_state_broadcaster'
[spawner-4] [INFO] [1768345125.515453413] [spawner_joint_state_broadcaster]: Loaded joint_state_broadcaster
[ros2_control_node-1] [INFO] [1768345125.516909386] [controller_manager]: Configuring controller 'joint_state_broadcaster'
[ros2_control_node-1] [INFO] [1768345125.517096273] [joint_state_broadcaster]: 'joints' or 'interfaces' parameter is empty. All available state interfaces will be published
[spawner-4] [INFO] [1768345126.473333746] [spawner_joint_state_broadcaster]: Configured and activated joint_state_broadcaster

At this point, my ros2_controlled robot has started successfully.

Start the ROS2 Joystick

To use a joystick (gamepad) to control the LEGO car, I use the ROS2 teleop_twist_joy package.

Each gamepad has an enable button. Press it while twisting the joystick to control the robot. On the PS5, it is the “PS” button.

One important thing to note is that the ROS_DOMAIN_ID environment variable must be the same on the dev machine running the “teleop_twist_joy” and in the Docker container running the robot. This environment variable controls who can access the robot’s published data and which ROS2 applications can interact with one another. If your robot cannot see the commands published by the joystick, please check that the ROS_DOMAIN_ID is set correctly.

To start the ROS2 teleop_twist_joy:

ros2 launch teleop_twist_joy teleop-launch.py joy_config:='ps3' publish_stamped_twist:=true

Here is a demo of the car driving autonomously using a ROS2 script, and we visualize it in RViz.

Enjoy!

However, ROS nodes in robots communicate with each other via TCP/UDP sockets, which are not accessible outside the robot’s LAN. Rosbridge WebSocket is a communication interface that enables non-ROS applications, such as web or mobile apps, to interact with a ROS system over a WebSocket connection through standard HTTP.

To use the robot as a security robot, I need to be able to interact with it over the internet while I’m away. How can I do that securely?

In my previous post, Live Video Streaming of Security Robots, I explained how to stream video from the robot over the internet securely. In this article, I will discuss how to control the robot over the internet securely.

Architecture

There are three components involved in the project. In the following sections, we will provide a detailed explanation of what they are and why they are needed:

1. The robot, where the ROS framework and ROS bridge operate.
2. The cloud server, which acts as an SSH Tunnel to relay WebSocket messages from the mobile app to the robot.
3. The mobile app, such as Droid Vision with built-in Joystick and Keypad, connects to the cloud server wss://cloud-server-domain.com/rosbridge/ and sends ROS commands in JSON format.

The Robot

Robot Operating System (ROS) runs entirely on the robot

1. The robot exposes ROS2 topics, such as /cmd_vel, /odom, and sensors topics, on the robot’s LAN. For details on running ROS2 on a physical robot, please see my article ROS 2 Control, Robot Control the Right Way

    ros2 launch my_bot robot.launch.py
   

2. The robot launches the ROS bridge server to accept ROS commands via HTTP requests

    ros2 launch rosbridge_server rosbridge_websocket_launch.xml
   

At this point, if I expose the robot’s IP address, I can control it from the iOS app through the websocket URL: ws://robot-ip-address:9090. However, I am not comfortable making my robot’s IP address public.

After exploring various options, I chose the “Reverse SSH Tunnel” method. It is similar to a Cloudflare tunnel but is self-hosted on a cloud compute instance. Since I already use a cloud instance as the media relay server for video streaming (Live Video Streaming of Security Robots), this approach fits well with my robot’s deployment architecture.

Here is the command I run on the robot to create a reverse SSH tunnel that opens an outbound WebSocket connection to the cloud server.

ssh -N -R 10000:localhost:9090 user@cloud-server-ip

Explanation of the argument -R 10000:localhost:9090:

• “-R” is reverse port forwarding. This means we open port 10000 on the cloud server and forward all traffic to port 9090 on the robot.
• “localhost” refers to the robot where this “ssh” command runs.
• The rosbridge only listens locally on port 9090 on the robot. It is not accessible from the outside.

The SSH tunnel disappears if the robot reboots or the network drops. Therefore, I have a stream_control.py program that dynamically opens and closes the tunnel based on whether the user goes live on the robot.

Cloud Server

The cloud server here functions solely as a relay and is not a ROS node. For simplicity, there is no ROS component on the cloud server.

Once the Reverse SSH Tunnel is established on the robot, any traffic on the cloud server’s port 10000 is automatically forwarded to the robot’s rosbridge.

However, there are two issues:

1. the WebSocket traffic isn’t encrypted
2. the firewall rule for the cloud instance includes ingress on port 10000.

To improve security, I will use Nginx to terminate the TLS WebSocket connection and upgrade/forward the WebSocket frames to the rosbridge tunnel at port 10000.

Here is the corresponding Nginx configuration:

server {
    listen 443 ssl;
    server_name cloud-server-domain.com;

    # SSL cert paths
    ssl_certificate ...
    ssl_certificate_key ...

    location /rosbridge/ {
        proxy_pass http://127.0.0.1:10000/;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # prevents 101 switching errors
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

This simple configuration encrypts WebSocket traffic over the internet, with only the standard HTTPS port open on the cloud server. Messages to the URL “/cloud-server-domain.com/rosbridge” are forwarded to port 10000, which automatically tunnels to the robot’s ROS Bridge at port 9090.

Droid Vision iOS app

Now, the iOS app can connect to wss://cloud-server-domain.com/rosbridge to send commands to the “/cmd_vel” topic, which the robot uses to control its driving speed and direction.

Conclusion

This approach is highly secure because:

• The robot is never exposed to the internet.
• SSH encryption secures the tunnel and WebSocket connection.
• Only HTTPS port 443 is open on the cloud server.
• The cloud relay can restrict what the user can do to the robot.

Here is a quick summary of what each component does:

Robot

• Runs ROS2
• Runs rosbridge on port 9090 locally
• Opens an SSH reverse tunnel between the robot and the remote cloud server.

Cloud Server

• The cloud server functions solely as a pass-through, not as a ROS node. It relays messages to the robot via the SSH tunnel.
• It provides a secure WebSocket connection for the mobile app.

iOS app

• Sends ROS commands to the robot by invoking the secure cloud server URL.

In addition to personal interests, in the era of AGI, wealth is predominantly generated through equity market investments.

A Stock AI Agent

That said, I don’t always have time to watch live stock charts. That makes me want to create a stock app where AI agents analyze the charts and relate them to market sentiment to give trading insights.

Additionally, in many ways, trading stocks is more of a psychological game than a numbers game. Therefore, using AI agents to recommend stock actions can be helpful during major pullbacks when everyone is scared, as well as at market peaks when everyone is greedy. AI has a much calmer mind than we humans. :)

I have a few stocks to start with, but I’d love to add more to the list as the AI agent researches and recommends new stocks in sectors that interest me.

Architecture

Here’s a brief overview of the architecture. The benefit of agent-based design is that:

1. It is modular, flexible, and with expert stock analyst intelligence.
2. This design supports the “in the loop” evaluation, enabling the Orchestrator agent to oversee and critique the output of other agents, promoting reflection - a key aspect of the agentic reasoning pattern that helps improve performance.
3. Additionally, the logging agent records the stock’s insights and feedback to facilitate ongoing iterative review and improvement.

Here are the responsibilities of each agent:

• The Orchestrator Agent initiates the flow (e.g., on schedule or event).
• It instructs the Technical Analysis Agent and Sentiment Agent to analyze the stocks.
• The Technical Agent contacts the Market Data Agent for stock data, and the Sentiment Agent uses the News Agent to fetch news data for the stocks.
• The Orchestrator Agent combines all signals and makes a recommendation.
• All insights are logged by the Logging Agent.

The word “agent” is a general term here. It can refer to a large language model (LLM) or an entity that performs specific tasks. For example:

• The “Technical Analysis Agent” is a large language model. It calculates various technical indicators for stocks and uses reasoning to provide a technical assessment.
• Conversely, the “Market Data Agent” retrieves stock data from the stock exchange.

Technologies

I use ChatGPT-5 as the large language model (LLM) and LangGraph as the agent framework. The AI agent is built with Python and Angular. The web user interface is developed entirely through Cursor, an AI-assisted coding tool.

The agent functions as a REST service with endpoints for on-demand stock analysis requests. It also runs the “watchlist” job in the background to automatically generate insightful alerts for the user.

The Stock Analyzer AI Agent

Here is the Stock Analyzer, the AI agent that offers professional stock technical insights and market sentiment analysis.

In addition to “Quick Insights,” the user can also chat with the agent about specific stock topics. Unlike a generic chatbot, the agent has access to the stock’s charts and the latest news, so it can provide the user with solid data points for quick decision-making.

Testimony

Palantir (PLTR)

Two days before Palantir’s earnings report, the Stock Analyzer’s insights recommended holding the position and not trimming it. It also noted that news headlines reinforced the technical outlook and supported a bullish run. After the earnings report, PLTR stock surged by 22%, from $154 to $188.

Then, on Friday, August 08, the Analyzer recommended that I trim slightly and take some profits because the stock was strongly overbought. One week later, the stock dropped 6% to $177. Ten days later, on August 19, PLTR sits at $157, 16% down from the price point where the Stock Analyzer recommended trimming.

Oklo Inc. (OKLO)

On September 25, the Stock Analyzer Agent recommended that I trim my OKLO position modestly at $131, as the OKLO chart indicates a loss of momentum and signals a potential distribution following the big run.

This proved to be a very helpful tip. The OKLO stock fell more than $21, closing at $110 over the next two trading days. Additionally, CNBC later reported that “Oklo has also seen a cluster of insider selling over the past few days”, which matches my AI agent’s speculation based on the chart.

Cheers!

However, to use the robot as a security camera, I am away from home, and the robot’s IP address is not visible from the phone. How can I monitor my home in real-time while I am away? Exposing the robot’s IP address poses a significant security risk and is not an option.

Relay the Video using a Public Media Server

The solution is to use a public server to relay the video: the video stream from the robot is sent to a cloud server, which then re-publishes the stream to the mobile device. This way, the robot can stay within the private network with all the safety and security, while its video is accessible from a public media server protected by credentials and a firewall.

All video data sent to the server is in memory and passes through. Nothing is stored unless recording is requested.

MediaMTX Media Server

A standard relay option is using an RTMP media server. RTMP is a protocol designed for streaming audio, video, and data over the internet, especially with low latency. It allows live video and audio from a source (such as a camera) to be sent to a platform (like YouTube Live or Twitch) for viewers to watch in real-time.

The RTMP media server I use is MediaMTX, an open-source solution that supports live streaming via RTSP, HLS, and WebRTC. Therefore, the Droid Vision app can continue using RTSP, and I just need to change the RTSP URL to the public media server: rtsp://PUBLIC_CLOUD_SERVER:8554/live/stream.

MediaMTX is easy to run. I can run it as a Docker container or download and run its binaries. The binary download page is on GitHub.

Here’s the output from MediaMTX. I used the MediaMTX Docker container. When the robot publishes the video to the MediaMTX server, message “[conn :34668] is publishing to path ‘live/stream’" is printed to the screen. When the Droid Vision app contacts the media server for the video stream, the message "[session ] is reading from path ‘live/stream’" is displayed.

% docker run --rm -it --network=host bluenviron/mediamtx:latest

025/07/07 21:02:36 INF MediaMTX v1.13.0
2025/07/07 21:02:36 INF configuration loaded from /mediamtx.yml
2025/07/07 21:02:36 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2025/07/07 21:02:36 INF [RTMP] listener opened on :1935
2025/07/07 21:02:36 INF [HLS] listener opened on :8888
2025/07/07 21:02:36 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2025/07/07 21:02:36 INF [SRT] listener opened on :8890 (UDP)
2025/07/07 21:03:01 INF [RTMP] [conn <robot ip>:34668] opened
2025/07/07 21:03:03 INF [RTMP] [conn <robot ip>:34668] is publishing to path 'live/stream', 1 track (H264)
2025/07/07 21:03:10 INF [RTSP] [conn <mobile device ip>:62634] opened
2025/07/07 21:03:10 INF [RTSP] [session c7b3d9d8] created by <mobile device ip>:62634
2025/07/07 21:03:11 INF [RTSP] [session c7b3d9d8] is reading from path 'live/stream', with UDP, 1 track (H264)

Video Stream pushes to the Media Server

Here is the GStreamer pipeline for the robot to publish the video stream to the media server. Please replace PUBLIC_CLOUD_SERVER with your server’s IP address in the cloud.

gst-launch-1.0 libcamerasrc ! \
  video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! \
  videoconvert ! \
  queue ! \
  x264enc tune=zerolatency speed-preset=ultrafast bitrate=1500 ! \
  queue ! \
  flvmux streamable=true name=mux ! \
  queue ! \
  rtmpsink location="rtmp://PUBLIC_CLOUD_SERVER/live/stream"

Here is the corresponding Python code “push_rtmp.py” for the robot. Either method can publish the video stream to the RTMP server.

import gi

gi.require_version('Gst', '1.0')
from gi.repository import Gst, GLib

class RTMPPush:
    def __init__(self):
        Gst.init(None)

        self.rtmp_url = "rtmp://PUBLIC_CLOUD_SERVER/live/stream"

        self.pipeline = Gst.parse_launch(
            f"""
            libcamerasrc !
            video/x-raw,format=YUY2,width=640,height=480,key-int-max=30,framerate=30/1 !
            videoconvert !
            queue !
            x264enc tune=zerolatency speed-preset=ultrafast bitrate=1500 !
            queue !
            flvmux streamable=true name=mux !
            queue !
            rtmpsink location={self.rtmp_url}
            """
        )
    def run(self):
        self.pipeline.set_state(Gst.State.PLAYING)
        loop = GLib.MainLoop()
        loop.run()

if __name__ == "__main__":
    pusher = RTMPPush()
    pusher.run()

RTMP is very efficient, and MediaMTX is just a relay. Additionally, the receiving pipeline on the Droid Vision app uses UDP, which is extremely fast. So, there’s no noticeable delay when using the MediaMTX server to route the video stream.

Video Stream fetched for the Droid Vision app

As mentioned earlier, we will continue to use RTSP to stream video to the mobile app. Therefore, the Droid Vision app only needs a URL update. The new URL is now: rtsp://PUBLIC_CLOUD_SERVER:8554/live/stream.

Protect MediaMTX with credentials

By default, MediaMTX has no authentication — anyone who knows its RTSP/RTMP/HLS URL can push or pull. So it’s essential to protect it, especially when it runs in the public cloud.

MediaMTX has built-in user/password auth for:

• Publishers
• Readers/viewers

I configured users and passwords in the mediamtx.yml file. The credential applies to all paths.

# mediamtx.yml
paths:
  all_others:
    # protect push
    publishUser: mypublisher
    publishPass: secret123

    # protect pull
    readUser: myviewer
    readPass: view456

To run the docker container with the updated yaml file, I mount the local “mediamtx.yml” into the container:

% docker run --rm -it --network=host \
    -v /path/to/local/config/mediamtx.yml:/mediamtx.yml \
    bluenviron/mediamtx:latest

When publishing or reading the stream, I include the credentials in the URL. For example, on the robot, I change the rtmp_url of the RTMPPush class to:

MEDIA_SERVER = os.getenv("MEDIA_SERVER")
MEDIA_PUBLISH_USER = os.getenv("MEDIA_PUBLISH_USER")
MEDIA_PUBLISH_PASS = os.getenv("MEDIA_PUBLISH_PASS")

self.rtmp_url = f"rtmp://{MEDIA_SERVER}/live/stream?user={MEDIA_PUBLISH_USER}&pass={MEDIA_PUBLISH_PASS}"

The Droid Vision app has been updated so users can configure the “Use Media Server” option with the media server’s username and password as separate fields. The app automatically inserts these credentials into the URL.

This method of protection is straightforward but not ideal for large-scale or highly secure applications because it uses hardcoded credentials. Therefore, MediaMTX offers alternative methods that utilize external authentication. For more information, please see the MediaMTX product site.

On-Demand Video Streaming

With a security camera, another critical feature is on-demand video streaming. Instead of streaming video continuously, the robot streams only when it detects something or when the user requests.

Media Control Server (Polling)

A quick solution is for the robot to run a small control client that periodically polls the cloud server for the streaming state, as requested by the mobile app.

MQTT Broker (Messaging)

The second approach involves using Message Queuing Telemetry Transport (MQTT) for push notifications: set up a public cloud MQTT broker. The robot subscribes to a specific MQTT topic, while the mobile app publishes start or stop messages to that topic.

Compared to the previous solution, this method eliminates polling, allowing the robot to react instantly. It also scales well to many cameras. MQTT is widely used for smart cameras, doorbells, drones, and other devices, which is why I chose this approach for my security robot.

Media Bridge Server

To use messaging in the mobile app, I need to make some deployment adjustments: instead of sending start/stop commands directly from the mobile app, which would require embedding the MQTT Swift client library, I use a cloud-based bridge server. The bridge server is an HTTP server that posts start/stop messages to the MQTT broker.

This setup keeps the Droid Vision app simple - it can use HTTP requests to start and stop the robot’s streaming through the bridge server rather than sending direct messages by embedding the MQTT client library.

1. Install and Config the Mosquitto MQTT Broker on the Cloud Server

Update packages, install, and configure Mosquitto MQTT broker:

sudo apt update
sudo apt install mosquitto mosquitto-clients -y

# Enable and start Mosquitto service
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

# add password auth
sudo mosquitto_passwd -c /etc/mosquitto/passwd mymqttuser
# Enter password when prompted

Create Mosquitto config /etc/mosquitto/conf.d/default.conf as the “root” user:

allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 0.0.0.0

Restart Mosquitto for the config changes:

sudo systemctl restart mosquitto

2. FastAPI Media Bridge on the Cloud Server

Install FastAPI and MQTT client:

# Create virtual environment:
python3 -m venv venv
source venv/bin/activate

# Install FastAPI and MQTT client
pip install fastapi uvicorn paho-mqtt

Python code bridge.py for the media bridge server. The APIs use the “x_api_key” header for the Authentication.

import os
from typing import Optional

from fastapi import FastAPI, HTTPException
from paho.mqtt import publish
import uvicorn

app = FastAPI()

MQTT_BROKER = os.getenv("MQTT_BROKER", "localhost")
MQTT_PORT = int(os.getenv("MQTT_PORT", "1883"))
MQTT_USER = os.getenv("MQTT_USER")
MQTT_PASS = os.getenv("MQTT_PASS")
API_KEY = os.getenv("API_KEY")

def _publish(command: str, robot_name: str) -> None:
    auth: Optional[dict] = None
    if MQTT_USER and MQTT_PASS:
        auth = {"username": MQTT_USER, "password": MQTT_PASS}

    # Use robot-specific topic: robots/{robot_name}/stream
    topic = f"robots/{robot_name}/stream"

    try:
        publish.single(
            topic,
            command,
            hostname=MQTT_BROKER,
            port=MQTT_PORT,
            auth=auth,
        )
    except Exception as exc:  # noqa: BLE001
        raise HTTPException(status_code=502, detail=f"Failed to publish MQTT message: {exc}") from exc

def verify_api_key(x_api_key: Optional[str] = Header(None, alias="X-API-Key")) -> None:
    """Verify API key authentication."""
    if not API_KEY:
        # If no API key is configured, skip authentication
        return
    
    if not x_api_key or x_api_key != API_KEY:
        raise HTTPException(
            status_code=401, 
            detail="Invalid or missing API key. Include X-API-Key header."
        )


@app.get("/")
def index():
    return {"msg": "Media bridge service running!"}


@app.post("/robots/{robot_name}/stream/start")
def start(robot_name: str, _: None = Depends(verify_api_key)):
    _publish("start", robot_name)
    return {"msg": f"Published start for robot: {robot_name}"}


@app.post("/robots/{robot_name}/stream/stop")
def stop(robot_name: str, _: None = Depends(verify_api_key)):
    _publish("stop", robot_name)
    return {"msg": f"Published stop for robot: {robot_name}"}

Start FastAPI media bridge server in the Python virtual environment:

uvicorn bridge:app --host 0.0.0.0 --port 8000 --reload

Verify that the messages are sent by the bridge server:

mosquitto_sub -h localhost -u mymqttuser -P <mqtt passwd> -t "robot/stream"

For security reasons, the Media bridge must have SSL enabled. I prefer to use Nginx and generate the SSL certificate with Certbot. Nginx acts as a reverse proxy, forwarding stream commands to the FastAPI application. This way, the FastAPI port 8000 remains hidden behind the firewall, and the cloud instance exposes only the default HTTP ports, 443 and 80.

3. Streaming Control on the Robot

The Robot connects to the MQTT broker, waits for messages, and starts or stops GStreamer accordingly.

To begin, I install the “MQTT client” Python library on the robot.

# Create virtual environment:
python3 -m venv venv --system-site-packages
source venv/bin/activate

# install MQTT client
pip install paho-mqtt

Then I create stream_control.py that waits for messages from the “robot/stream” topic. If the message is “start”, it starts the video streaming on the robot and publishs it to the media server. If the message is “stop”, the robot stops streaming the video.

import os
import shlex
import subprocess

import paho.mqtt.client as mqtt

MQTT_BROKER = os.getenv("MQTT_BROKER")
MQTT_PORT = int(os.getenv("MQTT_PORT", "1883"))
MQTT_USER = os.getenv("MQTT_USER")
MQTT_PASS = os.getenv("MQTT_PASS")
ROBOT_NAME = os.getenv("ROBOT_NAME", "Robot1")

# Construct robot-specific topic: robots/{robot_name}/stream
MQTT_TOPIC = f"robots/{ROBOT_NAME}/stream"

MEDIA_SERVER = os.getenv("MEDIA_SERVER")
MEDIA_PUBLISH_USER = os.getenv("MEDIA_PUBLISH_USER")
MEDIA_PUBLISH_PASS = os.getenv("MEDIA_PUBLISH_PASS")

RTMP_URL = f"rtmp://{MEDIA_SERVER}/live/stream?user={MEDIA_PUBLISH_USER}&pass={MEDIA_PUBLISH_PASS}"

GST_PIPELINE = f"""
libcamerasrc ! \
  video/x-raw,format=YUY2,width=640,height=480,framerate=30/1 ! \
  videoconvert ! \
  queue ! \
  x264enc tune=zerolatency speed-preset=ultrafast bitrate=1500 ! \
  queue ! \
  flvmux streamable=true name=mux ! \
  queue ! \
  rtmpsink location="{RTMP_URL}"
"""

gst_process = None

def on_connect(client, userdata, flags, rc):
    print(f"Connected with result code {rc}")
    print(f"Subscribing to topic: {MQTT_TOPIC}")
    client.subscribe(MQTT_TOPIC)

def on_message(client, userdata, msg):
    global gst_process
    payload = msg.payload.decode()
    print(f"Received: {payload}")

    if payload == "start":
        if gst_process is None:
            print("Starting GStreamer...")
            gst_process = subprocess.Popen(
                shlex.split(f"gst-launch-1.0 {GST_PIPELINE}"),
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE
            )
        else:
            print("Stream already running.")

    elif payload == "stop":
        if gst_process is not None:
            print("Stopping GStreamer...")
            gst_process.terminate()
            gst_process = None
        else:
            print("No stream to stop.")

client = mqtt.Client()
if MQTT_USER:
    client.username_pw_set(username=MQTT_USER, password=MQTT_PASS)
client.on_connect = on_connect
client.on_message = on_message

client.connect(MQTT_BROKER, MQTT_PORT, 60)
client.loop_forever()

Finally, let’s start the robot’s stream control in the Python virtual environment.

python stream_control.py

With that, the robot now waits for the start/stop command for video streaming.

4. Start or Stop Streaming using the Droid Vision App

Last but not least, in the Droid Vision app, I configure the media server API key and tap “Go Live View” to start the streaming request on the robot. Closing the streaming view stops the video streaming from the robot.

All in One Picture

Putting video relay and on-demand streaming together:

Cheers!

A year ago, I had someone install a dry riverbed along the water path to help manage rainwater. The riverbed is made of rocks of different kinds and colors. It loops around the house and directs the water to the backyard and down the hill. Besides its practical use, the riverbed also adds visual interest to the backyard.

Garden Bridges

The drainage problem has been solved, but it introduced a new issue. The yard is now split into two sections. To open the backyard gate, we must walk on the rocks, which disrupts the layered structure of the riverbed. To mow the lawn, my husband has to lift the lawnmower over the rocks. This makes me want to build a garden bridge that is large enough for a lawnmower and a person to cross easily, but small enough to stay roughly within the bounds of the dry riverbed.

Tools and Materia

I have some 2x6 construction heart redwood lumber from the previous decking project. I also kept pallet boards from the Tesla Powerwall and solar panels. The pallet wood is treated and sturdy, making it perfect for the bridge’s foundation. The California redwood is beautiful and unique in this Texas Hill Country since the coastal redwood is exclusive to the American West Coast and has to be transported to Texas. I also have galvanized nails and decking screws from the earlier project. So, I have most of the materials needed to build the garden bridge. I only need to buy the paint and brackets.

Regarding the tools, I need a miter saw to cut lumber to specific lengths. I also need a jigsaw for making curves, along with a drill, impact driver, sander, hammer, rafter square, tape measure, pencils, and a paintbrush. I purchased these tools during the decking project and plan to reuse them for future woodworking. I enjoy woodworking because it requires creativity, artistry, and engineering precision.

Design and Measurement

A flat bridge is easy to build, but an arched one is much more visually appealing. To create an arch on the wood, I used a thin, flexible piece of metal and traced along it. I use small nails to hold the metal piece on the board, making it easy for me to trace. The 3B drawing pencil is best for marking on wood because of its darkness and precise lead.

I use a board to connect the two arched boards to create an H-shaped base for the bridge. My lawnmower is 23 inches wide, so I designed the surface area of the bridge to be 27 inches wide, with an inch overhang on each side of the bridge. Since the board is 1.5 inches thick, the cross board must be 22 inches long - 27 - 1*2 - 1.5*2 = 22.

I cut the redwood boards to 27 inches, and one of the pallet boards to 22 inches long. Once cut, all boards need to be stained and sealed. I like to wash the boards before painting them because it removes dirt and mold and gives the wood a fresh, new look.

Installation

To connect the two arched boards, I use galvanized nails with metal brackets. I learned this from my decking project, where galvanized nails are used for all joist hangers and joints because they protect against corrosion and offer superior shear strength, supporting the weight and resisting movement. Before driving in the nails, I pre-drilled the holes to prevent the wood from splitting. It also makes the nails go in easier. I asked ChatGPT, and it suggested using a 1/8 drill bit for the 10D galvanized nails.

To create a precise one-inch overhang on both sides of the bridge, I marked one-inch on the boards so that when I install them onto the base, I can check if both sides are even. To secure the boards, I measure and pre-drill the holes to avoid splitting.

I set the impact driver’s setting to “1” so it does not overpower the screws. Once the screws are in, I change the setting to “2” so I can push the screws slightly below the wood surface to create a finished look.

Backyard Time

Check out my backyard! I’ve constructed two bridges, one before and one after the gate.

Cheers!

MGRS GPS is an app that gives your location using the MGRS coordinate system, your heading, speed, and elevation.

Waypoints can save and display on the map as you navigate.

If enabled, waypoints are saved to iCloud and can be accessed from all your devices. Allowing you to do things like save on your iPhone and then edit on your iPad later.

All of your waypoints can be exported to a kml file allowing you to display them on applications like Google Earth.

Download the MGRS GPS from the App Store.

Get to Know the SLAM Toolbox

The Nav2 (Navigation 2) stack is a modular system that enables autonomous navigation for mobile robots in the ROS framework. The SLAM Toolbox, which stands for Simultaneous Localization and Mapping, plays a crucial role in the navigation stack and is part of ROS Navigation 2.

The SLAM Toolbox is a 2D mapping and localization system based on LiDAR data and odometry. It is the first two steps of the Nav2 pipeline, which are: 

1. Mapping: generating and publishing the map of the environment
2. Localization: using the saved map to localize the robot in the known environment
3. Planning: computing the path from the current pose to the goal
4. Control: following the path using velocity commands
5. Recovery: handling failure conditions, such as scenarios where the robot gets stuck

Mapping

The SLAM Toolbox enables the robot to generate a map of an unknown environment while tracking its position on that map in real time. SLAM Toolbox builds a 2D occupancy grid map using the robot’s laser scans and motion data.

Here is the kitchen map created by my robot, R4, as it circled the kitchen using the Droid Vision app.

The tool that displays the map is RViz2, which is a 3D visualization tool within the ROS 2 framework. RViz2 enables users to view and interact with a robot’s state, sensor data, and environment in a 3D space. It provides a window into the robot’s world, illustrating what the robot “sees” and how it is positioned.

The generated map can be saved in RViz2 using the “slam_toolbox” panel. This panel contains the “save” and “serialization” options, where the “serialization” format is intended for use by the SLAM Toolbox itself, while the “save” format allows the map to be utilized by other Nav2 localization tools, such as Adaptive Monte Carlo Localization (AMCL).

Mapping is the first step of the navigation pipeline, and SLAM Toolbox plays a crucial role in map generation.

Localization

The SLAM Toolbox is also a localization system that identifies the robot’s position and orientation (pose) within its perceived world.

To explain the concept of “Localization” in ROS, we must discuss the ROS Frame and Transform.

Frame

• A Frame refers to a 3D coordinate system used to define the spatial location and orientation of an entity (like a robot, sensor, or object) in space.
• The odom Frame is the starting point of the robot’s trajectory. As the robot moves, its pose changes in the odom frame based on odometry data.
• The base_link Frame is a fixed frame attached to the robot’s chassis or main body. It serves as a reference point for other robot frames, such as wheels and lidar sensors.

The ROS coordinate frame follows the Right-Hand Rule, where X goes forward from the robot’s center, Y goes to the left, and Z rises upward, perpendicular to the floor.

Here are the frames of my mobile robot, as seen in RViz, with red representing the X-axis, green representing the Y-axis, and blue representing the Z-axis. Every joint defined in the robot’s URDF has a frame.

Transform chain

What is Transform in ROS?

• Transform(TF) represents the position and orientation of a coordinate frame relative to another. It’s a fundamental concept in ROS that describes how objects and coordinate systems are positioned in 3D space, enabling systems to understand the relative positions of various components and their interactions.

A typical Transform chain for mobile robots looks like this:

map → odom → base_link → laser_frame

Each transform has a purpose:

• The odom → base_link comes from the wheel encoder or other local sensors. It tracks how far the robot has moved from its starting point. It is fast to compute, continuous but accumulates drift over time.
  
  To correct for odometry drift, a higher-level system like SLAM Toolbox computes the robot’s true global pose and broadcasts.

• The map → odom comes from the SLAM Toolbox and provides global correction to the drifting odometry.
  
  The SLAM Toolbox estimates the robot’s pose in the global map frame based on laser scans and odometry data. It uses this information to compute a correction transform and broadcasts it as the map → odom transform. This allows the robot’s current global position to be determined as base_link in the map frame.

The “map → odom” transform is essential for:

1. RViz visualization: the robot appears in the correct position on the map.
2. Path planning: the global planners can compute paths from the robot’s actual location.
3. Localization: the robot can recognize when it returns to a previously visited location, known as loop closure.

In summary, the SLAM Toolbox broadcasts the map → odom transform to anchor the robot’s local odometry in the global map frame. This corrects for drift and ensures accurate global navigation. Without this transform, Nav2 cannot correctly localize the robot or plan valid paths.

With the SLAM Toolbox for mapping and localization, the navigation server performs the remaining steps of planning, control, and recovery in the navigation pipeline.

Meet Robot R4

This is my Differential Mobile Robot featuring two independently driven wheels and two caster wheels for balance. The Differential Bot moves forward or backward by rotating both wheels in the same direction, and it can rotate in place by spinning the wheels in opposite directions.

At the top of the robot is the RPLidar, which generates the scan data. I have a blog RPLidar in ROS 2 Docker on Raspberry Pi that details how to configure and run the Lidar nodes on a real robot. Please check that out.

Robot Mapping

To run the robot that generates maps, we need a ROS environment that includes the robot module, the RPLidar driver, the navigation stack, the rosbridge suite, and many other dependencies. The most straightforward approach is to use a Docker container. Docker simplifies deployment and makes the environment portable, consistent, and shareable.

A Docker Container

A Docker container is created from a Docker image, which serves as a template defining its structure and dependencies. Docker is widely used in enterprise software’s microservice architecture, but is relatively new in robotic applications. I have a blog, RPLidar in ROS 2 Docker on Raspberry Pi, which explains in detail how to use a Docker container in a robot.

The Dockerfile I prepared for my robot can be downloaded from here: Dockerfile and requirements.txt. The Docker image created from the Dockerfile includes all the necessary ROS 2 modules, Python libraries, and source code repositories. Access to the private Git repository is granted using an SSL key.

We can build the Docker image and start the Docker container using the following commands. Building the Docker image compiles the source code and creates the bot environment. You only need to build the image once and can reuse it to start the Docker container whenever needed.

# build the docker image "my_bot_image"
docker build -t my_bot_image .

# start the docker container from the image
docker run -it --network=host --ipc=host -v /dev:/dev \
    --device-cgroup-rule='c 188:* rmw' \
    --device-cgroup-rule='c 166:* rmw' \
    my_bot_image

Commands to Run the Robot Mapping

I launch the robot, the PRLidar, and the SLAM toolbox in the Raspberry Pi’s Docker container.

Additionally, I start the “rosbridge_server” because I use the Droid Vision app to view and control my robot remotely from my phone. Please see the article Droid Vision with built-in Joystick and Keypad for more information. If you prefer the traditional ROS teleop_twist_keyboard or teleop_twist_joy for remote control, feel free to use those and skip launching the rosbridge_server.

# 1. Start the robot itself
ros2 launch my_bot robot.launch.py

# 2. Start the robot's LiDAR scan
ros2 launch rplidar_ros rplidar_c1_launch.py serial_port:=/dev/ttyUSB0 frame_id:=laser_frame

# 3. Start the slam toolbox to create the map 
ros2 launch slam_toolbox online_async_launch.py use_sim_time:=false

# 4. Start the rosbridge_server for the Droid Vision Teleop
ros2 launch rosbridge_server rosbridge_websocket_launch.xml

On the Linux development machine, I launch RViz to visualize the robot in its world.

# 1. Launch RViz
rviz2 -d ~/dev/dev_ws/src/my_bot/config/view_bot_map.rviz

Cheers! :D

Motor Driver

I select motor drivers based on the motor’s specifications, particularly its rated voltage and current. Additionally, I also consider the motor driver’s size and mounting methods. If I build a tiny robot, I must use a tiny motor driver.

To control the motor’s direction, we commonly use a design called an “H-Bridge”, which consists of four switches (typically transistors) arranged in an “H” pattern, with the motor connected between the center points of the left and right legs. By turning on specific pairs of switches, current flows through the motor in one direction or the other, allowing it to spin forward or backward.

To control motor speed, we use PWM (Pulse Width Modulation) on the motor driver’s PWM input pin. PWM works by rapidly switching the motor’s power on and off and adjusting the duty cycle — the percentage of time the signal is HIGH versus LOW. A higher duty cycle (e.g., 80%) means the motor receives more power and spins faster, while a lower duty cycle (e.g., 30%) slows it down. In Arduino, this is done using the analogWrite function, where the value ranges from 0 (off) to 255 (full speed).

Examples of H-Bridge Motor Drivers. All of them have two channels for controlling two DC motors.

• L298N: supports motor voltage 5V - 35V and continuous current up to 2A.
• TB6612FNG: a tiny module. It supports motor voltage 4.5V - 13.5V and continuous current up to 1.2A.
• MX1508: an ideal choice for tiny motors. It supports motor voltage 2V - 10V and continuous current up to 1.5A.

L298N Dual H-Bridge

The L298N is a popular dual H-bridge motor driver that can control the speed and direction of two DC motors. It operates at voltages up to 35V and can handle up to 2A per channel, making it suitable for small to medium-sized motor control applications. It is very affordable, widely available, and easy to use.

The L298N uses bipolar junction transistors (BJTs) in its H-bridge design, which are less efficient than MOSFETs, resulting in more heat and significant voltage drop. Typically, a single bipolar transistor experiences a drop of approximately 0.7 volts. When two transistors are employed simultaneously in an H-Bridge configuration, the total drop is estimated to be around 1.4 volts. Consequently, if a 9-volt supply is applied to the H-Bridge, the motor will actually receive only 7.6 volts.

Another problem I face when using the L298N is that it is bulky and requires messy wiring to connect the necessary L298N pins to the Arduino. Here are the pins that must be connected:

• EnableA, EnableB (connect to Arduino’s PWM pins to control the motor’s speed)
• IN1, IN2, IN3, IN4 (control the motor direction)
• 5V logic voltage, GND

TB6612FNG Dual H-Bridge

The voltage drop, heat generation, and bulky size led me to explore other Dural H-Bridge motor drivers.

TB6612FNG features a newer, more efficient design, utilizing MOSFETs for switching, which results in a lower voltage drop and higher efficiency. Overall, TB6612FNG is smaller, cooler, and more efficient, making it a better choice for most projects unless higher voltage tolerance is needed from L298N.

Regarding the wiring, TB6612FNG uses the same pins as L298N and can serve as a drop-in replacement for L298N.

Here are L298N and TB6612FNG side by side; TB6612FNG is less than one-fifth the size of L298N.

Motor Shield

An Arduino Motor Shield is an add-on board (or “shield”) that plugs directly onto an Arduino to make it easy to control DC motors, stepper motors, and servos. It contains motor driver chips, such as the L298N or TB6612FNG, that handle the high current and voltage required by motors, which the Arduino alone cannot supply.

The shield simplifies wiring and programming by using a standard pin layout, and many shields come with Arduino libraries to make coding easier.

Meet the OSEPP TB6612 Motor Shield

The OSEPP TB6612 Motor Shield uses two TB6612FNG dual H-bridge driver chips, allowing independent control of up to four DC motors (M1–M4). All pins from the shield are already connected to the Arduino once the shield is stacked onto the Arduino board, removing eight wires from the configuration.

Here are the pictures of the updated wiring. I replaced the L298N motor driver with the TB6612 motor shield. Once I connect the motors to the motor shield using the wire clips, I don’t need any additional wires to control the motor. The four wires on the motor shield are for the motor encoders, not for the motors themselves.

The motor shield has convenient “V” and “G” rails to provide the 5V Logic Voltage and GND for the encoders and sensors. However, they are NOT directly connected to Arduino’s 5V/GND rails, so be careful when using them. More details will be discussed in the next section on how to use them correctly.

Troubleshooting Lessons, Common Pitfalls

Once the wires are cleaned up, the next step is to update the code to make it work again. I struggled with that for a couple of days, and here are some crucial details I learned about using the TB6612 Motor Shield.

Dedicated Arduino Digital Pins

Unlike a standalone motor driver, the OSEPP TB6612 motor shield has a Driver Schematic, which indicates that each H-bridge connects to dedicated Arduino digital pins for direction and PWM control, with motor power supplied through a VIN terminal and routed internally to the driver chips’ VM pins. This means I need to update the Arduino sketch to use those specific pins for motor direction and PWM control.

The STBY (standby) pins are internally connected to 5V, keeping both motor drivers active by default. This design integrates neatly with Arduino UNO headers, requiring no external wiring for basic motor control.

Each type of shield has its schematic. Grok or ChatGPT are currently not aware of it and hallucinate heavily. For example, they believe the reason the code is not working with the TB6612 motor shield is that the STBY pin is not set to HIGH and insist I run a jumper wire to connect pin 10 to 5V since pin 10 is usually the STBY pin. :D

PWM with One DIRECTION Input

From the OSEPP example code, I learned that I only use one pin to control the direction, unlike L298N or TB6612FNG, which use two input pins for the direction. Therefore, to stop the motor, I must set PWM to 0 rather than setting the input pins to LOW.

Here is the Arduino sketch I created to test the DC motor with the OSEPP TB6612 Motor Shield:

// Motor M1 (Motor A)
int enA = 11;    // PWM speed control
int dirA = 8;     // DIRECTION control

// Motor M2 (Motor B)
int enB = 3;     // PWM speed control
int dirB = 12;    // DIRECTION control

void setup()
{
  // Set all the motor control pins to outputs
  pinMode(enA, OUTPUT);
  pinMode(enB, OUTPUT);
  pinMode(dirA, OUTPUT);
  pinMode(dirB, OUTPUT);

  Serial.begin(9600);
}

// Run the motors in both directions at a fixed speed
void loop()
{
  // Run Motor M1 and M2 forward
  Serial.println("Forward");
  digitalWrite(dirA, HIGH);
  analogWrite(enA, 150); // speed 0–255

  digitalWrite(dirB, HIGH);
  analogWrite(enB, 150); // speed 0–255
  delay(2000);

  // Reverse the motor directions
  Serial.println("Reverse");
  digitalWrite(dirA, LOW);
  digitalWrite(dirB, LOW);
  delay(2000);

  // Stop the motor
  Serial.println("Stop motors");
  analogWrite(enA, 0);
  analogWrite(enB, 0);
  delay(1000);
}

0 Volts at M1, M2?

OSEPP TB6612 Motor Shield has a toggle switch. Even if the shield’s VIN terminal is connected to a battery and the shield is powered, the motors are NOT powered until the shield’s switch is turned on. I was stuck on this and could not figure out why the motor did not spin until I noticed the switch on the shield.

The Power Puzzle: VIN, VM, and the “V” and “G” Rails

The motor shield includes logic rails labeled “V” and GND rails labeled “G” for powering encoders or sensors and exposes signal pins alongside them for convenient 3-pin connections. However, the pins on those rails are not directly connected to Arduino’s 5V/GND rails. They are only powered when the shield’s VIN terminal is connected to the battery and the motor shield switch is turned on. Otherwise, the encoder signal lines become “floating” and produce oscillating HIGH/LOWs.

The alternative is to use Arduino 5V and GND for a clean and stable reference voltage, which is what I ended up choosing in my setup.

Update to the ROS Arduino Bridge Sketch

I updated the ros_arduino_bridge repository to support the TB6612 motor shield and modified the encoder_driver to use analog pins A2-A5 for encoder readings. This repository serves as the hardware interface for the ros2_control of my robot car.

Cheers!

What is a Motor Encoder

A motor encoder is a sensor attached to a motor shaft that measures the rotation of the shaft. It converts mechanical motion into digital signals that a controller can interpret to manage the motor’s speed.

Recall from my blog “ROS 2 Control, Robot Control the Right Way” that I briefly touched on using motor encoders and ros2_control for a closed-loop robot system. In the following component diagram, the motor encoder contributes to the elements circled in red.

The Purpose of Motor Encoder in ROS

Odometry

In robotics, odometry (or odom for short) refers to the method of estimating a robot’s position and orientation over time based on sensor data from wheel encoders. In ROS, odometry is published as messages on the /odom topic. Specifically, encoders track how far each wheel has turned, and the ROS nodes utilize this data to estimate:

• Distance traveled
• Robot’s pose (position and orientation)
• Velocity

Feedback for Motor Control

The “diff_drive_controller” in ros2_control relies on encoder feedback for:

• Position control: Moving to a desired position.
• Velocity control: Maintaining a target speed.

The encoder data is part of the closed-loop system that adjusts motor commands in real time.

Joint State Publishing

The readings from the encoders assist in reporting the position, angle, and velocity of the left and right wheel joints through the /joint_states topic, allowing users to visualize the robot in tools like RViz. This is how my robot appears in RViz.

Upgrade DC Motors using Motor Encoders

I have several OSEPP DC motors that I used for different DIY robotics projects. These motors are high-quality, made from durable materials, and they provide high torque and a long motor shaft. They work well with the mechanical components of my robot.

I considered using a new pair of DC motors with built-in encoders to simplify the setup. However, the ones I found on Amazon do not have a long enough motor shaft to work with my robotic parts.

After careful consideration, I chose to reuse my existing DC motors and enhance them with the OSEPP Motor Encoder. This motor encoder comes with a datasheet and detailed assembly instruction. Furthermore, I appreciate the build quality of OSEPP products.

Quadrature Encoders

The OSEPP motor encoder is a quadrature encoder, a type of rotary encoder. It provides two output signals, Channel A and Channel B, that are 90° out of phase. This allows the system to determine:

1. Speed (the rate at which the motor is rotating).
2. Direction (If A leads B → clockwise. If B leads A → counterclockwise).

Test the Encoder Installation

After following the assembly instructions, I installed the encoder mount next to the motor’s magnet. I wired the encoders to the Arduino, and now it’s time to test the encoders’ readings.

I used the following Arduino program to check the readings.

#define ENCA A4 // Pin 2, A4
#define ENCB A5 // Pin 3, A5

void setup() {
  Serial.begin(9600);
  pinMode(ENCA,INPUT);
  pinMode(ENCB,INPUT);
}

void loop() {
  int a = digitalRead(ENCA);
  int b = digitalRead(ENCB);
  Serial.print(a*5); 
  Serial.print(" ");
  Serial.print(b*5);
  Serial.println();
}

If everything is installed and wired correctly, we should see “value A” and “value B” interlacing in the Serial Plotter when I manually rotate the wheel.

If the plot appears as a flat line or shows only one value oscillating while rotating the wheel, the issue may be related to the wire connection or the positioning of the encoder.

In my case, the problem was that the encoder mount was too far from the magnet. Additionally, the two channels were angled relative to the magnet. The A3144 sensor’s Channels A and B must be close to and parallel to the magnet’s side to detect the magnetic field while the motor shaft spins. Here is a picture of a properly installed motor encoder mount.

Encoder Count Per Revolution

To use the encoder in ROS2 Control, an important parameter is enc_counts_per_rev, which refers to the encoder counts generated for one full revolution of the wheel or motor shaft.

This parameter is defined in “ros2_control.xacro” and is used in the “read” and “write” functions of the hardware interface “DiffDriveArduinoHardware” to calculate the velocity command sent to the motor, as well as to compute the robot’s current pose and velocity.

Here is the “ros2_control.xacro”:

<?xml version="1.0"?>
<robot xmlns:xacro="http://www.ros.org/wiki/xacro">
    <ros2_control name="RealRobot" type="system">
        <hardware>
            <plugin>diffdrive_arduino/DiffDriveArduinoHardware</plugin>
			...
            <param name="enc_counts_per_rev">2000</param>
        </hardware>

Compute the enc_counts_per_rev

To determine the enc_counts_per_rev, I wrote an Arduino program that outputs the count after I manually rotate the motor shaft for one full revolution. I perform this rotation several times and calculate the average count, which gives me the enc_counts_per_rev of the motor.

#define ENC_A 2  // Encoder Channel A (Digital Pin 2)
#define ENC_B 3  // Encoder Channel B (Digital Pin 3)

volatile int pulseCount = 0;
bool counting = false;

void encoderISR() {
    if (counting) {
        pulseCount++;  // Increment count on each rising edge
    }
}

void setup() {
    Serial.begin(9600);
    pinMode(ENC_A, INPUT_PULLUP);
    pinMode(ENC_B, INPUT_PULLUP);
    
    // Attach interrupt for counting pulses
    attachInterrupt(digitalPinToInterrupt(ENC_A), encoderISR, RISING);
    
    Serial.println("Rotate the motor one full revolution and press ENTER.");
}

void loop() {
    if (Serial.available()) {
        Serial.read();  // Clear serial buffer
        
        pulseCount = 0;  // Reset pulse count
        counting = true;
        Serial.println("Start rotating the motor one full revolution...");
        
        delay(5000);  // Wait 5 seconds for manual rotation
        
        counting = false;
        Serial.print("Total pulses counted: ");
        Serial.println(pulseCount);
        
        Serial.print("Estimated CPR: ");
        Serial.println(pulseCount * 4);  // Multiply by 4 for quadrature encoders
        Serial.println("Press ENTER and rotate again.");
    }
}

Let robot dance in RViz

As mentioned earlier, one application of motor encoders is to help users visualize the robot using tools like RViz. Therefore, I created this robot dance clip. Cheers! :D

# start the robot on Raspberry Pi
ros2 launch my_bot robot.launch.py

# view the robot in rviz on the linux dev machine
rviz2 -d ~/dev/dev_ws/src/my_bot/config/view_bot.rviz