Rsewiki - User contributions [en]

Ricbot

2026-03-24T08:27:24Z

Jca: /* Library and examples */

== Ricbot, a wheeled sensor platform ==

Ricbot is intended for fast deployment to areas of interest.

Main features:
* Reused motors and wheels from an old "Elector Wheelie" platform
* Designed to fit into a normal car for deployment, i.e can be disassembled to no more than 55cm in height.
* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.
* Wheel-odometry recording (and timestamped)
* Camera image recording (and timestamped), the intention is Realsense D435.
* Maybe GNSS recording too.
* Manual remote control.

Tentative layout:

[[file: ricbot_on-shape.png | 500px]]

Length is 1m, free height 25cm, width 65cm.

== Installation notes ==

=== Camera position ===

[[file: ric-camera-position.png | 500px]]

Forward-looking camera: Intel RealSense D455, FOV 87 x 58 deg, range 0.6 to 6m.

Down-looking camera: Intel RealSense D435, FOV: 87 x 58 deg, range 0.3 to 3m.

=== Cabling ===

[[file: ric_cabling.png | 500px]]

DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042

Regbot 6.3: [[Regbot hardware board]]

[[RICBOT Power on-off board]] PCB

==== DRI0042 to Regbot 4-pin PWM ====

DRI Regbot PWM Software
7 GND (black) 1 GND --
4 PWM (red) 2 in1 PIN_xxxx_DIR
5 IN1 (white) 3 in2 PIN_xxxx_PWM
6 IN2 (yellow) 4 fault PIN_xxxx_FAULT
3 5V out

DRI0042 control values
IN1 IN2 PWM OUT1, OUT2 Motor Behavior
0 0 x Stop
1 1 x Vacant (relax)
1 0 1 Forward 100%
0 1 1 Reverse 100%
1 0 PWM Forward at PWM speed
0 1 PWM Reverse at PWM speed

==== Power control ====

Pin IDC10-pin Software Function
1 (black) 1 -- GND
2 (red) 3 LS_1 (pin 27) power off (when low) -- pt not working (wrong mod on power board)
3 (white) 4 LS_0 (A6) battery voltage (39k/4.7k)
4 (yellow) 6 LS_4 (pin 26) Alive LED

=== Intel RealSense ===

Install
sudo apt-get install automake libtool libusb-1.0-0-dev libx11-dev xorg-dev libglu1-mesa-dev
sudo apt install libssl-dev

There is a script to download and compile, e.g. on Raspberry Pi here:
https://github.com/realsenseai/librealsense/blob/master/doc/libuvc_installation.md

To install pyrealsense2 at the same time as librealsense, line 46 of the 'libuvc_installation.sh' build script should be changed from this:
cmake ../ -DFORCE_LIBUVC=true -DCMAKE_BUILD_TYPE=release
to this:
cmake ../ -DFORCE_LIBUVC=true -DCMAKE_BUILD_TYPE=release -DBUILD_PYTHON_BINDINGS:bool=true
From MartyG-RealSense on a pose here: https://github.com/realsenseai/librealsense/issues/13373

==== Library and examples ====

This is an alternative to the script above.

cd ~/git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..
make -j3
sudo make install

Copy udev rules to udev

cd ~/git/librealsense/config/99-realsense*.rules /etc/udev/rules.d/
udevadm control --reload-rules

All example commands start with rs-, e.g.:
rs-capture
rs-pointcloud

=== Teensy interface ===

The Teensy interface implements a bridge to MQTT, a motor controller (velocity and turn rate), and a remote control.

The configuration is in
/home/local/svn/teensy_interface/build/robot.ini

See also [[Robobot teensy interface]].

=== Start at boot ===

See the similar start setup in [[https://rsewiki.electro.dtu.dk/index.php?title=Enable_autostart#Autostart]].

Comment out (or delete) the start of the camera streamer (not compatible with RealSense 3D cam)

=== Install software on Raspberry Pi ===

Perform the same installation as [[Robobot install on Raspberry]], except for the serial port configuration (which should not be needed).

=== Teensy software ===

This is the Regbot software, configured to match the Ricbot.

See more details here [[Regbot firmware]].

=== Intel Librealsense ===

Installing support for Intel librealsense.

sudo apt install libssl-dev
sudo apt-get install freeglut3-dev
sudo apt-get install xorg-dev
cd git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..

I also needed to install libusb-1.0-0-dev
sudo apt install libusb-1.0-0-dev
This path was not included in the CMakeLists.txt, so I added this line at the beginning of the CMakeLists.txt:

cd librealsense
nano CMakeLists.txt
add
include_directories( /usr/include/libusb-1.0/ )
like here:
cmake_minimum_required(VERSION 3.10)

set( LRS_TARGET realsense2 )
project( ${LRS_TARGET} LANGUAGES CXX C )

# Allow librealsense2 and all of the nested project to include the main repo folder
set(REPO_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${REPO_ROOT})
'''include_directories( /usr/include/libusb-1.0/ )'''

include(CMake/lrs_options.cmake)
include(CMake/connectivity_check.cmake)
...

== ROS2 ==

From https://docs.ros.org/en/jazzy/Installation/Ubuntu-Install-Debs.html

Install
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F\" '{print $4}')

curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"

sudo dpkg -i /tmp/ros2-apt-source.deb

sudo apt update && sudo apt install ros-dev-tools

Install full ROS2 Jazzy

sudo apt install ros-jazzy-desktop

Start in this ROS2 environment, now and in new terminals:
source /opt/ros/jazzy/setup.bash
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
export ROS_DOMAIN_ID=0
echo "export ROS_DOMAIN_ID=0" >> ~/.bashrc

Install ROS QT GUI stuff
sudo apt install '~nros-jazzy-rqt*'

=== Create workspace ===

From https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html

Install colcon
sudo apt install python3-colcon-common-extensions

Create workspace directory
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws

From within this directory clone (any) standard package

e.g. tutorial examples
git clone https://github.com/ros2/examples src/examples -b jazzy

Build the examples; this is memory and CPU-hungry, so the option ''--executor sequential'' may come in handy, especially on a Raspberry Pi, but it will take significantly longer.
colcon build --symlink-install --executor sequential

Allow use of colcon_cd
echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc
echo "export _colcon_cd_root=/opt/ros/jazzy/" >> ~/.bashrc

To use the ''mixin'' shortcut for some colcon options, add:
colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml
colcon mixin update default

=== MQTT client ===

The un-modified ''mqtt_client'' package can act as a bridge between the ''teensy_interface'' and the ROS domain.

From MQTT to ROS, the translation is using the primitive ROS type ''string'' for the parameters of the ''teensy_interface'' messages.
The MQTT topic name is translated to ROS topic names as specified in the parameter file below.

From ROS to Teensy, the message should be published on a topic that matches the desired destination.
Topics for command messages to the ''teensy_interface'':
* MQTT topic ricbot/cmd/T0 for the Teensy, the message is the string to send to the Teensy.
* MQTT topic ricbot/cmd/shutdown to schedule a shutdown of the RICBOT (power off), something like 20 seconds after the message.
* MQTT topic ricbot/cmd/ti for messages to the teensy_interface, the message is a string.

==== Install ====

The robot's interface is via MQTT. Install the MQTT ROS client
sudo apt install ros-jazzy-mqtt-client

Or directly as source
cd src
git clone https://github.com/ika-rwth-aachen/mqtt_client

Compile:
cd ~/ros2_ws
colcon build

==== Run MQTT_client ====

To start the ''mqtt_client'':
cd ros2_ws/src/mqtt_client/mqtt_client/config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"
The parameter file should be extended with more ''mqtt2ros'' topics as needed.

This will launch the un-modified ''mqtt_client'' node with specific bridge parameters as specified in ''params.teensy.yaml'':
/**/*:
ros__parameters:
broker:
host: localhost
port: 1883
tls:
enabled: false
client:
id: ros
clean_session: true
keep_alive_interval: 20.0
bridge:
ros2mqtt:
ros_topics:
- /teensy/cmd/T0
- /teensy/cmd/shutdown
- /teensy/cmd/ti
/teensy/cmd/T0:
mqtt_topic: ricbot/cmd/T0
primitive: true
inject_timestamp: false
/teensy/cmd/shutdown:
mqtt_topic: ricbot/cmd/shutdown
primitive: true
inject_timestamp: false
/teensy/cmd/ti:
mqtt_topic: ricbot/cmd/ti
primitive: true
inject_timestamp: false
mqtt2ros:
# Needs to be expanded to relevant topics
mqtt_topics:
- ricbot/data/T0/info
- ricbot/data/T0/hbt
ricbot/data/T0/info:
ros_topic: /teensy/T0/info
primitive: true
ricbot/data/T0/hbt:
ros_topic: /teensy/T0/hbt
primitive: true

=== Test interface ===

Start the ''teensy_interface'' with the right ini-file:
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -z ricbot.ini

This should respond with something like:
$ ./teensy_interface -z ricbot.ini
# UService:: created directory log_20260118_083120.745/
# UMqtt:: connection to MQTT broker on tcp://localhost:1883 established
# UMqttIn:: connection to MQTT broker on tcp://localhost:1883 established
# STeensy:: opening to USB /dev/ttyACM0
# SRobot:: (t0) found IP 0: eno1 192.168.2.157
# STeensy:: just connected
# UService:: setup of Teensy 0 modules finished OK.
# Type quit to stop, or 'h' for help

Start the ''mqtt_client'' in ROS
cd ~/svn/ricbot/ros_config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"

==== From MQTT to ROS ====

There should now be ''hbt'' (heartbeat) message on the ROS side:
ros2 topic echo /teensy/T0/hbt

This should give something like:
data: '1768722645.7425 1738.4885 93 1748 4.85 0 9 18.1 0 0
'
---
data: '1768722646.2426 1738.9885 93 1748 4.85 0 9 18.0 0 0
'
---
data: '1768722646.7431 1739.4885 93 1748 4.85 0 9 18.0 0 0
'
---

The data is: timestamp (host), timestamp Teensy, Teensy ID, version, battery voltage, ... (the rest depend on the platform).

==== From ROS to MQTT ====

e.g. make the robot drive with velocity 0.25m/s and turn 0.1 rad/s CCV, followed by stop:

ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0.25 0.1'
ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0 0'

Or send a request to publish gyro data every 12ms:

ros2 topic pub /ricbot/cmd/T0 std_msgs/String 'data: sub gyro 12'

== (RIC_pkg) HW sensor translate package ==

Create the package in the workspace.

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_cmake --license MIT --node-name ric_node ric_pkg

Add dependencies to other packages to CMakeLists.txt.
Add to the list of ''find_package''

find_package(rclcpp REQUIRED)
find_package(std_msgs REQUIRED)
find_package(nav_msgs REQUIRED)
find_package(sensor_msgs REQUIRED)
find_package(geometry_msgs REQUIRED)

Make target dependencies available in the include path (and elsewhere as needed).

Add this after the ''add_executable''
ament_target_dependencies(talker rclcpp std_msgs nav_msgs sensor_msgs geometry_msgs)

To the package description ''package.xml'' add dependencies:

Add just after the ''buildtool_depend'' section:
<depend>rclcpp</depend>
<depend>std_msgs</depend>
<depend>nav_msgs</depend>
<depend>sensor_msgs</depend>
<depend>geometry_msgs</depend>

=== RIC_node code ===

The code in ''ris_node.cpp'' is pt this (not functional yet):

#include <cstdio>
#include <chrono>
#include <memory>
#include <string>

#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
#include "std_msgs/msg/int32.hpp"
#include <nav_msgs/msg/odometry.hpp>
#include "geometry_msgs/msg/twist.hpp"

class RIC_translator : public rclcpp::Node
{
public:
RIC_translator()
: Node("minimal_publisher"), count(0)
{
publisher_ = this->create_publisher<std_msgs::msg::String>("/ric/hbt", 10);
//
// Heartbeat
auto topic_callback =
[this](std_msgs::msg::String::UniquePtr msg) -> void {
// RCLCPP_INFO(this->get_logger(), "I heard: hbt '%s'", msg->data.c_str());
// strncpy(hbtParams, msg->data.c_str(), 100);
printHbt(msg->data.c_str());
};
subsHbt =
this->create_subscription<std_msgs::msg::String>("/teensy/T0/hbt", 10, topic_callback);
}
private:
rclcpp::TimerBase::SharedPtr timer_;
rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
rclcpp::Publisher<std_msgs::msg::Int32>::SharedPtr odo_;
size_t count;
//
char hbtParams[100] = "";
rclcpp::Subscription<std_msgs::msg::String>::SharedPtr subsHbt;
void printHbt(const char * msg)
{
printf("# %lu got hbt %s", count, msg);
snprintf(hbtParams, 100, "Hello RIC %lu %s", count++, msg);
auto message = std_msgs::msg::String();
message.set__data(hbtParams);
this->publisher_->publish(message);
}
};

int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<RIC_translator>());
rclcpp::shutdown();
return 0;
}

=== Run RIC_node ===

Compile (from workspace)
colcon build --packages-select ric_pkg

Then add it to the path
source install/setup.bash

and run
ros2 run ric_pkg ric_node

If the ''teensy_interface'' and the ''mqtt-client'' are also running, then (with the code above), it should print something like this on the console.
# 0 got hbt 1769340959.8623 13504.9463 105 1033 15.65 4 8 8.9 0.27 0
# 1 got hbt 1769340960.3625 13505.4463 105 1033 15.65 4 8 8.8 0.28 0
# 2 got hbt 1769340960.8626 13505.9453 105 1033 15.65 4 8 8.8 0.27 0
# 3 got hbt 1769340961.3622 13506.4463 105 1033 15.65 4 8 8.9 0.28 0
# 4 got hbt 1769340961.8625 13506.9463 105 1033 15.65 4 8 8.9 0.25 0
# 5 got hbt 1769340962.3631 13507.4453 105 1033 15.66 4 8 8.9 0.26 0
# 6 got hbt 1769340962.8624 13507.9463 105 1033 15.63 4 8 8.8 0.26 0

=== Ros2 relevant messages ===

One of the messages are probably ''twist'':
ros2 interface show geometry_msgs/msg/Twist
# This expresses velocity in free space broken into its linear and angular parts.
Vector3 linear
float64 x
float64 y
float64 z
Vector3 angular
float64 x
float64 y
float64 z

=== Where from here ===

Search for tutorials in https://docs.ros.org/en/jazzy/

Ricbot

2026-03-24T08:26:43Z

Jca: /* Intel RealSense */

== Ricbot, a wheeled sensor platform ==

Ricbot is intended for fast deployment to areas of interest.

Main features:
* Reused motors and wheels from an old "Elector Wheelie" platform
* Designed to fit into a normal car for deployment, i.e can be disassembled to no more than 55cm in height.
* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.
* Wheel-odometry recording (and timestamped)
* Camera image recording (and timestamped), the intention is Realsense D435.
* Maybe GNSS recording too.
* Manual remote control.

Tentative layout:

[[file: ricbot_on-shape.png | 500px]]

Length is 1m, free height 25cm, width 65cm.

== Installation notes ==

=== Camera position ===

[[file: ric-camera-position.png | 500px]]

Forward-looking camera: Intel RealSense D455, FOV 87 x 58 deg, range 0.6 to 6m.

Down-looking camera: Intel RealSense D435, FOV: 87 x 58 deg, range 0.3 to 3m.

=== Cabling ===

[[file: ric_cabling.png | 500px]]

DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042

Regbot 6.3: [[Regbot hardware board]]

[[RICBOT Power on-off board]] PCB

==== DRI0042 to Regbot 4-pin PWM ====

DRI Regbot PWM Software
7 GND (black) 1 GND --
4 PWM (red) 2 in1 PIN_xxxx_DIR
5 IN1 (white) 3 in2 PIN_xxxx_PWM
6 IN2 (yellow) 4 fault PIN_xxxx_FAULT
3 5V out

DRI0042 control values
IN1 IN2 PWM OUT1, OUT2 Motor Behavior
0 0 x Stop
1 1 x Vacant (relax)
1 0 1 Forward 100%
0 1 1 Reverse 100%
1 0 PWM Forward at PWM speed
0 1 PWM Reverse at PWM speed

==== Power control ====

Pin IDC10-pin Software Function
1 (black) 1 -- GND
2 (red) 3 LS_1 (pin 27) power off (when low) -- pt not working (wrong mod on power board)
3 (white) 4 LS_0 (A6) battery voltage (39k/4.7k)
4 (yellow) 6 LS_4 (pin 26) Alive LED

=== Intel RealSense ===

Install
sudo apt-get install automake libtool libusb-1.0-0-dev libx11-dev xorg-dev libglu1-mesa-dev
sudo apt install libssl-dev

There is a script to download and compile, e.g. on Raspberry Pi here:
https://github.com/realsenseai/librealsense/blob/master/doc/libuvc_installation.md

To install pyrealsense2 at the same time as librealsense, line 46 of the 'libuvc_installation.sh' build script should be changed from this:
cmake ../ -DFORCE_LIBUVC=true -DCMAKE_BUILD_TYPE=release
to this:
cmake ../ -DFORCE_LIBUVC=true -DCMAKE_BUILD_TYPE=release -DBUILD_PYTHON_BINDINGS:bool=true
From MartyG-RealSense on a pose here: https://github.com/realsenseai/librealsense/issues/13373

==== Library and examples ====

cd ~/git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..
make -j3
sudo make install

Copy udev rules to udev

cd ~/git/librealsense/config/99-realsense*.rules /etc/udev/rules.d/
udevadm control --reload-rules

All example commands start with rs-, e.g.:
rs-capture
rs-pointcloud

=== Teensy interface ===

The Teensy interface implements a bridge to MQTT, a motor controller (velocity and turn rate), and a remote control.

The configuration is in
/home/local/svn/teensy_interface/build/robot.ini

See also [[Robobot teensy interface]].

=== Start at boot ===

See the similar start setup in [[https://rsewiki.electro.dtu.dk/index.php?title=Enable_autostart#Autostart]].

Comment out (or delete) the start of the camera streamer (not compatible with RealSense 3D cam)

=== Install software on Raspberry Pi ===

Perform the same installation as [[Robobot install on Raspberry]], except for the serial port configuration (which should not be needed).

=== Teensy software ===

This is the Regbot software, configured to match the Ricbot.

See more details here [[Regbot firmware]].

=== Intel Librealsense ===

Installing support for Intel librealsense.

sudo apt install libssl-dev
sudo apt-get install freeglut3-dev
sudo apt-get install xorg-dev
cd git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..

I also needed to install libusb-1.0-0-dev
sudo apt install libusb-1.0-0-dev
This path was not included in the CMakeLists.txt, so I added this line at the beginning of the CMakeLists.txt:

cd librealsense
nano CMakeLists.txt
add
include_directories( /usr/include/libusb-1.0/ )
like here:
cmake_minimum_required(VERSION 3.10)

set( LRS_TARGET realsense2 )
project( ${LRS_TARGET} LANGUAGES CXX C )

# Allow librealsense2 and all of the nested project to include the main repo folder
set(REPO_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${REPO_ROOT})
'''include_directories( /usr/include/libusb-1.0/ )'''

include(CMake/lrs_options.cmake)
include(CMake/connectivity_check.cmake)
...

== ROS2 ==

From https://docs.ros.org/en/jazzy/Installation/Ubuntu-Install-Debs.html

Install
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F\" '{print $4}')

curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"

sudo dpkg -i /tmp/ros2-apt-source.deb

sudo apt update && sudo apt install ros-dev-tools

Install full ROS2 Jazzy

sudo apt install ros-jazzy-desktop

Start in this ROS2 environment, now and in new terminals:
source /opt/ros/jazzy/setup.bash
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
export ROS_DOMAIN_ID=0
echo "export ROS_DOMAIN_ID=0" >> ~/.bashrc

Install ROS QT GUI stuff
sudo apt install '~nros-jazzy-rqt*'

=== Create workspace ===

From https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html

Install colcon
sudo apt install python3-colcon-common-extensions

Create workspace directory
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws

From within this directory clone (any) standard package

e.g. tutorial examples
git clone https://github.com/ros2/examples src/examples -b jazzy

Build the examples; this is memory and CPU-hungry, so the option ''--executor sequential'' may come in handy, especially on a Raspberry Pi, but it will take significantly longer.
colcon build --symlink-install --executor sequential

Allow use of colcon_cd
echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc
echo "export _colcon_cd_root=/opt/ros/jazzy/" >> ~/.bashrc

To use the ''mixin'' shortcut for some colcon options, add:
colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml
colcon mixin update default

=== MQTT client ===

The un-modified ''mqtt_client'' package can act as a bridge between the ''teensy_interface'' and the ROS domain.

From MQTT to ROS, the translation is using the primitive ROS type ''string'' for the parameters of the ''teensy_interface'' messages.
The MQTT topic name is translated to ROS topic names as specified in the parameter file below.

From ROS to Teensy, the message should be published on a topic that matches the desired destination.
Topics for command messages to the ''teensy_interface'':
* MQTT topic ricbot/cmd/T0 for the Teensy, the message is the string to send to the Teensy.
* MQTT topic ricbot/cmd/shutdown to schedule a shutdown of the RICBOT (power off), something like 20 seconds after the message.
* MQTT topic ricbot/cmd/ti for messages to the teensy_interface, the message is a string.

==== Install ====

The robot's interface is via MQTT. Install the MQTT ROS client
sudo apt install ros-jazzy-mqtt-client

Or directly as source
cd src
git clone https://github.com/ika-rwth-aachen/mqtt_client

Compile:
cd ~/ros2_ws
colcon build

==== Run MQTT_client ====

To start the ''mqtt_client'':
cd ros2_ws/src/mqtt_client/mqtt_client/config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"
The parameter file should be extended with more ''mqtt2ros'' topics as needed.

This will launch the un-modified ''mqtt_client'' node with specific bridge parameters as specified in ''params.teensy.yaml'':
/**/*:
ros__parameters:
broker:
host: localhost
port: 1883
tls:
enabled: false
client:
id: ros
clean_session: true
keep_alive_interval: 20.0
bridge:
ros2mqtt:
ros_topics:
- /teensy/cmd/T0
- /teensy/cmd/shutdown
- /teensy/cmd/ti
/teensy/cmd/T0:
mqtt_topic: ricbot/cmd/T0
primitive: true
inject_timestamp: false
/teensy/cmd/shutdown:
mqtt_topic: ricbot/cmd/shutdown
primitive: true
inject_timestamp: false
/teensy/cmd/ti:
mqtt_topic: ricbot/cmd/ti
primitive: true
inject_timestamp: false
mqtt2ros:
# Needs to be expanded to relevant topics
mqtt_topics:
- ricbot/data/T0/info
- ricbot/data/T0/hbt
ricbot/data/T0/info:
ros_topic: /teensy/T0/info
primitive: true
ricbot/data/T0/hbt:
ros_topic: /teensy/T0/hbt
primitive: true

=== Test interface ===

Start the ''teensy_interface'' with the right ini-file:
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -z ricbot.ini

This should respond with something like:
$ ./teensy_interface -z ricbot.ini
# UService:: created directory log_20260118_083120.745/
# UMqtt:: connection to MQTT broker on tcp://localhost:1883 established
# UMqttIn:: connection to MQTT broker on tcp://localhost:1883 established
# STeensy:: opening to USB /dev/ttyACM0
# SRobot:: (t0) found IP 0: eno1 192.168.2.157
# STeensy:: just connected
# UService:: setup of Teensy 0 modules finished OK.
# Type quit to stop, or 'h' for help

Start the ''mqtt_client'' in ROS
cd ~/svn/ricbot/ros_config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"

==== From MQTT to ROS ====

There should now be ''hbt'' (heartbeat) message on the ROS side:
ros2 topic echo /teensy/T0/hbt

This should give something like:
data: '1768722645.7425 1738.4885 93 1748 4.85 0 9 18.1 0 0
'
---
data: '1768722646.2426 1738.9885 93 1748 4.85 0 9 18.0 0 0
'
---
data: '1768722646.7431 1739.4885 93 1748 4.85 0 9 18.0 0 0
'
---

The data is: timestamp (host), timestamp Teensy, Teensy ID, version, battery voltage, ... (the rest depend on the platform).

==== From ROS to MQTT ====

e.g. make the robot drive with velocity 0.25m/s and turn 0.1 rad/s CCV, followed by stop:

ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0.25 0.1'
ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0 0'

Or send a request to publish gyro data every 12ms:

ros2 topic pub /ricbot/cmd/T0 std_msgs/String 'data: sub gyro 12'

== (RIC_pkg) HW sensor translate package ==

Create the package in the workspace.

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_cmake --license MIT --node-name ric_node ric_pkg

Add dependencies to other packages to CMakeLists.txt.
Add to the list of ''find_package''

find_package(rclcpp REQUIRED)
find_package(std_msgs REQUIRED)
find_package(nav_msgs REQUIRED)
find_package(sensor_msgs REQUIRED)
find_package(geometry_msgs REQUIRED)

Make target dependencies available in the include path (and elsewhere as needed).

Add this after the ''add_executable''
ament_target_dependencies(talker rclcpp std_msgs nav_msgs sensor_msgs geometry_msgs)

To the package description ''package.xml'' add dependencies:

Add just after the ''buildtool_depend'' section:
<depend>rclcpp</depend>
<depend>std_msgs</depend>
<depend>nav_msgs</depend>
<depend>sensor_msgs</depend>
<depend>geometry_msgs</depend>

=== RIC_node code ===

The code in ''ris_node.cpp'' is pt this (not functional yet):

#include <cstdio>
#include <chrono>
#include <memory>
#include <string>

#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
#include "std_msgs/msg/int32.hpp"
#include <nav_msgs/msg/odometry.hpp>
#include "geometry_msgs/msg/twist.hpp"

class RIC_translator : public rclcpp::Node
{
public:
RIC_translator()
: Node("minimal_publisher"), count(0)
{
publisher_ = this->create_publisher<std_msgs::msg::String>("/ric/hbt", 10);
//
// Heartbeat
auto topic_callback =
[this](std_msgs::msg::String::UniquePtr msg) -> void {
// RCLCPP_INFO(this->get_logger(), "I heard: hbt '%s'", msg->data.c_str());
// strncpy(hbtParams, msg->data.c_str(), 100);
printHbt(msg->data.c_str());
};
subsHbt =
this->create_subscription<std_msgs::msg::String>("/teensy/T0/hbt", 10, topic_callback);
}
private:
rclcpp::TimerBase::SharedPtr timer_;
rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
rclcpp::Publisher<std_msgs::msg::Int32>::SharedPtr odo_;
size_t count;
//
char hbtParams[100] = "";
rclcpp::Subscription<std_msgs::msg::String>::SharedPtr subsHbt;
void printHbt(const char * msg)
{
printf("# %lu got hbt %s", count, msg);
snprintf(hbtParams, 100, "Hello RIC %lu %s", count++, msg);
auto message = std_msgs::msg::String();
message.set__data(hbtParams);
this->publisher_->publish(message);
}
};

int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<RIC_translator>());
rclcpp::shutdown();
return 0;
}

=== Run RIC_node ===

Compile (from workspace)
colcon build --packages-select ric_pkg

Then add it to the path
source install/setup.bash

and run
ros2 run ric_pkg ric_node

If the ''teensy_interface'' and the ''mqtt-client'' are also running, then (with the code above), it should print something like this on the console.
# 0 got hbt 1769340959.8623 13504.9463 105 1033 15.65 4 8 8.9 0.27 0
# 1 got hbt 1769340960.3625 13505.4463 105 1033 15.65 4 8 8.8 0.28 0
# 2 got hbt 1769340960.8626 13505.9453 105 1033 15.65 4 8 8.8 0.27 0
# 3 got hbt 1769340961.3622 13506.4463 105 1033 15.65 4 8 8.9 0.28 0
# 4 got hbt 1769340961.8625 13506.9463 105 1033 15.65 4 8 8.9 0.25 0
# 5 got hbt 1769340962.3631 13507.4453 105 1033 15.66 4 8 8.9 0.26 0
# 6 got hbt 1769340962.8624 13507.9463 105 1033 15.63 4 8 8.8 0.26 0

=== Ros2 relevant messages ===

One of the messages are probably ''twist'':
ros2 interface show geometry_msgs/msg/Twist
# This expresses velocity in free space broken into its linear and angular parts.
Vector3 linear
float64 x
float64 y
float64 z
Vector3 angular
float64 x
float64 y
float64 z

=== Where from here ===

Search for tutorials in https://docs.ros.org/en/jazzy/

Ricbot

2026-03-24T08:21:07Z

Jca: /* Intel RealSense */

== Ricbot, a wheeled sensor platform ==

Ricbot is intended for fast deployment to areas of interest.

Main features:
* Reused motors and wheels from an old "Elector Wheelie" platform
* Designed to fit into a normal car for deployment, i.e can be disassembled to no more than 55cm in height.
* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.
* Wheel-odometry recording (and timestamped)
* Camera image recording (and timestamped), the intention is Realsense D435.
* Maybe GNSS recording too.
* Manual remote control.

Tentative layout:

[[file: ricbot_on-shape.png | 500px]]

Length is 1m, free height 25cm, width 65cm.

== Installation notes ==

=== Camera position ===

[[file: ric-camera-position.png | 500px]]

Forward-looking camera: Intel RealSense D455, FOV 87 x 58 deg, range 0.6 to 6m.

Down-looking camera: Intel RealSense D435, FOV: 87 x 58 deg, range 0.3 to 3m.

=== Cabling ===

[[file: ric_cabling.png | 500px]]

DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042

Regbot 6.3: [[Regbot hardware board]]

[[RICBOT Power on-off board]] PCB

==== DRI0042 to Regbot 4-pin PWM ====

DRI Regbot PWM Software
7 GND (black) 1 GND --
4 PWM (red) 2 in1 PIN_xxxx_DIR
5 IN1 (white) 3 in2 PIN_xxxx_PWM
6 IN2 (yellow) 4 fault PIN_xxxx_FAULT
3 5V out

DRI0042 control values
IN1 IN2 PWM OUT1, OUT2 Motor Behavior
0 0 x Stop
1 1 x Vacant (relax)
1 0 1 Forward 100%
0 1 1 Reverse 100%
1 0 PWM Forward at PWM speed
0 1 PWM Reverse at PWM speed

==== Power control ====

Pin IDC10-pin Software Function
1 (black) 1 -- GND
2 (red) 3 LS_1 (pin 27) power off (when low) -- pt not working (wrong mod on power board)
3 (white) 4 LS_0 (A6) battery voltage (39k/4.7k)
4 (yellow) 6 LS_4 (pin 26) Alive LED

=== Intel RealSense ===

Install
sudo apt-get install automake libtool libusb-1.0-0-dev libx11-dev xorg-dev libglu1-mesa-dev
sudo apt install libssl-dev

There is a script to download and compile, e.g. on Raspberry Pi here:
https://github.com/realsenseai/librealsense/blob/master/doc/libuvc_installation.md

==== Library and examples ====

cd ~/git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..
make -j3
sudo make install

Copy udev rules to udev

cd ~/git/librealsense/config/99-realsense*.rules /etc/udev/rules.d/
udevadm control --reload-rules

All example commands start with rs-, e.g.:
rs-capture
rs-pointcloud

=== Teensy interface ===

The Teensy interface implements a bridge to MQTT, a motor controller (velocity and turn rate), and a remote control.

The configuration is in
/home/local/svn/teensy_interface/build/robot.ini

See also [[Robobot teensy interface]].

=== Start at boot ===

See the similar start setup in [[https://rsewiki.electro.dtu.dk/index.php?title=Enable_autostart#Autostart]].

Comment out (or delete) the start of the camera streamer (not compatible with RealSense 3D cam)

=== Install software on Raspberry Pi ===

Perform the same installation as [[Robobot install on Raspberry]], except for the serial port configuration (which should not be needed).

=== Teensy software ===

This is the Regbot software, configured to match the Ricbot.

See more details here [[Regbot firmware]].

=== Intel Librealsense ===

Installing support for Intel librealsense.

sudo apt install libssl-dev
sudo apt-get install freeglut3-dev
sudo apt-get install xorg-dev
cd git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..

I also needed to install libusb-1.0-0-dev
sudo apt install libusb-1.0-0-dev
This path was not included in the CMakeLists.txt, so I added this line at the beginning of the CMakeLists.txt:

cd librealsense
nano CMakeLists.txt
add
include_directories( /usr/include/libusb-1.0/ )
like here:
cmake_minimum_required(VERSION 3.10)

set( LRS_TARGET realsense2 )
project( ${LRS_TARGET} LANGUAGES CXX C )

# Allow librealsense2 and all of the nested project to include the main repo folder
set(REPO_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${REPO_ROOT})
'''include_directories( /usr/include/libusb-1.0/ )'''

include(CMake/lrs_options.cmake)
include(CMake/connectivity_check.cmake)
...

== ROS2 ==

From https://docs.ros.org/en/jazzy/Installation/Ubuntu-Install-Debs.html

Install
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F\" '{print $4}')

curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"

sudo dpkg -i /tmp/ros2-apt-source.deb

sudo apt update && sudo apt install ros-dev-tools

Install full ROS2 Jazzy

sudo apt install ros-jazzy-desktop

Start in this ROS2 environment, now and in new terminals:
source /opt/ros/jazzy/setup.bash
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
export ROS_DOMAIN_ID=0
echo "export ROS_DOMAIN_ID=0" >> ~/.bashrc

Install ROS QT GUI stuff
sudo apt install '~nros-jazzy-rqt*'

=== Create workspace ===

From https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html

Install colcon
sudo apt install python3-colcon-common-extensions

Create workspace directory
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws

From within this directory clone (any) standard package

e.g. tutorial examples
git clone https://github.com/ros2/examples src/examples -b jazzy

Build the examples; this is memory and CPU-hungry, so the option ''--executor sequential'' may come in handy, especially on a Raspberry Pi, but it will take significantly longer.
colcon build --symlink-install --executor sequential

Allow use of colcon_cd
echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc
echo "export _colcon_cd_root=/opt/ros/jazzy/" >> ~/.bashrc

To use the ''mixin'' shortcut for some colcon options, add:
colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml
colcon mixin update default

=== MQTT client ===

The un-modified ''mqtt_client'' package can act as a bridge between the ''teensy_interface'' and the ROS domain.

From MQTT to ROS, the translation is using the primitive ROS type ''string'' for the parameters of the ''teensy_interface'' messages.
The MQTT topic name is translated to ROS topic names as specified in the parameter file below.

From ROS to Teensy, the message should be published on a topic that matches the desired destination.
Topics for command messages to the ''teensy_interface'':
* MQTT topic ricbot/cmd/T0 for the Teensy, the message is the string to send to the Teensy.
* MQTT topic ricbot/cmd/shutdown to schedule a shutdown of the RICBOT (power off), something like 20 seconds after the message.
* MQTT topic ricbot/cmd/ti for messages to the teensy_interface, the message is a string.

==== Install ====

The robot's interface is via MQTT. Install the MQTT ROS client
sudo apt install ros-jazzy-mqtt-client

Or directly as source
cd src
git clone https://github.com/ika-rwth-aachen/mqtt_client

Compile:
cd ~/ros2_ws
colcon build

==== Run MQTT_client ====

To start the ''mqtt_client'':
cd ros2_ws/src/mqtt_client/mqtt_client/config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"
The parameter file should be extended with more ''mqtt2ros'' topics as needed.

This will launch the un-modified ''mqtt_client'' node with specific bridge parameters as specified in ''params.teensy.yaml'':
/**/*:
ros__parameters:
broker:
host: localhost
port: 1883
tls:
enabled: false
client:
id: ros
clean_session: true
keep_alive_interval: 20.0
bridge:
ros2mqtt:
ros_topics:
- /teensy/cmd/T0
- /teensy/cmd/shutdown
- /teensy/cmd/ti
/teensy/cmd/T0:
mqtt_topic: ricbot/cmd/T0
primitive: true
inject_timestamp: false
/teensy/cmd/shutdown:
mqtt_topic: ricbot/cmd/shutdown
primitive: true
inject_timestamp: false
/teensy/cmd/ti:
mqtt_topic: ricbot/cmd/ti
primitive: true
inject_timestamp: false
mqtt2ros:
# Needs to be expanded to relevant topics
mqtt_topics:
- ricbot/data/T0/info
- ricbot/data/T0/hbt
ricbot/data/T0/info:
ros_topic: /teensy/T0/info
primitive: true
ricbot/data/T0/hbt:
ros_topic: /teensy/T0/hbt
primitive: true

=== Test interface ===

Start the ''teensy_interface'' with the right ini-file:
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -z ricbot.ini

This should respond with something like:
$ ./teensy_interface -z ricbot.ini
# UService:: created directory log_20260118_083120.745/
# UMqtt:: connection to MQTT broker on tcp://localhost:1883 established
# UMqttIn:: connection to MQTT broker on tcp://localhost:1883 established
# STeensy:: opening to USB /dev/ttyACM0
# SRobot:: (t0) found IP 0: eno1 192.168.2.157
# STeensy:: just connected
# UService:: setup of Teensy 0 modules finished OK.
# Type quit to stop, or 'h' for help

Start the ''mqtt_client'' in ROS
cd ~/svn/ricbot/ros_config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"

==== From MQTT to ROS ====

There should now be ''hbt'' (heartbeat) message on the ROS side:
ros2 topic echo /teensy/T0/hbt

This should give something like:
data: '1768722645.7425 1738.4885 93 1748 4.85 0 9 18.1 0 0
'
---
data: '1768722646.2426 1738.9885 93 1748 4.85 0 9 18.0 0 0
'
---
data: '1768722646.7431 1739.4885 93 1748 4.85 0 9 18.0 0 0
'
---

The data is: timestamp (host), timestamp Teensy, Teensy ID, version, battery voltage, ... (the rest depend on the platform).

==== From ROS to MQTT ====

e.g. make the robot drive with velocity 0.25m/s and turn 0.1 rad/s CCV, followed by stop:

ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0.25 0.1'
ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0 0'

Or send a request to publish gyro data every 12ms:

ros2 topic pub /ricbot/cmd/T0 std_msgs/String 'data: sub gyro 12'

== (RIC_pkg) HW sensor translate package ==

Create the package in the workspace.

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_cmake --license MIT --node-name ric_node ric_pkg

Add dependencies to other packages to CMakeLists.txt.
Add to the list of ''find_package''

find_package(rclcpp REQUIRED)
find_package(std_msgs REQUIRED)
find_package(nav_msgs REQUIRED)
find_package(sensor_msgs REQUIRED)
find_package(geometry_msgs REQUIRED)

Make target dependencies available in the include path (and elsewhere as needed).

Add this after the ''add_executable''
ament_target_dependencies(talker rclcpp std_msgs nav_msgs sensor_msgs geometry_msgs)

To the package description ''package.xml'' add dependencies:

Add just after the ''buildtool_depend'' section:
<depend>rclcpp</depend>
<depend>std_msgs</depend>
<depend>nav_msgs</depend>
<depend>sensor_msgs</depend>
<depend>geometry_msgs</depend>

=== RIC_node code ===

The code in ''ris_node.cpp'' is pt this (not functional yet):

#include <cstdio>
#include <chrono>
#include <memory>
#include <string>

#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
#include "std_msgs/msg/int32.hpp"
#include <nav_msgs/msg/odometry.hpp>
#include "geometry_msgs/msg/twist.hpp"

class RIC_translator : public rclcpp::Node
{
public:
RIC_translator()
: Node("minimal_publisher"), count(0)
{
publisher_ = this->create_publisher<std_msgs::msg::String>("/ric/hbt", 10);
//
// Heartbeat
auto topic_callback =
[this](std_msgs::msg::String::UniquePtr msg) -> void {
// RCLCPP_INFO(this->get_logger(), "I heard: hbt '%s'", msg->data.c_str());
// strncpy(hbtParams, msg->data.c_str(), 100);
printHbt(msg->data.c_str());
};
subsHbt =
this->create_subscription<std_msgs::msg::String>("/teensy/T0/hbt", 10, topic_callback);
}
private:
rclcpp::TimerBase::SharedPtr timer_;
rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
rclcpp::Publisher<std_msgs::msg::Int32>::SharedPtr odo_;
size_t count;
//
char hbtParams[100] = "";
rclcpp::Subscription<std_msgs::msg::String>::SharedPtr subsHbt;
void printHbt(const char * msg)
{
printf("# %lu got hbt %s", count, msg);
snprintf(hbtParams, 100, "Hello RIC %lu %s", count++, msg);
auto message = std_msgs::msg::String();
message.set__data(hbtParams);
this->publisher_->publish(message);
}
};

int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<RIC_translator>());
rclcpp::shutdown();
return 0;
}

=== Run RIC_node ===

Compile (from workspace)
colcon build --packages-select ric_pkg

Then add it to the path
source install/setup.bash

and run
ros2 run ric_pkg ric_node

If the ''teensy_interface'' and the ''mqtt-client'' are also running, then (with the code above), it should print something like this on the console.
# 0 got hbt 1769340959.8623 13504.9463 105 1033 15.65 4 8 8.9 0.27 0
# 1 got hbt 1769340960.3625 13505.4463 105 1033 15.65 4 8 8.8 0.28 0
# 2 got hbt 1769340960.8626 13505.9453 105 1033 15.65 4 8 8.8 0.27 0
# 3 got hbt 1769340961.3622 13506.4463 105 1033 15.65 4 8 8.9 0.28 0
# 4 got hbt 1769340961.8625 13506.9463 105 1033 15.65 4 8 8.9 0.25 0
# 5 got hbt 1769340962.3631 13507.4453 105 1033 15.66 4 8 8.9 0.26 0
# 6 got hbt 1769340962.8624 13507.9463 105 1033 15.63 4 8 8.8 0.26 0

=== Ros2 relevant messages ===

One of the messages are probably ''twist'':
ros2 interface show geometry_msgs/msg/Twist
# This expresses velocity in free space broken into its linear and angular parts.
Vector3 linear
float64 x
float64 y
float64 z
Vector3 angular
float64 x
float64 y
float64 z

=== Where from here ===

Search for tutorials in https://docs.ros.org/en/jazzy/

Robobot install on Raspberry

2026-03-18T10:17:34Z

Jca: /* Additional packages */

Back to [[Robobot B]]

== Raspberry installation notes ==

Raspberry Pi recommended 64-bit OS is ''Debian GNU/Linux 13 (trixie)'' (2025)

[[Raspberry base install]]

Alternatively, if ROS2 is needed, install Ubuntu (but a bit more complicated)

=== Install Raspberry on blank SD-card ===

Use Raspberry Pi Imager
(download from https://www.raspberrypi.com/software/)

rpi-imager

'''Select operating system''' 'Raspberry Pi OS (64bit)' and '''storage''', an empty SD-flash of at least 16GB.

Next

Edit settings: set:

* Hostname (e.g. robobot)
* Username (local) and password (remember to spell the password correctly).
* SSID (DTUdevice), and associated password
* Time zone (Europe/Copenhagen)
* Danish keyboard
* In ''Services'', enable SSH.

Then yes, yes.

When finished, mount the SD into the Raspberry Pi

=== Get in contact with Raspberry ===

If everything is configured as above, you just need to determine the IP.
On a Linux computer, you can find the Raspberry Pi's IP address using (if on the same local network):

sudo apt install net-tools nmap
nmap -sP 192.168.2.0/24

else

You need a screen and keyboard.

Log on to the Raspberry Pi

$ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
...
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.197.217.175 netmask 255.255.252.0 broadcast 10.197.219.255
inet6 fe80::f620:b431:69cc:44f4 prefixlen 64 scopeid 0x20<link>
ether dc:a6:32:f4:0e:a4 txqueuelen 1000 (Ethernet)
RX packets 486 bytes 41505 (40.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 421 bytes 43403 (42.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

In this case, the IP4 (inet) is 10.197.217.175.

If you don't get an IP address, the Wi-Fi may not be set correctly (see the [[Network setup]]).

===Additional packages===

Install the following packages:
libreadline-dev
libopencv-dev
libgpiod-dev
gpiod
cmake
subversion
aptitude
telnet
ntp (better to use timesyncd)
ntpdate ( -- )
nmap
lsof
net-tools
libpaho-mqtt-dev
libpaho-mqttpp-dev (if not available, then not needed)
python3-paho-mqtt
python3-opencv
python3-setproctitle
mosquito
mosquitto-dev
mosquitto-clients
libusb-dev
libcli11-dev (maybe not available)
libssl-dev
sudo apt install libreadline-dev libopencv-dev libgpiod-dev gpiod cmake subversion aptitude telnet nmap lsof python3-paho-mqtt libpaho-mqtt-dev python3-opencv python3-setproctitle mosquitto mosquitto-dev mosquitto-clients libusb-dev libcli11-dev net-tools libssl-dev

and, if libcli11-dev is not available

Install command line interface library (if not found by 'apt install libcli11-dev')
cd
cd git
git clone https://github.com/CLIUtils/CLI11.git

The library is 'header-only', and the makefile for Raspberry looks in ~/git/CLI11 for the file, so no need to build.

==== Ubuntu additional ====

Install also:
build-essential
net-tools
openssh-server
grub-mkconfig (not found)
git
sudo apt install net-tools openssh-server git build-essential

The ssh server needs to be enabled
sudo systemctl enable ssh
sudo systemctl start ssh

The grub-mkconfig command can be used to update the startup behaviour, e.g., to terminal-only.
Edit the /etc/default/grub, make the changes, and then update the boot
sudo grub-mkconfig -o /boot/grub/grub.cfg
but not found

=== Configure Mosquitto ===

At installation, the Mosquitto server does not allow remote access.

A complete configuration file can be found here: https://github.com/eclipse-mosquitto/mosquitto/tree/master

Only two options are needed, so we make a set of local options:

sudo nano /etc/mosquitto/conf.d/robobot.conf

Insert these lines (insert from clipboard is Ctrl+Shift+v in nano)
listener 1883
allow_anonymous true

Save and restart mosquito

sudo service mosquitto restart

More details here [[MQTT_and_Mosquitto]]

=== Configure serial port /dev/ttyACM0 ===

At times, a serial port echoes what is received. This creates an endless loop, as the Teensy sends a reply, if something is not understood.
This is a configuration of the port; see the settings using stty:

stty -a -F /dev/ttyACM0
''speed 9600 baud; rows 0; columns 0; line = 0;
''intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
''stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
''-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
''-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
''-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
''-isig -icanon iexten '''-echo''' -echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc''

Especially ''echo'' (last line) must have a '-' in front. However, other types of handshake, such as 'ixoff', should be disabled as well.
This can all be set by:

stty -F /dev/ttyACM0 raw -echo -echoe

When installing the ''udev'' rule for Teensy devices, then the above command is executed when a Teensy device is detected.
See [[Arduino_and_Teensy_libraries#Add_Teensy_board_support]].

The ''udev'' rule is included in ''robobot/setup'' directory as ''00-teensy.rules'', is should be copied to /etc/udev
sudo cp ~/svn/robobot/setup/00-teensy.rules /etc/udev/rules.d/
The file contains

# UDEV Rules for Teensy boards, http://www.pjrc.com/teensy/
#
# The latest version of this file may be found at:
# http://www.pjrc.com/teensy/00-teensy.rules
#
# This file must be placed at:
#
# /etc/udev/rules.d/00-teensy.rules (preferred location)
# or
# /lib/udev/rules.d/00-teensy.rules (req'd on some broken systems)
#
# To install, type this command in a terminal:
# sudo cp 00-teensy.rules /etc/udev/rules.d/00-teensy.rules
#
# After this file is installed, physically unplug and reconnect Teensy.
#
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04*", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_PORT_IGNORE}="1"
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789a]*", ENV{MTP_NO_PROBE}="1"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04*", MODE:="0666", RUN:="/bin/stty -F /dev/%k raw -echo"
KERNEL=="hidraw*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04*", MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04*", MODE:="0666"
KERNEL=="hidraw*", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="013*", MODE:="0666"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="013*", MODE:="0666"

#
# If you share your Linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with
# GROUP:="somegroupname" and manage access using standard Unix groups.
#
# ModemManager tends to interfere with USB Serial devices like Teensy.
# Problems manifest as the Arduino Serial Monitor missing some incoming
# data, and "Unable to open /dev/ttyACM0 for reboot request" when
# uploading. If you experience these problems, disable or remove
# ModemManager from your system. If you must use a modem, perhaps
# try disabling the "MM_FILTER_RULE_TTY_ACM_INTERFACE" ModemManager
# rule. Changing ModemManager's filter policy from "strict" to "default"
# may also help. But if you don't use a modem, completely removing
# the troublesome ModemManager is the most effective solution.

Robobot calibration

2026-03-12T13:26:27Z

Jca: /* Testing calibration */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92 or 68)
* Distance between wheels (around 23cm)

==== Set configuration ====
These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

This message is typicalle send from the Python script ''spose.py'' around line 92:
service.send("robobot/cmd/T0", "confw 0.074 0.074 19 92 0.23")
Note: Some of the motors have a different encoder with 68 ticks per revolution (TPR), rather than the 92 in this example.

==== Get configuration ====

The configuration values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

==== Testing calibration ====

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

In Python, there are start options to test the odometry calibration. To drive 1m forward:

python3 mqtt-client.py -m

and for the turn calibration (turn 180 degrees):

python3 mqtt-client.py -p

The robot may make a small overshoot in both distance and the turn, so check the logfile to see what the robot thinks; this should match the actual measured drive.

The Python log file is named ''logfile.txt'' in the ''svn/robobot/mqtt_python'' directory.

The ''teensy_interface'' also creates a logfile named ''log_y0_pose.txt'' in the ''svn/robobot/teensy_interface/build'' directory.

Robobot calibration

2026-03-12T13:21:22Z

Jca: /* Testing calibration */

Robobot calibration

2026-03-12T13:18:06Z

Jca: /* Testing calibration */

Robobot calibration

2026-03-12T13:15:01Z

Jca: /* Calibrate odometry */

Robobot calibration

2026-03-12T13:14:44Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92 or 68)
* Distance between wheels (around 23cm)

==== set configuration ====
These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

This message is typicalle send from the Python script ''spose.py'' around line 92:
service.send("robobot/cmd/T0", "confw 0.074 0.074 19 92 0.23")
Note: Some of the motors have a different encoder with 68 ticks per revolution (TPR), rather than the 92 in this example.

==== get configuration ====

The configuration values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

==== testing calibration ====

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:13:40Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92 or 68)
* Distance between wheels (around 23cm)

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

This message is typicalle send from the Python script ''spose.py'' around line 92:
service.send("robobot/cmd/T0", "confw 0.074 0.074 19 92 0.23")
Note: Some of the motors have a different encoder with 68 ticks per revolution (TPR), rather than the 92 in this example.

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:13:26Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92 or 68)
* Distance between wheels (around 23cm)

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

This message is typicalle send from the Python script '''spose.py''' around line 92:
service.send("robobot/cmd/T0", "confw 0.074 0.074 19 92 0.23")
Note: Some of the motors have a different encoder with 68 ticks per revolution (TPR), rather than the 92 in this example.

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:12:05Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92)
* Distance between wheels (around 23cm)

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

This message is typicalle send from the Python script '''spose.py''' around line 92:
service.send("robobot/cmd/T0","confw 0.074 0.074 19 92 0.23")
Note that some of the motors have a different encoder with 68 ticks per revolution (TPR), rather than the 92 in this example.

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:07:43Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92)
* Distance between wheels (around 23cm)

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:07:35Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92)
* Distance between wheels (around 23cm)

<-- In the 2026 version, odometry is calculated by the teensy_interface,
So these values need to go into the file
svn/robobot/teensy_interface/build/robot.ini
in the [mixer] section.
Remember that this file is overwritten when the teensy_interface stops (e.g. at reboot). The overwriting can be avoided by changing 'saveconfig = true' to 'saveconfig = false' in the [ini] section. -->

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-12T13:07:25Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92)
* Distance between wheels (around 23cm)

<--! In the 2026 version, odometry is calculated by the teensy_interface,
So these values need to go into the file
svn/robobot/teensy_interface/build/robot.ini
in the [mixer] section.
Remember that this file is overwritten when the teensy_interface stops (e.g. at reboot). The overwriting can be avoided by changing 'saveconfig = true' to 'saveconfig = false' in the [ini] section. -->

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

Robobot calibration

2026-03-06T14:03:56Z

Jca: /* Calibrate odometry */

Back to [[Robobot_B | Robobot]]

== Sending commands to the Teensy board using MQTT ==

== Line sensor ==

[[file:line-sensor-firmware-blocks.png | 500px ]]

The line sensor blinks the LED illumination and subtracts the non-illuminated from the illuminated.

These (raw) values are then normalized relative to a calibrated expected white value.

The normalized value is between 0 (black - no reflection) and 1000 (calibrated white reflection).

=== Start calibration ===

Place the sensor at the expected distance over a white surface with the expected reflectance (i.e. white tape).

Send the command, e.g. ''licw 100'':
topic: robobot/cmd/T0
message: "licw 100"
where 100 means average over 100 samples.

Once finished, save the values in the Teensy flash by ''eew'':
topic: robobot/cmd/T0
message "eew"

=== Get normalized data ===

Subscribe to data from the Teensy using the command
sub livn 7
Or using MQTT, publish:
topic: robobot/cmd/T0
message: "sub livn 7"
where 7 means update every 7 ms. This could be as low as 1, but the traffic load may give communication bottlenecks, resulting in delay or lost messages. The communication limit is approximately 4000 messages per second (each below 64 characters).

== Distance sensor calibration ==

The distance sensor needs calibration.

[[file:distance_sensor_firmware_block.png | 700px]]

The sensor is calibrated with two sensor values, 13 cm and 50 cm.

The datasheet states that the analogue voltage out of the sensor is something like:

[[file:ir-sensor-voltage-2025.png | 400px]]

It can be seen that distances below 5cm can give the same voltage as most other distances.

The easiest way is to have console access directly to the Teensy.
Connect to the robot using, e.g., Putty to get two command lines on the Robot's Raspberry.
Or a serial console if the Teensy is connected directly to a PC.

==== Sensor values 13 cm ====

Subscribe to sensor data and calibration values every 300ms:

Send this message to the Teensy
sub ir 300
Using MQTT this is:
topic: robobot/cmd/T0
message: sub ir 300

Watch the message (either using cat or MQTT)
cat /dev/ttyACM0
Using MQTT, subscribe to
topic: robobot/drive/T0/ir
Should get this

ir 0.124 0.137 15698 14219 15000 4600 15000 4100 1
ir 0.124 0.137 15660 14220 15000 4600 15000 4100 1
ir 0.124 0.137 15666 14207 15000 4600 15000 4100 1
or using MQTT
robobot/drive/T0/ir 1740853405.7074 0.124 0.137 15698 14219 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.0078 0.124 0.137 15660 14220 15000 4600 15000 4100 1
robobot/drive/T0/ir 1740853406.3075 0.124 0.137 15666 14207 15000 4600 15000 4100 1

Obstacles are here at 13 cm for both sensors. The first two values show the distance, which is close to 13 cm here. The raw (filtered) values are approximately 15660 and 14210, respectively. This is relatively close to the already-calibrated value of 15000.

The last value ''1'' shows that the sensor is on; if not, then send the on command:

iron 1
Using MQTT
topic: robobot/cmd/T0
message: iron 1

==== Sensor values 50 cm ====

The 50cm values could be

ir 0.496 0.426 4633 4761 15000 4600 15000 4100 1
ir 0.500 0.426 4600 4770 15000 4600 15000 4100 1
ir 0.496 0.426 4628 4764 15000 4600 15000 4100 1
ir 0.494 0.426 4641 4762 15000 4600 15000 4100 1
ir 0.498 0.426 4616 4761 15000 4600 15000 4100 1
ir 0.496 0.427 4627 4759 15000 4600 15000 4100 1
ir 0.481 0.427 4741 4756 15000 4600 15000 4100 1

The value seems fine for sensor 1 (default side-mounted); it is a bit off for the other sensor.

==== Implement calibration ====

To implement the new calibration values, use (in this case).
* Help text is: ''irc A1 B1 A2 B2 V Set calibration values A=13cm value, B=50cm (sensor 1 and 2) V=1 in on''.

irc 15660 4600 14210 4760 1
or MQTT, publish:
topic: robobot/cmd/T0
message: "irc 15660 4600 14210 4760 1"
Then save to the Teensy flash:
eew
or using MQTT
topic: robobot/cmd/T0
message "eew"

The values at 50cm now look like:

ir 0.501 0.501 4590 4756 15660 4600 14210 4760 1
ir 0.491 0.498 4669 4770 15660 4600 14210 4760 1
ir 0.498 0.501 4619 4754 15660 4600 14210 4760 1
ir 0.499 0.499 4610 4765 15660 4600 14210 4760 1
ir 0.493 0.501 4654 4755 15660 4600 14210 4760 1

After this calibration, the actual values should be within 3-5 cm in the 10cm to 50cm range.

==== Reflections ====

If the sensor looks into a reflecting surface, then this may disturb the reading.

==== Back to normal ====

The teensy_interface was terminated, and further, the CRC was disabled.

Turn on CRC:

echo "i 0" >/dev/ttyACM0

Restart the teensy_interface, or maybe better, reboot the Raspberry:

sudo reboot now

alternatively, restart

cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l

But the restarted process will be terminated sometime after you terminate the command line access.

== Calibrate odometry ==

Robot wheel configuration requires:
* Wheel radius (around 7.5cm)
* Gear ratio (19:1)
* Encoder ticks per revolution (92)
* Distance between wheels (around 23cm)

In the 2026 version, odometry is calculated by the teensy_interface,
So these values need to go into the file
svn/robobot/teensy_interface/build/robot.ini
in the [mixer] section.
Remember that this file is overwritten when the teensy_interface stops (e.g. at reboot). The overwriting can be avoided by changing 'saveconfig = true' to 'saveconfig = false' in the [ini] section.

These values are sent to the ''teensy_firmware_8'' as ''confw rl rr gear TPR wb'', e.g.:
confw 0.0750 0.0750 19 92 0.234
or using MQTT
topic: robobot/cmd/T0
message: "confw 0.0750 0.0750 19 92 0.234"

The values can be queried with a ''configi'' command, which returns, e.g.:
conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
or, if subscribed from MQTT
topic: robobot/drive/T0
message: conf 0.0750 0.0750 19.000 92 0.2340 0.0020 0
The last ''0.0020'' is the system sample time, here 2ms. The last ''0'' is for motortest only.

The simple method is:
* Order the robot to drive 1m, check how long the robot thinks it has driven, e.g. 1.02m, then compare with reality, and adjust the wheel radius as relevant.
* Order the robot to turn, e.g. 180 degrees, compare with reality and adjust the distance between driving wheels as needed.

File:Power switch v2 pcb.png

2026-03-01T18:46:35Z

Jca: PCB

== Summary ==
PCB

File:Power switch v2 circuit.png

2026-03-01T18:46:13Z

Jca: Circuit diagram

== Summary ==
Circuit diagram

RICBOT Power on-off board

2026-03-01T18:45:41Z

Jca: /* Power distribution */

Back to [[Ricbot]]

== Power distribution ==

PCB

[[file: power_switch_v2_circuit.png | 500px]]

[[file: power_switch_v2_pcb.png | 500px]]

RICBOT Power on-off board

2026-03-01T18:41:31Z

Jca:

Back to [[Ricbot]]

== Power distribution ==

RICBOT Power on-off board

2026-03-01T18:41:00Z

Jca: Created page with "Back to RICBOT == Power distribution =="

Back to [[RICBOT]]

== Power distribution ==

Ricbot

2026-03-01T18:40:36Z

Jca: /* Cabling */

== Ricbot, a wheeled sensor platform ==

Ricbot is intended for fast deployment to areas of interest.

Main features:
* Reused motors and wheels from an old "Elector Wheelie" platform
* Designed to fit into a normal car for deployment, i.e can be disassembled to no more than 55cm in height.
* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.
* Wheel-odometry recording (and timestamped)
* Camera image recording (and timestamped), the intention is Realsense D435.
* Maybe GNSS recording too.
* Manual remote control.

Tentative layout:

[[file: ricbot_on-shape.png | 500px]]

Length is 1m, free height 25cm, width 65cm.

== Installation notes ==

=== Camera position ===

[[file: ric-camera-position.png | 500px]]

Forward-looking camera: Intel RealSense D455, FOV 87 x 58 deg, range 0.6 to 6m.

Down-looking camera: Intel RealSense D435, FOV: 87 x 58 deg, range 0.3 to 3m.

=== Cabling ===

[[file: ric_cabling.png | 500px]]

DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042

Regbot 6.3: [[Regbot hardware board]]

[[RICBOT Power on-off board]] PCB

==== DRI0042 to Regbot 4-pin PWM ====

DRI Regbot PWM Software
7 GND (black) 1 GND --
4 PWM (red) 2 in1 PIN_xxxx_DIR
5 IN1 (white) 3 in2 PIN_xxxx_PWM
6 IN2 (yellow) 4 fault PIN_xxxx_FAULT
3 5V out

DRI0042 control values
IN1 IN2 PWM OUT1, OUT2 Motor Behavior
0 0 x Stop
1 1 x Vacant (relax)
1 0 1 Forward 100%
0 1 1 Reverse 100%
1 0 PWM Forward at PWM speed
0 1 PWM Reverse at PWM speed

==== Power control ====

Pin IDC10-pin Software Function
1 (black) 1 -- GND
2 (red) 3 LS_1 (pin 27) power off (when low) -- pt not working (wrong mod on power board)
3 (white) 4 LS_0 (A6) battery voltage (39k/4.7k)
4 (yellow) 6 LS_4 (pin 26) Alive LED

=== Intel RealSense ===

Install
sudo apt-get install automake libtool libusb-1.0-0-dev libx11-dev xorg-dev libglu1-mesa-dev
sudo apt install libssl-dev

==== Library and examples ====

cd ~/git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..
make -j3
sudo make install

Copy udev rules to udev

cd ~/git/librealsense/config/99-realsense*.rules /etc/udev/rules.d/
udevadm control --reload-rules

All example commands start with rs-, e.g.:
rs-capture
rs-pointcloud

=== Teensy interface ===

The Teensy interface implements a bridge to MQTT, a motor controller (velocity and turn rate), and a remote control.

The configuration is in
/home/local/svn/teensy_interface/build/robot.ini

See also [[Robobot teensy interface]].

=== Start at boot ===

See the similar start setup in [[https://rsewiki.electro.dtu.dk/index.php?title=Enable_autostart#Autostart]].

Comment out (or delete) the start of the camera streamer (not compatible with RealSense 3D cam)

=== Install software on Raspberry Pi ===

Perform the same installation as [[Robobot install on Raspberry]], except for the serial port configuration (which should not be needed).

=== Teensy software ===

This is the Regbot software, configured to match the Ricbot.

See more details here [[Regbot firmware]].

=== Intel Librealsense ===

Installing support for Intel librealsense.

sudo apt install libssl-dev
sudo apt-get install freeglut3-dev
sudo apt-get install xorg-dev
cd git
git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense
mkdir build
cd build
cmake ..

I also needed to install libusb-1.0-0-dev
sudo apt install libusb-1.0-0-dev
This path was not included in the CMakeLists.txt, so I added this line at the beginning of the CMakeLists.txt:

cd librealsense
nano CMakeLists.txt
add
include_directories( /usr/include/libusb-1.0/ )
like here:
cmake_minimum_required(VERSION 3.10)

set( LRS_TARGET realsense2 )
project( ${LRS_TARGET} LANGUAGES CXX C )

# Allow librealsense2 and all of the nested project to include the main repo folder
set(REPO_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${REPO_ROOT})
'''include_directories( /usr/include/libusb-1.0/ )'''

include(CMake/lrs_options.cmake)
include(CMake/connectivity_check.cmake)
...

== ROS2 ==

From https://docs.ros.org/en/jazzy/Installation/Ubuntu-Install-Debs.html

Install
export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F\" '{print $4}')

curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb"

sudo dpkg -i /tmp/ros2-apt-source.deb

sudo apt update && sudo apt install ros-dev-tools

Install full ROS2 Jazzy

sudo apt install ros-jazzy-desktop

Start in this ROS2 environment, now and in new terminals:
source /opt/ros/jazzy/setup.bash
echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
export ROS_DOMAIN_ID=0
echo "export ROS_DOMAIN_ID=0" >> ~/.bashrc

Install ROS QT GUI stuff
sudo apt install '~nros-jazzy-rqt*'

=== Create workspace ===

From https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html

Install colcon
sudo apt install python3-colcon-common-extensions

Create workspace directory
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws

From within this directory clone (any) standard package

e.g. tutorial examples
git clone https://github.com/ros2/examples src/examples -b jazzy

Build the examples; this is memory and CPU-hungry, so the option ''--executor sequential'' may come in handy, especially on a Raspberry Pi, but it will take significantly longer.
colcon build --symlink-install --executor sequential

Allow use of colcon_cd
echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc
echo "export _colcon_cd_root=/opt/ros/jazzy/" >> ~/.bashrc

To use the ''mixin'' shortcut for some colcon options, add:
colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml
colcon mixin update default

=== MQTT client ===

The un-modified ''mqtt_client'' package can act as a bridge between the ''teensy_interface'' and the ROS domain.

From MQTT to ROS, the translation is using the primitive ROS type ''string'' for the parameters of the ''teensy_interface'' messages.
The MQTT topic name is translated to ROS topic names as specified in the parameter file below.

From ROS to Teensy, the message should be published on a topic that matches the desired destination.
Topics for command messages to the ''teensy_interface'':
* MQTT topic ricbot/cmd/T0 for the Teensy, the message is the string to send to the Teensy.
* MQTT topic ricbot/cmd/shutdown to schedule a shutdown of the RICBOT (power off), something like 20 seconds after the message.
* MQTT topic ricbot/cmd/ti for messages to the teensy_interface, the message is a string.

==== Install ====

The robot's interface is via MQTT. Install the MQTT ROS client
sudo apt install ros-jazzy-mqtt-client

Or directly as source
cd src
git clone https://github.com/ika-rwth-aachen/mqtt_client

Compile:
cd ~/ros2_ws
colcon build

==== Run MQTT_client ====

To start the ''mqtt_client'':
cd ros2_ws/src/mqtt_client/mqtt_client/config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"
The parameter file should be extended with more ''mqtt2ros'' topics as needed.

This will launch the un-modified ''mqtt_client'' node with specific bridge parameters as specified in ''params.teensy.yaml'':
/**/*:
ros__parameters:
broker:
host: localhost
port: 1883
tls:
enabled: false
client:
id: ros
clean_session: true
keep_alive_interval: 20.0
bridge:
ros2mqtt:
ros_topics:
- /teensy/cmd/T0
- /teensy/cmd/shutdown
- /teensy/cmd/ti
/teensy/cmd/T0:
mqtt_topic: ricbot/cmd/T0
primitive: true
inject_timestamp: false
/teensy/cmd/shutdown:
mqtt_topic: ricbot/cmd/shutdown
primitive: true
inject_timestamp: false
/teensy/cmd/ti:
mqtt_topic: ricbot/cmd/ti
primitive: true
inject_timestamp: false
mqtt2ros:
# Needs to be expanded to relevant topics
mqtt_topics:
- ricbot/data/T0/info
- ricbot/data/T0/hbt
ricbot/data/T0/info:
ros_topic: /teensy/T0/info
primitive: true
ricbot/data/T0/hbt:
ros_topic: /teensy/T0/hbt
primitive: true

=== Test interface ===

Start the ''teensy_interface'' with the right ini-file:
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -z ricbot.ini

This should respond with something like:
$ ./teensy_interface -z ricbot.ini
# UService:: created directory log_20260118_083120.745/
# UMqtt:: connection to MQTT broker on tcp://localhost:1883 established
# UMqttIn:: connection to MQTT broker on tcp://localhost:1883 established
# STeensy:: opening to USB /dev/ttyACM0
# SRobot:: (t0) found IP 0: eno1 192.168.2.157
# STeensy:: just connected
# UService:: setup of Teensy 0 modules finished OK.
# Type quit to stop, or 'h' for help

Start the ''mqtt_client'' in ROS
cd ~/svn/ricbot/ros_config
ros2 launch mqtt_client standalone.launch.xml params_file:="params.teensy.yaml"

==== From MQTT to ROS ====

There should now be ''hbt'' (heartbeat) message on the ROS side:
ros2 topic echo /teensy/T0/hbt

This should give something like:
data: '1768722645.7425 1738.4885 93 1748 4.85 0 9 18.1 0 0
'
---
data: '1768722646.2426 1738.9885 93 1748 4.85 0 9 18.0 0 0
'
---
data: '1768722646.7431 1739.4885 93 1748 4.85 0 9 18.0 0 0
'
---

The data is: timestamp (host), timestamp Teensy, Teensy ID, version, battery voltage, ... (the rest depend on the platform).

==== From ROS to MQTT ====

e.g. make the robot drive with velocity 0.25m/s and turn 0.1 rad/s CCV, followed by stop:

ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0.25 0.1'
ros2 topic pub /ricbot/cmd/ti std_msgs/String 'data: rc 0 0'

Or send a request to publish gyro data every 12ms:

ros2 topic pub /ricbot/cmd/T0 std_msgs/String 'data: sub gyro 12'

== (RIC_pkg) HW sensor translate package ==

Create the package in the workspace.

cd ~/ros2_ws/src
ros2 pkg create --build-type ament_cmake --license MIT --node-name ric_node ric_pkg

Add dependencies to other packages to CMakeLists.txt.
Add to the list of ''find_package''

find_package(rclcpp REQUIRED)
find_package(std_msgs REQUIRED)
find_package(nav_msgs REQUIRED)
find_package(sensor_msgs REQUIRED)
find_package(geometry_msgs REQUIRED)

Make target dependencies available in the include path (and elsewhere as needed).

Add this after the ''add_executable''
ament_target_dependencies(talker rclcpp std_msgs nav_msgs sensor_msgs geometry_msgs)

To the package description ''package.xml'' add dependencies:

Add just after the ''buildtool_depend'' section:
<depend>rclcpp</depend>
<depend>std_msgs</depend>
<depend>nav_msgs</depend>
<depend>sensor_msgs</depend>
<depend>geometry_msgs</depend>

=== RIC_node code ===

The code in ''ris_node.cpp'' is pt this (not functional yet):

#include <cstdio>
#include <chrono>
#include <memory>
#include <string>

#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
#include "std_msgs/msg/int32.hpp"
#include <nav_msgs/msg/odometry.hpp>
#include "geometry_msgs/msg/twist.hpp"

class RIC_translator : public rclcpp::Node
{
public:
RIC_translator()
: Node("minimal_publisher"), count(0)
{
publisher_ = this->create_publisher<std_msgs::msg::String>("/ric/hbt", 10);
//
// Heartbeat
auto topic_callback =
[this](std_msgs::msg::String::UniquePtr msg) -> void {
// RCLCPP_INFO(this->get_logger(), "I heard: hbt '%s'", msg->data.c_str());
// strncpy(hbtParams, msg->data.c_str(), 100);
printHbt(msg->data.c_str());
};
subsHbt =
this->create_subscription<std_msgs::msg::String>("/teensy/T0/hbt", 10, topic_callback);
}
private:
rclcpp::TimerBase::SharedPtr timer_;
rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
rclcpp::Publisher<std_msgs::msg::Int32>::SharedPtr odo_;
size_t count;
//
char hbtParams[100] = "";
rclcpp::Subscription<std_msgs::msg::String>::SharedPtr subsHbt;
void printHbt(const char * msg)
{
printf("# %lu got hbt %s", count, msg);
snprintf(hbtParams, 100, "Hello RIC %lu %s", count++, msg);
auto message = std_msgs::msg::String();
message.set__data(hbtParams);
this->publisher_->publish(message);
}
};

int main(int argc, char ** argv)
{
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<RIC_translator>());
rclcpp::shutdown();
return 0;
}

=== Run RIC_node ===

Compile (from workspace)
colcon build --packages-select ric_pkg

Then add it to the path
source install/setup.bash

and run
ros2 run ric_pkg ric_node

If the ''teensy_interface'' and the ''mqtt-client'' are also running, then (with the code above), it should print something like this on the console.
# 0 got hbt 1769340959.8623 13504.9463 105 1033 15.65 4 8 8.9 0.27 0
# 1 got hbt 1769340960.3625 13505.4463 105 1033 15.65 4 8 8.8 0.28 0
# 2 got hbt 1769340960.8626 13505.9453 105 1033 15.65 4 8 8.8 0.27 0
# 3 got hbt 1769340961.3622 13506.4463 105 1033 15.65 4 8 8.9 0.28 0
# 4 got hbt 1769340961.8625 13506.9463 105 1033 15.65 4 8 8.9 0.25 0
# 5 got hbt 1769340962.3631 13507.4453 105 1033 15.66 4 8 8.9 0.26 0
# 6 got hbt 1769340962.8624 13507.9463 105 1033 15.63 4 8 8.8 0.26 0

=== Ros2 relevant messages ===

One of the messages are probably ''twist'':
ros2 interface show geometry_msgs/msg/Twist
# This expresses velocity in free space broken into its linear and angular parts.
Vector3 linear
float64 x
float64 y
float64 z
Vector3 angular
float64 x
float64 y
float64 z

=== Where from here ===

Search for tutorials in https://docs.ros.org/en/jazzy/

Robot dashboard

2026-02-25T09:37:23Z

Jca: Created page with " == Introduction == This is intro. * bullit list then it is code 500px Figur 1"

== Introduction ==

This is intro.

* bullit list

then it is code

[[file: billede.png | 500px]]

Figur 1

Main Page

2026-02-25T09:35:15Z

Jca: /* Robots */

Welcome to the wiki pages of the Robot Systems Engineering (RSE) group in Automation and Control at DTU Electrical Engineering.

These pages will contain updated information on RSE projects and other issues related to robotics research.

= Facilities =

* [[ASTA|Autonomous System Testing Arena (ASTA)]]

* [[ASTA motion capture|Motion capture (Optitrack)]]

* [[uASTA|μASTA]]

* [[Lipo Safety | Lipo safety]]

* [[Workshop]]

= Robots =

[[SMR]] (Small Mobile Robot)

[[UR5]] (Universal Robot UR5 Arm)

[[UR10]] (Universal Robot UR10 Arm)

[[Fieldrobot]] (Fieldrobot)

[[iRobot ATRV-Jr]]

[[TerrainHopper]]

[[regbot | Regbot]] (small robot intended as control-1 exercise)

[[Basebot]] is the base version of Regbot for digital control exercises.

[[robobot B | Robobot]] A small 4-wheel robot for DTU Robocup.

[[SimServer]] Stage-based multi-robot simulator

[[Fejemis]] autonomous cleaning

[[Capra]] P5

[[Scorpi]] crane robot.

[[Lanciers]] demo robots.

[[Ricbot]] Wheeled sensor platform for weed detection.

=== Other projects===

[[Robot dashboard]] - igangværende projekt.

[[Weather monitor]], also including the GNSS 'weather'.

[[Claas axion]] (Semi-autonomous heavy tractor)

[[Mini40 force/torque sensor]]

[[Robotiq gripper]]

[[Visual Tracking on Pixhawk]] (Position estimation of Pixhawk flight controller with external camera)

[[3D localization]] based on sensor network



[[inspection robot]] (4/6-legged robot)


= Mobotware =

(Mobile Robot software)

* [[AU Robot Servers]] (AURS) includes servers for soft real-time processing, e.g.: camera and laser scanner processing.

* [[RHD]] (Robot Hardware Daemon) is the hardware abstraction layer, with interface to real-time sensors and actuators.

* MRC - see SMR below - is the real-time movement control (and mission control using the SMR-CL language)

[[Version and download]]

[[Automated test setup]]

= Linux system considerations =

[[Switchtool]] - Shift Mobotware version - earlier, newer or the one locally on the robots

[[Rules for udev on RTAI]] (How to use udev rules to get correct modes for RTAI fifos and Comedi devices)

[[Naming networkinterfaces using udev]]

[[Setting permissions for various devices using udev]]

[[Authenticating Linux clients against MS Active Directory]]

[[Using GDB for coredump]]

====Older pages====

These pages are no longer relevant.

[[Labyrinth]] (Labyrinth game)

[[Drone control]] drone base control

[[DTU running path dataset]]

[[flexbot]] design work to get a flexible stair climbing robot

[[Ubuntu 32-bit or 64-bit]]

[[Slackware OpenCV package install]]

[[Slackware packages in robot image]]

[[MMR]] (Medium Mobile Robot)

[[HAKO]] (KU Life tractor, now in Hohenheim University Germany)

[[hexakopter]] (notes for six-rotor helicopter including the pixhawk autopilot)

= Controllab =

[[Platform list]] (List of computers used for various control set-ups)

[[Realtime testing]] (Description of small test procedures to verify RTAI realtime operation)

[http://aut.elektro.dtu.dk/staff/sh/rsewiki/matlabrtai_intro.pdf Introduction to Matlab RTW and RTAI] (Guide for usage of RTAILab with Matlab RTW and Simulink)

= How-to documentation =

====installation====

[[NTP howto]] time-sync 2 computers

Using the [[RSE SVN]] repository

[[Flash disk cloning]] - to repair robot boot disk image

[[Install on (K)UBUNTU]] - for test and development on PC or laptop

[[Install on raspberry]] - install Mobotware on raspbian (NOOBS) or a Debian based Linux on Beagle-bone.

[[Install Universal Robots simulator on lab PC]]

[[Remote Development of Mobotware Using Eclipse]]

[[Set hostnames from dhcp-server with dhclient on *buntu systems]]

[[Notes on compiling augclient]] - GUI interface for Mobotware used fx. in AGCO project

====utility pages====

[[Convert a .tex document to openoffice]]

[[Access DTU campus network using VPN from Linux]]

[[disable display manager on boot]] (and thereby the graphic user interface)

[[How to make a animation from separate images]]

[[Citrix access to DTU files and Windows Apps]] (Using Citrix Receiver, preferred way from 2015+)

[[Latex]] where to put document class files in ubuntu installation

[[file export]] testpage for export of files

====older pages====

[[RoboCup]] - bl.a. scoreboard - not maintained

[[AU software license considerations]]

[[Robot GUI (MARG)]] - (no longer maintained)

[[Install GUI-less UBUNTU]] - new boot disk image for robots

= Demonstrations =

[[PLC controlled traffic light]]

[[Machine shop in 326]]

[[Inverted pendulum]]

Network setup

2026-02-10T08:48:10Z

Jca: /* Using static IP and DNS server on Raspberry */

Back to [[Robobot B]]

==WiFi network==

If you are at DTU and the small display shows an IP, then all is fine. Otherwise read further down.

====Network Manager====

The NetworkManager uses device UUID as part of the Wi-Fi network setup. This means that (sometimes) an SD card can not be moved from one robot to another with a functional Wi-Fi connection.

After 20 seconds, an attempt to solve this is activated using the commands below (the code is found in svn/robobot/setup/rename_host.bash - last half).

Use the last line to setup manually - or the GUI, if available.

See the current network settings
nmcli dev show
Network manager connection with UUID
nmcli connection
List available wifi access points
nmcli dev wifi

==== Connect to DTUdevice net ====

You can establish a new connection from the command line
sudo nmcli device wifi connect DTUdevice password <password> ifname wlan0 ipv6.method "disabled"
This should create a new system-connection file with a usable UUID.
IPv6 is disabled because many of the IPv6 MACs appear to be the same (we cloned the SD card), and this will blacklist the connection for MAC address theft.

There is a terminal-based user interface to edit a connection. First list connections:
$ nmcli con show
eg: NAME UUID TYPE DEVICE
preconfigured e07a0ae8-028b-4d65-806c-ec63f435df44 wifi wlan0
lo 2737bad6-956f-4668-99e0-4697f4ec30a7 loopback lo
Find the NAME of the connection to edit, e.g. 'preconfigured'
sudo nmtui edit "preconfigured"
Then edit as desired.

Reload Network Manager to read this.

sudo nmcli connection reload

or restart the NetworkManager

sudo systemctl restart NetworkManager.service

==== Home network connection ====

If you know the SSID and password, you can prepare the robot for another (home) network.
Use this command (replacing <SSID> and <password>):

sudo nmcli device wifi connect <SSID> password <password> ifname wlan0

If you have no network contact, then use a local link (cable) or attach a screen and keyboard.

== Cable connection ==

==== Using static IP and DNS server on Raspberry ====

Assign a static IP for the Raspberry:

sudo nmcli connection add con-name eth0-manual ifname eth0 type ethernet ip4 192.168.7.7/24 ipv6.method disabled

The Raspberry's IP address is 192.168.7.7 when a cable is connected. The Network Manager may need to be reloaded.

sudo nmcli con reload

Your PC on the other end then needs to be assigned a static (manual) IP address in the same network, e.g., 192.168.7.22.

The response time on the cable is much faster than over wifi. Typically less than 0.5ms on cable and often more than 5ms on wifi. Try ping from your PC:

ping 192.168.7.7

==== Alternative ====

I found this method (Google AI) to use DHCP with higher priority, and then static IP if DHCP fails

sudo nmcli connection add type ethernet con-name "Wired-DHCP" ifname eth0 ipv4.method auto autoconnect yes connect.autoconnect-priority 1

sudo nmcli connection add type ethernet con-name "Robobot-Static7" ifname eth0 ipv4.method manual ipv4.addresses 192.168.7.7/24 ipv4.gateway 192.168.7.1 ipv4.dns 8.8.8.8 autoconnect yes connect.autoconnect-priority 0

This creates 2 entries in /etc/NetworkManager/system-connections (on a default Raspberry Pi 64 Bit OS using Network Manager)

/etc/NetworkManager/system-connections/Wired-DHCP.nmconnection

[connection]
id=Wired-DHCP
uuid=339844b1-cee4-4a43-a3f1-a5de05f3cb70
type=ethernet
autoconnect-priority=1
interface-name=eth0

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note! the UUID should be different''

/etc/NetworkManager/system-connections/Robobot-Static7.nmconnection

[connection]
id=Robobot-Static7
uuid=2a91ef05-3666-4293-a793-330c3b49cdd4
type=ethernet
interface-name=eth0

[ethernet]

[ipv4]
address1=192.168.7.7/24,192.168.7.1
dns=8.8.8.8;
method=manual

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note2! To default to static IP can take 2-4 minutes after detecting the cable! (at least 2 times 60 second timeout is needed)''

On your laptop you can do the same, but probably more efficient, set to manual IP v4.
This can be done using your GUI tools, or on Linux:

sudo ip eth0 192.168.7.22

Note! ''eth0'' may be different, as modern hardware often has a more complex name, as ''eno1'' or ''enp108s0''.

Note2! If the robot has 192.168.7.7, then you should use something else for your laptop, e.g. 192.168.7.22.

Then ssh to the robot

ssh local@192.168.7.7

==== Install DNS server on Raspberry ====

This section may be deprecated, use the alternative method above with fallback to static IP.

Allow the connected PC to get an IP automatically; install DNSMASQ

sudo apt install dnsmasq

Configure the use by editing /etc/dnsmasq.conf

sudo nano /etc/dnsmasq.conf

Uncomment and change two lines. It is to be used on ETH0 only and in the IP range 192.168.7.50 to 192.168.7.99.

# DNS requests only on
# specified interface
interface=eth0
# range of addresses available for lease and optionally
# a lease time
dhcp-range=192.168.7.50,192.168.7.99,255.255.255.0,12h

Restart the dnsmasq

sudo service dnsmasq restart

To see the status of the dnsmasq service use:

journalctl -b0 -u dnsmasq.service

After this, when you plug in a cable to a PC, then, after some seconds, both the robot and the PC should have an IP in the range 192.168.7.x. And the robot should display the new IP 192.168.7.7.

You can now access the robot using
ssh local@192.168.7.7

==== Local link ====

Note: This method failed in most cases

If wifi is too slow or unavailable, a local link using a network cable could be the solution.

Many PCs will assign a local link IP like 168.254.x.x, and the Robot will do the same. The robot IP will be displayed on the small display but may be obscured if a Wi-Fi IP is available.

To prepare this behaviour, log in to the Raspberry using wifi (or attach a screen and keyboard) and make a preferred local-link cabled connection:

sudo nmcli con mod "Wired connection 1" ipv4.method link-local ipv6.method disabled

This should then be the behaviour after a reboot. "Wired connection 1" needs to be spelt this way; see the valid names using:

nmcli connection

Reload Network manager

sudo nmcli connection reload

== Check IP and SSID ==

When the Pi has rebooted, connect to it using SSH once again. Check that the Pi is connected to WiFi
ifconfig
Under '''wlan0''' confirm that the Pi has received an IP (inet addr) and note down the first three sections of the IP - they are most likely '''10.197.21x.xxx'''

To see which SSID you are connected to, use
iwconfig
or
nmcli -o

The MAC address ('HWaddr' or 'ether') of the Pi should also be noted down - this probably starts with '''B8:27:EB:xx:xx:xx''' make sure to get all of it.

===Find IP of robot (Linux)===

In case the Pi gets a new IP address after reboot, you can search for it using the MAC address and '''nmap'''. If '''nmap''' is not installed, start by installing it
sudo apt-get install nmap
To search for the Pi using the MAC address in terminal type
nmap -sP 10.197.218.0/20 | awk '/^Nmap/{ip=$NF}/B8:27:EB:23:A0:F5/{print ip}'
where '''10.197.218''' is the first three sections of the IP you noted down, 20 is the number of fixed bits (out of 32), and '''B8:27:EB:23:A0:F5''' is the MAC address of the Pi. This should return the IP of the Pi.

NB! the MAC can hold letters, they should probably be capital.

==== If you don't know the IP address====

Use the first part to get a list of active IPs on the net:
nmap -sP 10.197.218.0/24

The robot's name should be included in the list, but the network may take a while to detect it.

== NTP ==

'''Depreciated'''. The Raspberry default time sync now works, also at DTU.

Network Time Protocol is used to keep clocks in sync.
Raspberry Pi will start with the date and time of the last proper shutdown, and a few seconds after the network is up, it will sync the clock using NTP.

NTP need to be installed, i.e. 'sudo apt install ntp' if not done already.

At DTU, most clock sources are blocked; the clock source needs to be configured.

At DTU, edit /etc/NTP.conf or /etc/ntpsec/ntp.conf and add ntp.ait.du.dk to the top of the server pool list.

sudo nano /etc/ntpsec/ntp.conf

...
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
pool ntp.ait.dtu.dk
...

Sync time (if on DTU net)

sudo ntpdate -u ntp.ait.dtu.dk

Should work in and around DTU - see also [[NTP howto]] for more details.

You can also check the status of the ntp service:

sudo systemctl status ntp.service

Network setup

2026-02-10T08:46:18Z

Jca: /* Cable connection */

Back to [[Robobot B]]

==WiFi network==

If you are at DTU and the small display shows an IP, then all is fine. Otherwise read further down.

====Network Manager====

The NetworkManager uses device UUID as part of the Wi-Fi network setup. This means that (sometimes) an SD card can not be moved from one robot to another with a functional Wi-Fi connection.

After 20 seconds, an attempt to solve this is activated using the commands below (the code is found in svn/robobot/setup/rename_host.bash - last half).

Use the last line to setup manually - or the GUI, if available.

See the current network settings
nmcli dev show
Network manager connection with UUID
nmcli connection
List available wifi access points
nmcli dev wifi

==== Connect to DTUdevice net ====

You can establish a new connection from the command line
sudo nmcli device wifi connect DTUdevice password <password> ifname wlan0 ipv6.method "disabled"
This should create a new system-connection file with a usable UUID.
IPv6 is disabled because many of the IPv6 MACs appear to be the same (we cloned the SD card), and this will blacklist the connection for MAC address theft.

There is a terminal-based user interface to edit a connection. First list connections:
$ nmcli con show
eg: NAME UUID TYPE DEVICE
preconfigured e07a0ae8-028b-4d65-806c-ec63f435df44 wifi wlan0
lo 2737bad6-956f-4668-99e0-4697f4ec30a7 loopback lo
Find the NAME of the connection to edit, e.g. 'preconfigured'
sudo nmtui edit "preconfigured"
Then edit as desired.

Reload Network Manager to read this.

sudo nmcli connection reload

or restart the NetworkManager

sudo systemctl restart NetworkManager.service

==== Home network connection ====

If you know the SSID and password, you can prepare the robot for another (home) network.
Use this command (replacing <SSID> and <password>):

sudo nmcli device wifi connect <SSID> password <password> ifname wlan0

If you have no network contact, then use a local link (cable) or attach a screen and keyboard.

== Cable connection ==

==== Using static IP and DNS server on Raspberry ====

Assign a static IP for the Raspberry:

sudo nmcli connection add con-name eth0-manual ifname eth0 type ethernet ip4 192.168.7.7/24 ipv6.method disabled

The Raspberry's IP address is 192.168.7.7 when a cable is connected. The Network Manager may need to be reloaded.

sudo nmcli con reload

Your PC on the other end then needs to be assigned a static (manual) IP address in the same network, e.g., 192.168.7.8.

The response time on the cable is much faster than over wifi. Typically less than 0.5ms on cable and often more than 5ms on wifi. Try ping from your PC:

ping 192.168.7.7

==== Alternative ====

I found this method (Google AI) to use DHCP with higher priority, and then static IP if DHCP fails

sudo nmcli connection add type ethernet con-name "Wired-DHCP" ifname eth0 ipv4.method auto autoconnect yes connect.autoconnect-priority 1

sudo nmcli connection add type ethernet con-name "Robobot-Static7" ifname eth0 ipv4.method manual ipv4.addresses 192.168.7.7/24 ipv4.gateway 192.168.7.1 ipv4.dns 8.8.8.8 autoconnect yes connect.autoconnect-priority 0

This creates 2 entries in /etc/NetworkManager/system-connections (on a default Raspberry Pi 64 Bit OS using Network Manager)

/etc/NetworkManager/system-connections/Wired-DHCP.nmconnection

[connection]
id=Wired-DHCP
uuid=339844b1-cee4-4a43-a3f1-a5de05f3cb70
type=ethernet
autoconnect-priority=1
interface-name=eth0

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note! the UUID should be different''

/etc/NetworkManager/system-connections/Robobot-Static7.nmconnection

[connection]
id=Robobot-Static7
uuid=2a91ef05-3666-4293-a793-330c3b49cdd4
type=ethernet
interface-name=eth0

[ethernet]

[ipv4]
address1=192.168.7.7/24,192.168.7.1
dns=8.8.8.8;
method=manual

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note2! To default to static IP can take 2-4 minutes after detecting the cable! (at least 2 times 60 second timeout is needed)''

On your laptop you can do the same, but probably more efficient, set to manual IP v4.
This can be done using your GUI tools, or on Linux:

sudo ip eth0 192.168.7.22

Note! ''eth0'' may be different, as modern hardware often has a more complex name, as ''eno1'' or ''enp108s0''.

Note2! If the robot has 192.168.7.7, then you should use something else for your laptop, e.g. 192.168.7.22.

Then ssh to the robot

ssh local@192.168.7.7

==== Install DNS server on Raspberry ====

This section may be deprecated, use the alternative method above with fallback to static IP.

Allow the connected PC to get an IP automatically; install DNSMASQ

sudo apt install dnsmasq

Configure the use by editing /etc/dnsmasq.conf

sudo nano /etc/dnsmasq.conf

Uncomment and change two lines. It is to be used on ETH0 only and in the IP range 192.168.7.50 to 192.168.7.99.

# DNS requests only on
# specified interface
interface=eth0
# range of addresses available for lease and optionally
# a lease time
dhcp-range=192.168.7.50,192.168.7.99,255.255.255.0,12h

Restart the dnsmasq

sudo service dnsmasq restart

To see the status of the dnsmasq service use:

journalctl -b0 -u dnsmasq.service

After this, when you plug in a cable to a PC, then, after some seconds, both the robot and the PC should have an IP in the range 192.168.7.x. And the robot should display the new IP 192.168.7.7.

You can now access the robot using
ssh local@192.168.7.7

==== Local link ====

Note: This method failed in most cases

If wifi is too slow or unavailable, a local link using a network cable could be the solution.

Many PCs will assign a local link IP like 168.254.x.x, and the Robot will do the same. The robot IP will be displayed on the small display but may be obscured if a Wi-Fi IP is available.

To prepare this behaviour, log in to the Raspberry using wifi (or attach a screen and keyboard) and make a preferred local-link cabled connection:

sudo nmcli con mod "Wired connection 1" ipv4.method link-local ipv6.method disabled

This should then be the behaviour after a reboot. "Wired connection 1" needs to be spelt this way; see the valid names using:

nmcli connection

Reload Network manager

sudo nmcli connection reload

== Check IP and SSID ==

When the Pi has rebooted, connect to it using SSH once again. Check that the Pi is connected to WiFi
ifconfig
Under '''wlan0''' confirm that the Pi has received an IP (inet addr) and note down the first three sections of the IP - they are most likely '''10.197.21x.xxx'''

To see which SSID you are connected to, use
iwconfig
or
nmcli -o

The MAC address ('HWaddr' or 'ether') of the Pi should also be noted down - this probably starts with '''B8:27:EB:xx:xx:xx''' make sure to get all of it.

===Find IP of robot (Linux)===

In case the Pi gets a new IP address after reboot, you can search for it using the MAC address and '''nmap'''. If '''nmap''' is not installed, start by installing it
sudo apt-get install nmap
To search for the Pi using the MAC address in terminal type
nmap -sP 10.197.218.0/20 | awk '/^Nmap/{ip=$NF}/B8:27:EB:23:A0:F5/{print ip}'
where '''10.197.218''' is the first three sections of the IP you noted down, 20 is the number of fixed bits (out of 32), and '''B8:27:EB:23:A0:F5''' is the MAC address of the Pi. This should return the IP of the Pi.

NB! the MAC can hold letters, they should probably be capital.

==== If you don't know the IP address====

Use the first part to get a list of active IPs on the net:
nmap -sP 10.197.218.0/24

The robot's name should be included in the list, but the network may take a while to detect it.

== NTP ==

'''Depreciated'''. The Raspberry default time sync now works, also at DTU.

Network Time Protocol is used to keep clocks in sync.
Raspberry Pi will start with the date and time of the last proper shutdown, and a few seconds after the network is up, it will sync the clock using NTP.

NTP need to be installed, i.e. 'sudo apt install ntp' if not done already.

At DTU, most clock sources are blocked; the clock source needs to be configured.

At DTU, edit /etc/NTP.conf or /etc/ntpsec/ntp.conf and add ntp.ait.du.dk to the top of the server pool list.

sudo nano /etc/ntpsec/ntp.conf

...
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
pool ntp.ait.dtu.dk
...

Sync time (if on DTU net)

sudo ntpdate -u ntp.ait.dtu.dk

Should work in and around DTU - see also [[NTP howto]] for more details.

You can also check the status of the ntp service:

sudo systemctl status ntp.service

Network setup

2026-02-10T08:45:13Z

Jca: /* Cable connection */

Back to [[Robobot B]]

==WiFi network==

If you are at DTU and the small display shows an IP, then all is fine. Otherwise read further down.

====Network Manager====

The NetworkManager uses device UUID as part of the Wi-Fi network setup. This means that (sometimes) an SD card can not be moved from one robot to another with a functional Wi-Fi connection.

After 20 seconds, an attempt to solve this is activated using the commands below (the code is found in svn/robobot/setup/rename_host.bash - last half).

Use the last line to setup manually - or the GUI, if available.

See the current network settings
nmcli dev show
Network manager connection with UUID
nmcli connection
List available wifi access points
nmcli dev wifi

==== Connect to DTUdevice net ====

You can establish a new connection from the command line
sudo nmcli device wifi connect DTUdevice password <password> ifname wlan0 ipv6.method "disabled"
This should create a new system-connection file with a usable UUID.
IPv6 is disabled because many of the IPv6 MACs appear to be the same (we cloned the SD card), and this will blacklist the connection for MAC address theft.

There is a terminal-based user interface to edit a connection. First list connections:
$ nmcli con show
eg: NAME UUID TYPE DEVICE
preconfigured e07a0ae8-028b-4d65-806c-ec63f435df44 wifi wlan0
lo 2737bad6-956f-4668-99e0-4697f4ec30a7 loopback lo
Find the NAME of the connection to edit, e.g. 'preconfigured'
sudo nmtui edit "preconfigured"
Then edit as desired.

Reload Network Manager to read this.

sudo nmcli connection reload

or restart the NetworkManager

sudo systemctl restart NetworkManager.service

==== Home network connection ====

If you know the SSID and password, you can prepare the robot for another (home) network.
Use this command (replacing <SSID> and <password>):

sudo nmcli device wifi connect <SSID> password <password> ifname wlan0

If you have no network contact, then use a local link (cable) or attach a screen and keyboard.

== Cable connection ==

==== Using static IP and DNS server on Raspberry ====

Assign a static IP for the Raspberry:

sudo nmcli connection add con-name eth0-manual ifname eth0 type ethernet ip4 192.168.7.7/24 ipv6.method disabled

The Raspberry's IP address is 192.168.7.7 when a cable is connected. The Network Manager may need to be reloaded.

sudo nmcli con reload

Your PC on the other end then needs to be assigned a static (manual) IP address in the same network, e.g., 192.168.7.8.

The response time on the cable is much faster than over wifi. Typically less than 0.5ms on cable and often more than 5ms on wifi.

==== Alternative ====

I found this method (Google AI) to use DHCP with higher priority, and then static IP if DHCP fails

sudo nmcli connection add type ethernet con-name "Wired-DHCP" ifname eth0 ipv4.method auto autoconnect yes connect.autoconnect-priority 1

sudo nmcli connection add type ethernet con-name "Robobot-Static7" ifname eth0 ipv4.method manual ipv4.addresses 192.168.7.7/24 ipv4.gateway 192.168.7.1 ipv4.dns 8.8.8.8 autoconnect yes connect.autoconnect-priority 0

This creates 2 entries in /etc/NetworkManager/system-connections (on a default Raspberry Pi 64 Bit OS using Network Manager)

/etc/NetworkManager/system-connections/Wired-DHCP.nmconnection

[connection]
id=Wired-DHCP
uuid=339844b1-cee4-4a43-a3f1-a5de05f3cb70
type=ethernet
autoconnect-priority=1
interface-name=eth0

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note! the UUID should be different''

/etc/NetworkManager/system-connections/Robobot-Static7.nmconnection

[connection]
id=Robobot-Static7
uuid=2a91ef05-3666-4293-a793-330c3b49cdd4
type=ethernet
interface-name=eth0

[ethernet]

[ipv4]
address1=192.168.7.7/24,192.168.7.1
dns=8.8.8.8;
method=manual

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note2! To default to static IP can take 2-4 minutes after detecting the cable! (at least 2 times 60 second timeout is needed)''

On your laptop you can do the same, but probably more efficient, set to manual IP v4.
This can be done using your GUI tools, or on Linux:

sudo ip eth0 192.168.7.22

Note! ''eth0'' may be different, as modern hardware often has a more complex name, as ''eno1'' or ''enp108s0''.

Note2! If the robot has 192.168.7.7, then you should use something else for your laptop, e.g. 192.168.7.22.

Then ssh to the robot

ssh local@192.168.7.7

==== Install DNS server on Raspberry ====

This section may be deprecated, use the alternative method above with fallback to static IP.

Allow the connected PC to get an IP automatically; install DNSMASQ

sudo apt install dnsmasq

Configure the use by editing /etc/dnsmasq.conf

sudo nano /etc/dnsmasq.conf

Uncomment and change two lines. It is to be used on ETH0 only and in the IP range 192.168.7.50 to 192.168.7.99.

# DNS requests only on
# specified interface
interface=eth0
# range of addresses available for lease and optionally
# a lease time
dhcp-range=192.168.7.50,192.168.7.99,255.255.255.0,12h

Restart the dnsmasq

sudo service dnsmasq restart

To see the status of the dnsmasq service use:

journalctl -b0 -u dnsmasq.service

After this, when you plug in a cable to a PC, then, after some seconds, both the robot and the PC should have an IP in the range 192.168.7.x. And the robot should display the new IP 192.168.7.7.

You can now access the robot using
ssh local@192.168.7.7

==== Local link ====

Note: This method failed in most cases

If wifi is too slow or unavailable, a local link using a network cable could be the solution.

Many PCs will assign a local link IP like 168.254.x.x, and the Robot will do the same. The robot IP will be displayed on the small display but may be obscured if a Wi-Fi IP is available.

To prepare this behaviour, log in to the Raspberry using wifi (or attach a screen and keyboard) and make a preferred local-link cabled connection:

sudo nmcli con mod "Wired connection 1" ipv4.method link-local ipv6.method disabled

This should then be the behaviour after a reboot. "Wired connection 1" needs to be spelt this way; see the valid names using:

nmcli connection

Reload Network manager

sudo nmcli connection reload

== Check IP and SSID ==

When the Pi has rebooted, connect to it using SSH once again. Check that the Pi is connected to WiFi
ifconfig
Under '''wlan0''' confirm that the Pi has received an IP (inet addr) and note down the first three sections of the IP - they are most likely '''10.197.21x.xxx'''

To see which SSID you are connected to, use
iwconfig
or
nmcli -o

The MAC address ('HWaddr' or 'ether') of the Pi should also be noted down - this probably starts with '''B8:27:EB:xx:xx:xx''' make sure to get all of it.

===Find IP of robot (Linux)===

In case the Pi gets a new IP address after reboot, you can search for it using the MAC address and '''nmap'''. If '''nmap''' is not installed, start by installing it
sudo apt-get install nmap
To search for the Pi using the MAC address in terminal type
nmap -sP 10.197.218.0/20 | awk '/^Nmap/{ip=$NF}/B8:27:EB:23:A0:F5/{print ip}'
where '''10.197.218''' is the first three sections of the IP you noted down, 20 is the number of fixed bits (out of 32), and '''B8:27:EB:23:A0:F5''' is the MAC address of the Pi. This should return the IP of the Pi.

NB! the MAC can hold letters, they should probably be capital.

==== If you don't know the IP address====

Use the first part to get a list of active IPs on the net:
nmap -sP 10.197.218.0/24

The robot's name should be included in the list, but the network may take a while to detect it.

== NTP ==

'''Depreciated'''. The Raspberry default time sync now works, also at DTU.

Network Time Protocol is used to keep clocks in sync.
Raspberry Pi will start with the date and time of the last proper shutdown, and a few seconds after the network is up, it will sync the clock using NTP.

NTP need to be installed, i.e. 'sudo apt install ntp' if not done already.

At DTU, most clock sources are blocked; the clock source needs to be configured.

At DTU, edit /etc/NTP.conf or /etc/ntpsec/ntp.conf and add ntp.ait.du.dk to the top of the server pool list.

sudo nano /etc/ntpsec/ntp.conf

...
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
pool ntp.ait.dtu.dk
...

Sync time (if on DTU net)

sudo ntpdate -u ntp.ait.dtu.dk

Should work in and around DTU - see also [[NTP howto]] for more details.

You can also check the status of the ntp service:

sudo systemctl status ntp.service

Network setup

2026-02-10T08:43:23Z

Jca: /* Cable connection */

Back to [[Robobot B]]

==WiFi network==

If you are at DTU and the small display shows an IP, then all is fine. Otherwise read further down.

====Network Manager====

The NetworkManager uses device UUID as part of the Wi-Fi network setup. This means that (sometimes) an SD card can not be moved from one robot to another with a functional Wi-Fi connection.

After 20 seconds, an attempt to solve this is activated using the commands below (the code is found in svn/robobot/setup/rename_host.bash - last half).

Use the last line to setup manually - or the GUI, if available.

See the current network settings
nmcli dev show
Network manager connection with UUID
nmcli connection
List available wifi access points
nmcli dev wifi

==== Connect to DTUdevice net ====

You can establish a new connection from the command line
sudo nmcli device wifi connect DTUdevice password <password> ifname wlan0 ipv6.method "disabled"
This should create a new system-connection file with a usable UUID.
IPv6 is disabled because many of the IPv6 MACs appear to be the same (we cloned the SD card), and this will blacklist the connection for MAC address theft.

There is a terminal-based user interface to edit a connection. First list connections:
$ nmcli con show
eg: NAME UUID TYPE DEVICE
preconfigured e07a0ae8-028b-4d65-806c-ec63f435df44 wifi wlan0
lo 2737bad6-956f-4668-99e0-4697f4ec30a7 loopback lo
Find the NAME of the connection to edit, e.g. 'preconfigured'
sudo nmtui edit "preconfigured"
Then edit as desired.

Reload Network Manager to read this.

sudo nmcli connection reload

or restart the NetworkManager

sudo systemctl restart NetworkManager.service

==== Home network connection ====

If you know the SSID and password, you can prepare the robot for another (home) network.
Use this command (replacing <SSID> and <password>):

sudo nmcli device wifi connect <SSID> password <password> ifname wlan0

If you have no network contact, then use a local link (cable) or attach a screen and keyboard.

== Cable connection ==

==== Using static IP and DNS server on Raspberry ====

Assign a static IP for the Raspberry:

sudo nmcli connection add con-name eth0-manual ifname eth0 type ethernet ip4 192.168.7.7/24 ipv6.method disabled

The Raspberry's IP address is 192.168.7.7 when a cable is connected. The Network Manager may need to be reloaded.

sudo nmcli con reload

Your PC on the other end then needs to be assigned a static (manual) IP address in the same network, e.g., 192.168.7.8.

==== Alternative ====

I found this method (Google AI) to use DHCP with higher priority, and then static IP if DHCP fails

sudo nmcli connection add type ethernet con-name "Wired-DHCP" ifname eth0 ipv4.method auto autoconnect yes connect.autoconnect-priority 1

sudo nmcli connection add type ethernet con-name "Robobot-Static7" ifname eth0 ipv4.method manual ipv4.addresses 192.168.7.7/24 ipv4.gateway 192.168.7.1 ipv4.dns 8.8.8.8 autoconnect yes connect.autoconnect-priority 0

This creates 2 entries in /etc/NetworkManager/system-connections (on a default Raspberry Pi 64 Bit OS using Network Manager)

/etc/NetworkManager/system-connections/Wired-DHCP.nmconnection

[connection]
id=Wired-DHCP
uuid=339844b1-cee4-4a43-a3f1-a5de05f3cb70
type=ethernet
autoconnect-priority=1
interface-name=eth0

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note! the UUID should be different''

/etc/NetworkManager/system-connections/Robobot-Static7.nmconnection

[connection]
id=Robobot-Static7
uuid=2a91ef05-3666-4293-a793-330c3b49cdd4
type=ethernet
interface-name=eth0

[ethernet]

[ipv4]
address1=192.168.7.7/24,192.168.7.1
dns=8.8.8.8;
method=manual

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

''Note2! To default to static IP can take 2-4 minutes after detecting the cable! (at least 2 times 60 second timeout is needed)''

On your laptop you can do the same, but probably more efficient, set to manual IP v4.
This can be done using your GUI tools, or on Linux:

sudo ip eth0 192.168.7.22

Note! ''eth0'' may be different, as modern hardware often has a more complex name, as ''eno1'' or ''enp108s0''.

Note2! If the robot has 192.168.7.7, then you should use something else for your laptop, e.g. 192.168.7.22.

Then ssh to the robot

ssh local@192.168.7.7

==== Install DNS server on Raspberry ====

This section may be deprecated, use the alternative method above with fallback to static IP.

Allow the connected PC to get an IP automatically; install DNSMASQ

sudo apt install dnsmasq

Configure the use by editing /etc/dnsmasq.conf

sudo nano /etc/dnsmasq.conf

Uncomment and change two lines. It is to be used on ETH0 only and in the IP range 192.168.7.50 to 192.168.7.99.

# DNS requests only on
# specified interface
interface=eth0
# range of addresses available for lease and optionally
# a lease time
dhcp-range=192.168.7.50,192.168.7.99,255.255.255.0,12h

Restart the dnsmasq

sudo service dnsmasq restart

To see the status of the dnsmasq service use:

journalctl -b0 -u dnsmasq.service

After this, when you plug in a cable to a PC, then, after some seconds, both the robot and the PC should have an IP in the range 192.168.7.x. And the robot should display the new IP 192.168.7.7.

You can now access the robot using
ssh local@192.168.7.7

==== Local link ====

Note: This method failed in most cases

If wifi is too slow or unavailable, a local link using a network cable could be the solution.

Many PCs will assign a local link IP like 168.254.x.x, and the Robot will do the same. The robot IP will be displayed on the small display but may be obscured if a Wi-Fi IP is available.

To prepare this behaviour, log in to the Raspberry using wifi (or attach a screen and keyboard) and make a preferred local-link cabled connection:

sudo nmcli con mod "Wired connection 1" ipv4.method link-local ipv6.method disabled

This should then be the behaviour after a reboot. "Wired connection 1" needs to be spelt this way; see the valid names using:

nmcli connection

Reload Network manager

sudo nmcli connection reload

== Check IP and SSID ==

When the Pi has rebooted, connect to it using SSH once again. Check that the Pi is connected to WiFi
ifconfig
Under '''wlan0''' confirm that the Pi has received an IP (inet addr) and note down the first three sections of the IP - they are most likely '''10.197.21x.xxx'''

To see which SSID you are connected to, use
iwconfig
or
nmcli -o

The MAC address ('HWaddr' or 'ether') of the Pi should also be noted down - this probably starts with '''B8:27:EB:xx:xx:xx''' make sure to get all of it.

===Find IP of robot (Linux)===

In case the Pi gets a new IP address after reboot, you can search for it using the MAC address and '''nmap'''. If '''nmap''' is not installed, start by installing it
sudo apt-get install nmap
To search for the Pi using the MAC address in terminal type
nmap -sP 10.197.218.0/20 | awk '/^Nmap/{ip=$NF}/B8:27:EB:23:A0:F5/{print ip}'
where '''10.197.218''' is the first three sections of the IP you noted down, 20 is the number of fixed bits (out of 32), and '''B8:27:EB:23:A0:F5''' is the MAC address of the Pi. This should return the IP of the Pi.

NB! the MAC can hold letters, they should probably be capital.

==== If you don't know the IP address====

Use the first part to get a list of active IPs on the net:
nmap -sP 10.197.218.0/24

The robot's name should be included in the list, but the network may take a while to detect it.

== NTP ==

'''Depreciated'''. The Raspberry default time sync now works, also at DTU.

Network Time Protocol is used to keep clocks in sync.
Raspberry Pi will start with the date and time of the last proper shutdown, and a few seconds after the network is up, it will sync the clock using NTP.

NTP need to be installed, i.e. 'sudo apt install ntp' if not done already.

At DTU, most clock sources are blocked; the clock source needs to be configured.

At DTU, edit /etc/NTP.conf or /etc/ntpsec/ntp.conf and add ntp.ait.du.dk to the top of the server pool list.

sudo nano /etc/ntpsec/ntp.conf

...
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
pool ntp.ait.dtu.dk
...

Sync time (if on DTU net)

sudo ntpdate -u ntp.ait.dtu.dk

Should work in and around DTU - see also [[NTP howto]] for more details.

You can also check the status of the ntp service:

sudo systemctl status ntp.service

Robobot 2

2026-02-01T16:17:37Z

Jca:

Back to [[Robobot_B | Robobot]]

==Network Access==

[[file:O-led-display-ann.jpg | 400px]]

=== Install Putty ===

Putty is the recommended SSH client (see e.g. https://en.wikipedia.org/wiki/Comparison_of_SSH_clients).

Install Putty and connect to the IP address on the small robot display.

[[File:Putty_Screenshot.png|500px|Putty setup for SSH connection and IP]]
[[File:Putty_Screenshot_login_3.png|500px|Login with username ''local'' - password is found in the course ''resources'']]

Once connected, you have a command line control of the Raspberry Pi.

=== Alternative SSH connection ===

Most PCs have a command line and a command line SSH-client version, try

ssh local@10.197.218.202

See also the similar page [[Raspberry Pi directory structure for Robobot | Network access]].

==== Fail to connect ====

If the robot does not have an IP, consult [[Network_setup]] and maybe use the ''local link'' option.

== Access to files on Raspberry ==

All operating systems can be setup to access and modify files on Raspberry.

=== Windows ===

On a Windows computer ''WinScp'' is a satisfactory solution, but "RealFTP" may be cheaper:

Connect using the above address (and port 22), you could get something like:

[[File:RealFTP-screenshot.png | 500px | RealFTP (with Danish lead test)]]

=== Linux (and Mac?) ===

On Linux-based platforms, you could use SSHFS to mount a remote directory on your platform.

In a terminal, create an empty directory (here jjj) and mount the remote directory:

mkdir jjj
sshfs local@10.197.218.202: jjj
password:
cd jjj
ls
Documents Downloads git mission_start.bash Music on_reboot.bash rebootinfo.txt svn Video

In the 'sshfs' command, remember the ':' after the IP address.

Remember to unmount

umount jjj

Robobot B

2026-02-01T16:15:33Z

Jca: /* Overview */

Robobot is a robot platform for innovative applications, especially the annual DTU Robocup competition.

=Robobot=

[[File:robobot-in-blocks-2024.png | 600px]]
[[File:robobot-rev_8_frog.jpg | 400px]]

==Overview==

This section is intended for users.

* Getting started
** [[Robobot 1 | Power on]], start and shut down
** [[Robobot 2 | Network access]]
** [[Robobot 2b | Software update]]
** [[Robobot 3 | Camera view]]
** [[Robobot 4 | Python control]]
** [[Robobot 5 | Firmware tools]]
* System description
** [[Robobot architecture | System overview]] and top-level blocks description.
** [[Robobot MQTT-client]]
** [[Robobot webcam server]]
** [[Robobot teensy interface]]
** [[Robobot teensy firmware]]
** [[Robobot MQTT topics]]
** [[Robobot calibration]]
* Further details
** Start button to start mission, see first part of [[Enable autostart]]
** [[Robobot and MATLAB]] use of logfiles.
** [[Raspberry Pi directory structure for Robobot | Network access]], file share and directory structure.
** [[Robobot hardware]] items. Motors, sensors, plastic and screws.
** [[Robobot circuits]], PCB and circuit diagrams

==Developers notes==

This section contains notes on robot installation.

* [[Robobot install on Raspberry]] including all needed packages.
* DTU network and time setup: [[Network setup]]
* [[Robobot base software installation]] like teensy_interface
* [[Enable autostart]] and IP display as well as on_reboot script.
* [[Servo supply issue]] Especially the small servo X9MG.

Arduino firmware - one of these:
* Installation of [[Arduino and Teensy libraries]] when using the Arduino IDE.
* Installation of [[Visual studio support | Visual Studio Code]] when working on a standard PC. There may be further help here [[Import code to Visual Studio]]
* installation of [[Arduino command line support | Command line support]] for use on the Raspberry Pi.

Help and setup
* [[Help page Teensy_8]] from on-line command ''help''.
* [[Robobot processor]] initialise setup of Teensy (factory reset)
* [[Robobot Raspberry strange error]] Unexplained error (January 2026, Trixie image, not cloned).
* [[Robobot packing list]].
* [[Robobot logfile cleanup]].

Simulator (webots)
* https://github.com/WildWillyRobots/DtuRobocupWebots.git is a simulator for the DTU Robocup track for the 2025 track. Created by Jonas Sølvhøj.

Older pages

* Old [[robobot]] instructions are mostly deprecated
* Some architecture notes [[Robobot Teensy interface]].
* [[Robobot software description | Software description]] and examples.

Robobot 1

2026-02-01T16:13:33Z

Jca: /* Run mission */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''Power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm, turn 90 degrees left, and then take 5 images while blinking an LED on the IO board.

Press the green start button. It will take some 2-5 seconds for the Python script to load and start the mission.

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T16:11:59Z

Jca: /* Run mission */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''Power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm, turn 90 degrees left, and thereafter take 5 images (blinking an LED on the IO-board).

Press the start button. It will take some 2-5 seconds for the Python script to load and start the mission.

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T16:10:33Z

Jca: /* Run mission */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''Power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm and turn 90 degrees left.

Press the start button. It will take some 2-5 seconds for the Python script to load and start the mission.

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T16:09:58Z

Jca: /* Run mission */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''Power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm and turn 90 degrees left.

Press the start button. It will take some 2-4 seconds for the Python script to load and start the mission.

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T16:08:23Z

Jca: /* Power on */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''Power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm and turn 90 degrees left.

Press the start button

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T16:07:11Z

Jca: /* Power on */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software-off may be active, then press the small '''power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED band LED 14 will start blinking, but communication is not available for another 5-10 seconds.

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm and turn 90 degrees left.

Press the start button

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

File:Robobot teensy interfce LED.png

2026-02-01T16:04:48Z

Jca: LED 14

== Summary ==
LED 14

Robobot 1

2026-02-01T16:04:17Z

Jca: /* Robobot with Raspberry Pi */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==

===Power on===

Usually, the robot powers on, then the power switch is fully UP. Some switches have three positions.
If this fails, then the software off may be active, then press the small '''power ON''' button on the PCB (see image further down).

When the Raspberry is booted, the LED-band

[[file:robobot_teensy_interfce_LED.png | 600px]]

===Run mission===

By default, a mission is available to run 30cm and turn 90 degrees left.

Press the start button

===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T15:54:35Z

Jca: /* OFF and ON */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==
===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and back ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T15:52:39Z

Jca: /* OFF and ON */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==
===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''Power on'' button.

[[file:PCB-off-and-on.png | 700px]]

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot 1

2026-02-01T15:51:40Z

Jca: /* OFF and ON */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==
===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:PCB-off-and-on.png | 700px]]
[[file:Start-buttons.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''power'' button.

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot architecture

2026-02-01T15:30:29Z

Jca: /* Start buttons (and external power) */

Back to [[Robobot_B | Robobot]]

== Display and LED-band ==

=== O-LED display ===

[[file:o-led-display-ann.jpg | 500 px]]

The primary function of this display is the battery voltage. The AS encoder is not used by Robobot.

=== LED-band ===

[[file:led-band-annotated.jpg | 750px]]

The Teensy maintains the LED band. Most LEDs show sensor values. The last 3 LEDs can be set by commands to the Teensy.

== Hardware block overview ==

[[File:robobot-in-blocks-2024.png | 600px]]

Figure 1. The main hardware building blocks.

== Software building blocks ==

[[File:robobot-function-blocks.png | 600px]]

Figure 2. The main software building blocks.

The blocks marked with a blue dot are available in the repository as source code.

==== Mission app====
The mission app block is the robot's top-level controller.

It can subscribe to data streams from the Teensy interface and command the robot to perform actions (like forward and turn velocity).
It attaches to the camera video stream and connects to the IO board (e.g. the start and stop buttons.

The mission app is in svn/robobot/mqtt_python; its main file is ''mqtt-client.py.''

==== Teensy interface ====

The Teensy interface connects the Teensy USB interface and the MQTT protocol.

The Teensy interface further has closed-loop control for forward velocity and implements turn-rate commands.

The interface decodes many essential data types and allows these data streams to be logged.
The logged files are text-based and intended for Matlab for analysis and debugging.
See more details in [[Robobot teensy interface]].

==== Mosquitto MQTT server ====

This Mosquitto server is an open-source MQTT protocol server - see https://mosquitto.org/.
This server is running as a service.

==== Camera streamer====

The camera streamer is a small Python app that takes data from the camera and streams the video to socket port 7123.
This means that the stream is also available on Wi-Fi.
See [[Robobot webcam server]] for more details

==== IP-disp ====

IP_disp is a silent app that is started at reboot (by ''on_reboot.bash'') and has two tasks:
* Detect the IP net address of the Raspberry and send it to the small display on the Teensy board (inactive if the Teensy_interface is running.)
* Detect if the "start" button is pressed, and start the mission app.
* Detect if the "start" button is pressed for more than 5 seconds to shut down the robot.

==== Digital IO ====

This is the board on top of the Robobot. It provides digital IO and a power supply for external devices.

The IO is connected to the Raspberry PI pins GPIO06 (stop), 13 (start), 16, 19, 20, 21, and 26.
See details in [[Robobot circuits]].

==== Teensy PCB ====

The Teensy board is a baseboard used in the more straightforward 'Regbot' robot.
This board has most of the hardware interfaces and offers all sensor data to be streamed in a publish-subscribe protocol.
All communication is based on clear text lines.

The firmware is in ''svn/robobot/teensy_firmware_8'', compiled with ''./compile'' and uploaded to the Teensy by ''./upload''. NB! An upload will cut the battery power, so press the ''power'' switch during upload.
See details in [[Robobot circuits]].

== Start buttons (and external power) ==

[[file:start-buttons.png | 600px]]

The two start buttons are quite different.
* The Arduino mission start will start the mission code in the Teensy.
* The IO Start button is read by ''ip_disp'' and starts the Python script mentioned in ''mission_start.bash''.

Both buttons can shut down the robot when pressed for 5 seconds.

The digital-io (except the start button) can only be used from the Python script.

=== External power ===

On the digital-io board, there are power pins available for 3V, 5V, and 12V. 12V is the battery voltage, which can vary from 10 to 16V.

Robobot processor

2026-02-01T15:12:03Z

Jca: /* Fresh software */

Back to [[Robobot_B | Robobot]]

== Reset of Teensy configuration ==

Configuration commands to update or initialize a Robobot with version 8 PCB.

=== Stop the Teensy user ===

If the Raspberry is running, then stop the ''teensy_interface''

pkill teensy_interfac

The last 'e' is missing; the process names are limited to 15 characters.

=== Fresh software ===

Upload the newly compiled software (from Raspberry or directly from a PC), e.g.

./upload
Teensy Loader, Command Line, Version 2.3
Read "build/teensy_firmware_8.ino.hex": 202752 bytes, 2.5% usage
Waiting for Teensy device...
(hint: press the reset button)

Remember to hold the ''power on'' button.

[[file:PCB-off-and-on.png | 700px]]

Disable the CRC check to make the console printout look better (interactive flag). This also prevents the Teensy from stopping communicating due to a lack of activity (60 seconds).

i 1

=== Fresh flash configuration ===

If the flash configuration has changed, then use these commands.

* Set robot number to ''invalid'' and save to flash:
setidx 0
eew
* Reboot the Teensy processor
reboot

=== Configure and calibrate ===

* Set a valid robot number
setidx <robot-number>
sethw 8
eew

The robot should now show the new name.

==== robot wheel configuration ====

Defaults should be OK for Robobot (to view current configuration, use ''confi''.)
confw rl rr gear TPR wb
confi 0.0750 0.0750 19 68 0.234

==== Line sensor ====
Place the robot on white tape (all sensors)
licw 100
Wait at least 100ms, then
eew

==== distance sensor ====
Values need to be found; use ''sub ir 200'' to see regular values (lists ''ir m m AD1 AD2'').
iron 1
irc A13 A50 B13 B50 1

Fair values
irc 15000 5000 15000 5000

==== gyro calibration ====
gyroc
==== logger flags ====

Use ''lfli'' to see current flags.
lfls 0 acc gyro 0 0 motv mota enc vel turnrate pose line dist batt timing 0 0

Default is OK

==== save to flash ====

Save to flash and turn off interactive mode.
eew
i 0

=== Start the ''teensy_interface'' ===

Either reboot the Raspberry or start the interface manually.

Reboot
sudo reboot now
Restart (with the no-logging option)
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l &

Robobot processor

2026-02-01T15:11:45Z

Jca: /* Fresh software */

Back to [[Robobot_B | Robobot]]

== Reset of Teensy configuration ==

Configuration commands to update or initialize a Robobot with version 8 PCB.

=== Stop the Teensy user ===

If the Raspberry is running, then stop the ''teensy_interface''

pkill teensy_interfac

The last 'e' is missing; the process names are limited to 15 characters.

=== Fresh software ===

Upload the newly compiled software (from Raspberry or directly from a PC), e.g.

./upload
Teensy Loader, Command Line, Version 2.3
Read "build/teensy_firmware_8.ino.hex": 202752 bytes, 2.5% usage
Waiting for Teensy device...
(hint: press the reset button)

Remember to hold the ''power'' button.

[[file:PCB-off-and-on.png | 700px]]

Disable the CRC check to make the console printout look better (interactive flag). This also prevents the Teensy from stopping communicating due to a lack of activity (60 seconds).

i 1

=== Fresh flash configuration ===

If the flash configuration has changed, then use these commands.

* Set robot number to ''invalid'' and save to flash:
setidx 0
eew
* Reboot the Teensy processor
reboot

=== Configure and calibrate ===

* Set a valid robot number
setidx <robot-number>
sethw 8
eew

The robot should now show the new name.

==== robot wheel configuration ====

Defaults should be OK for Robobot (to view current configuration, use ''confi''.)
confw rl rr gear TPR wb
confi 0.0750 0.0750 19 68 0.234

==== Line sensor ====
Place the robot on white tape (all sensors)
licw 100
Wait at least 100ms, then
eew

==== distance sensor ====
Values need to be found; use ''sub ir 200'' to see regular values (lists ''ir m m AD1 AD2'').
iron 1
irc A13 A50 B13 B50 1

Fair values
irc 15000 5000 15000 5000

==== gyro calibration ====
gyroc
==== logger flags ====

Use ''lfli'' to see current flags.
lfls 0 acc gyro 0 0 motv mota enc vel turnrate pose line dist batt timing 0 0

Default is OK

==== save to flash ====

Save to flash and turn off interactive mode.
eew
i 0

=== Start the ''teensy_interface'' ===

Either reboot the Raspberry or start the interface manually.

Reboot
sudo reboot now
Restart (with the no-logging option)
cd ~/svn/robobot/teensy_interface/build
./teensy_interface -l &

Robobot 1

2026-02-01T15:10:20Z

Jca: /* OFF and ON */

back to [[Robobot_B | Robobot]]

== Robobot with Raspberry Pi==
===Battery===

The battery is an 11V 2.2 Ah 3-cell Lipo. Its power consumption (when not moving) is 0.3-0.5A, so it can sustain about 4 hours of use.

Robobot will cut power when the battery voltage is below 10V to protect the battery.

The Battery is (probably) charged to storage level (~40% of full capacity), so start by charging it.

===Power supply===

A 230V power supply, which supplies 15V and 6A, is available and intended for use during development.

=== OFF and ON ===

Preferably, turn the power off by holding the ''Start'' button for more than 5 seconds.

[[file:PCB-off-and-on.png | 700px]]

This will illuminate 3 LEDs in the LED band. These will gradually go off, and then the power will be cut.

The Teensy display will show ''power off in XX seconds'' while waiting for the Raspberry to shut down. And usually 10 seconds longer, just in case.

The Raspberry will be asked to ''shutdown'' during the wait time.

To power on, press the ''power'' button.

The ''power cut'' switch should not be used while the Raspberry is running.
It will usually be OK, but the disk may crash.

===Raspberry Pi shutdown===

The Raspberry Pi can alternatively be shut down from the command line.

Use the command
sudo shutdown now
Then, wait about 30 seconds before cutting the power.

This will ensure that all open files are closed correctly and that the system date and time are stored for the next boot.

Robobot B

2026-02-01T15:09:07Z

Jca:

Robobot is a robot platform for innovative applications, especially the annual DTU Robocup competition.

=Robobot=

[[File:robobot-in-blocks-2024.png | 600px]]
[[File:robobot-rev_8_frog.jpg | 400px]]

==Overview==

This section is intended for users.

* Getting started
** [[Robobot 1 | Battery power]] and shut down
** [[Robobot 2 | Network access]]
** [[Robobot 2b | Software update]]
** [[Robobot 3 | Camera view]]
** [[Robobot 4 | Python control]]
** [[Robobot 5 | Firmware tools]]
* System description
** [[Robobot architecture | System overview]] and top-level blocks description.
** [[Robobot MQTT-client]]
** [[Robobot webcam server]]
** [[Robobot teensy interface]]
** [[Robobot teensy firmware]]
** [[Robobot MQTT topics]]
** [[Robobot calibration]]
* Further details
** Start button to start mission, see first part of [[Enable autostart]]
** [[Robobot and MATLAB]] use of logfiles.
** [[Raspberry Pi directory structure for Robobot | Network access]], file share and directory structure.
** [[Robobot hardware]] items. Motors, sensors, plastic and screws.
** [[Robobot circuits]], PCB and circuit diagrams

==Developers notes==

This section contains notes on robot installation.

* [[Robobot install on Raspberry]] including all needed packages.
* DTU network and time setup: [[Network setup]]
* [[Robobot base software installation]] like teensy_interface
* [[Enable autostart]] and IP display as well as on_reboot script.
* [[Servo supply issue]] Especially the small servo X9MG.

Arduino firmware - one of these:
* Installation of [[Arduino and Teensy libraries]] when using the Arduino IDE.
* Installation of [[Visual studio support | Visual Studio Code]] when working on a standard PC. There may be further help here [[Import code to Visual Studio]]
* installation of [[Arduino command line support | Command line support]] for use on the Raspberry Pi.

Help and setup
* [[Help page Teensy_8]] from on-line command ''help''.
* [[Robobot processor]] initialise setup of Teensy (factory reset)
* [[Robobot Raspberry strange error]] Unexplained error (January 2026, Trixie image, not cloned).
* [[Robobot packing list]].
* [[Robobot logfile cleanup]].

Simulator (webots)
* https://github.com/WildWillyRobots/DtuRobocupWebots.git is a simulator for the DTU Robocup track for the 2025 track. Created by Jonas Sølvhøj.

Older pages

* Old [[robobot]] instructions are mostly deprecated
* Some architecture notes [[Robobot Teensy interface]].
* [[Robobot software description | Software description]] and examples.

Robobot logfile cleanup

2026-02-01T15:04:37Z

Jca: /* Logfiles */

Back to [[Robobot_B | Robobot]]

== Logfiles ==

Many logfiles will accumulate over time.

To clean up these files, there are two scripts in the setup directory.

A total cleanup could be:
cd ~/svn/robobot/setup
./clean_logfiles.bash
sudo ./clean_logfiles_sudo.bash

=== Files owned by ''local'' ===

This script removes all images from the mqtt_python directory and automatically generated log files.

clean_logfiles.bash:
#!/bin/bash
# clean logfiles before flash image
# teensy_interface
rm -r /home/local/svn/robobot/teensy_interface/build/log_20*
rm /home/local/svn/robobot/teensy_interface/build/out_*.txt
# mqtt_python
rm /home/local/svn/robobot/mqtt_python/image*.jpg
rm /home/local/svn/robobot/mqtt_python/log*.txt
# log
rm -r /home/local/svn/log/log_20*
rm /home/local/svn/log/ip_disp.out
rm /home/local/svn/log/log_*.txt
rm /home/local/svn/log/rebootinfo.txt
# these are owned by root
# rm /home/local/svn/log/rename_info.txt
# rm /home/local/svn/log/off_by*.txt
echo "all clean (except svn/log/rename_info.txt and off_by*.txt that is owned by root)"

=== Files owned by ''root'' ===

The host rename and off_by_mqtt run as user 'root', so the files are owned by 'root'.
These need to be removed with the ''sudo'' command.

clean_logfiles_sudo.bash:
#!/bin/bash
# clean logfiles before flash image
# these are owned by root
rm /home/local/svn/log/rename_info.txt
rm /home/local/svn/log/off_by*.txt
echo "all root-logfiles clean"

Robobot logfile cleanup

2026-02-01T15:03:45Z

Jca: /* Files owned by root */

Back to [[Robobot_B | Robobot]]

== Logfiles ==

Many logfiles will accumulate over time.

To clean up these files, there are two scripts in the setup directory.

A total cleanup could be:
cd ~/svn/robobot/setup
./clean_

=== Files owned by ''local'' ===

This script removes all images from the mqtt_python directory and automatically generated log files.

clean_logfiles.bash:
#!/bin/bash
# clean logfiles before flash image
# teensy_interface
rm -r /home/local/svn/robobot/teensy_interface/build/log_20*
rm /home/local/svn/robobot/teensy_interface/build/out_*.txt
# mqtt_python
rm /home/local/svn/robobot/mqtt_python/image*.jpg
rm /home/local/svn/robobot/mqtt_python/log*.txt
# log
rm -r /home/local/svn/log/log_20*
rm /home/local/svn/log/ip_disp.out
rm /home/local/svn/log/log_*.txt
rm /home/local/svn/log/rebootinfo.txt
# these are owned by root
# rm /home/local/svn/log/rename_info.txt
# rm /home/local/svn/log/off_by*.txt
echo "all clean (except svn/log/rename_info.txt and off_by*.txt that is owned by root)"

=== Files owned by ''root'' ===

The host rename and off_by_mqtt run as user 'root', so the files are owned by 'root'.
These need to be removed with the ''sudo'' command.

clean_logfiles_sudo.bash:
#!/bin/bash
# clean logfiles before flash image
# these are owned by root
rm /home/local/svn/log/rename_info.txt
rm /home/local/svn/log/off_by*.txt
echo "all root-logfiles clean"

Robobot logfile cleanup

2026-02-01T15:03:35Z

Jca: /* Files owned by local */

Back to [[Robobot_B | Robobot]]

== Logfiles ==

Many logfiles will accumulate over time.

To clean up these files, there are two scripts in the setup directory.

A total cleanup could be:
cd ~/svn/robobot/setup
./clean_

=== Files owned by ''local'' ===

This script removes all images from the mqtt_python directory and automatically generated log files.

clean_logfiles.bash:
#!/bin/bash
# clean logfiles before flash image
# teensy_interface
rm -r /home/local/svn/robobot/teensy_interface/build/log_20*
rm /home/local/svn/robobot/teensy_interface/build/out_*.txt
# mqtt_python
rm /home/local/svn/robobot/mqtt_python/image*.jpg
rm /home/local/svn/robobot/mqtt_python/log*.txt
# log
rm -r /home/local/svn/log/log_20*
rm /home/local/svn/log/ip_disp.out
rm /home/local/svn/log/log_*.txt
rm /home/local/svn/log/rebootinfo.txt
# these are owned by root
# rm /home/local/svn/log/rename_info.txt
# rm /home/local/svn/log/off_by*.txt
echo "all clean (except svn/log/rename_info.txt and off_by*.txt that is owned by root)"

=== Files owned by ''root'' ===

The host rename and off_by_mqtt run as user 'root', so the files are owned by 'root'.
These need to be removed with the ''sudo'' command.

clean_logfiles_sudo.bash:
#!/bin/bash
# clean logfiles before flash image
# these are owned by root
rm /home/local/svn/log/rename_info.txt
rm /home/local/svn/log/off_by*.txt
echo "all root-logfiles clean"

Robobot logfile cleanup

2026-02-01T15:03:23Z

Jca: Created page with "Back to Robobot == Logfiles == Many logfiles will accumulate over time. To clean up these files, there are two scripts in the setup directory. A total cleanup could be: cd ~/svn/robobot/setup ./clean_ === Files owned by ''local'' === This script removes all images from the mqtt_python directory and automatically generated log files. clean_logfiles.bash: #!/bin/bash # clean logfiles before flash image # teensy_interface rm -r /home/local/svn/r..."

Back to [[Robobot_B | Robobot]]

== Logfiles ==

Many logfiles will accumulate over time.

To clean up these files, there are two scripts in the setup directory.

A total cleanup could be:
cd ~/svn/robobot/setup
./clean_

=== Files owned by ''local'' ===

This script removes all images from the mqtt_python directory and automatically generated log files.

clean_logfiles.bash:
#!/bin/bash
# clean logfiles before flash image
# teensy_interface
rm -r /home/local/svn/robobot/teensy_interface/build/log_20*
rm /home/local/svn/robobot/teensy_interface/build/out_*.txt
# mqtt_python
rm /home/local/svn/robobot/mqtt_python/image*.jpg
rm /home/local/svn/robobot/mqtt_python/log*.txt
# log
rm -r /home/local/svn/log/log_20*
rm /home/local/svn/log/ip_disp.out
rm /home/local/svn/log/log_*.txt
rm /home/local/svn/log/rebootinfo.txt
# these are owned by root
# rm /home/local/svn/log/rename_info.txt
# rm /home/local/svn/log/off_by*.txt
echo "all clean (except svn/log/rename_info.txt and off_by*.txt that is owned by root)"

=== Files owned by ''root'' ===

The host rename and off_by_mqtt run as user 'root', so the files are owned by 'root'.
These need to be removed with the ''sudo'' command.

clean_logfiles_sudo.bash:
#!/bin/bash
# clean logfiles before flash image
# these are owned by root
rm /home/local/svn/log/rename_info.txt
rm /home/local/svn/log/off_by*.txt
echo "all root-logfiles clean"