Back to [[Ricbot]]

== 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

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

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

=== 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)
...

== D435 failed at reboot ==

The RealSense D435 is connected to a powered USB3 hub.
The Raspberry is powered by a 5V supply through expansion pins.
It is a default 64-bit Raspberry Pi OS:
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian

=== error ===
At times (after reboot), I can no longer enumerate RealSense devices, and I get:
$ rs-enumerate-devices
15/05 09:00:33,247 ERROR [140732254925120] (handle-libusb.h:125) failed to claim usb interface: 0, error: RS2_USB_STATUS_BUSY
15/05 09:00:33,249 ERROR [140732304337472] (uvc-sensor.cpp:428) acquire_power failed: failed to set power state
15/05 09:00:33,251 ERROR [140732304337472] (rs.cpp:280) [rs2_create_device( info_list:0x555598c13730, index:0 ) UNKNOWN] failed to set power state
15/05 09:00:33,251 ERROR [140732304337472] (rs.cpp:280) [rs2_delete_device( device:nullptr ) UNKNOWN] null pointer passed for argument "device"
Could not create device - failed to set power state . Check SDK logs for details
No device detected. Is it plugged in?

=== lsusb ===

But ''lsusb'' find the device

$ lsusb
Bus 004 Device 004: ID 8086:0b07 Intel Corp. RealSense D435
Bus 004 Device 005: ID 2676:ba05 Basler AG Vision Camera
Bus 004 Device 003: ID 05e3:0626 Genesys Logic, Inc. Hub
Bus 004 Device 002: ID 05e3:0626 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ricbot realsense

2026-05-15T07:04:19Z

Jca:

2026-04-28T07:02:35Z

Jca: /* Network manager */

RICbot Hotspot

2026-04-28T06:59:35Z

Jca: /* Raspberry hotspot */

Back to [[Ricbot]]

== Raspberry hotspot ==

If Wi-Fi is not available, then start your own hotspot.

=== Network manager ===

Network Manager do it all in one go:

sudo nmcli device wifi hotspot ssid <example-network-name> password <example-password>

This will also make an entry in ''/etc/NetworkManager/system-connections/'' called ''Hotspot.nmconnection''

# default setup without priority
[connection]
id=Hotspot
uuid=407d1e04-7971-4c33-9a71-c760c803ce9b
type=wifi
autoconnect=false
interface-name=wlan0

[wifi]
mode=ap
ssid=raspberry

[wifi-security]
group=ccmp;
key-mgmt=wpa-psk
pairwise=ccmp;
proto=rsn;
psk=pipiAnika

[ipv4]
method=shared

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

[proxy]

Set autoconnect to true and add a priority line to make this the last-resort priority (low negative value).

sudo nano /etc/NetworkManager/system-connections/Hotspot.nmconnection
# In the [connection] group, '''replace''' ''autoconnect=false'' with
autoconnect-priority=-50

RICbot Hotspot

2026-04-28T06:59:08Z

Jca: /* Network manager */

Back to [[Ricbot]]

== Raspberry hotspot ==

If Wi-Fi is not available, then start your own hotspot.

=== Network manager ===

Network Manager do it all in one go:

sudo nmcli device wifi hotspot ssid <example-network-name> password <example-password>

This will also make an entry in ''/etc/NetworkManager/system-connections/'' called ''Hotspot.nmconnection''

# default setup without priority
[connection]
id=Hotspot
uuid=407d1e04-7971-4c33-9a71-c760c803ce9b
type=wifi
autoconnect=false
interface-name=wlan0

[wifi]
mode=ap
ssid=raspberry

[wifi-security]
group=ccmp;
key-mgmt=wpa-psk
pairwise=ccmp;
proto=rsn;
psk=pipiAnika

[ipv4]
method=shared

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

[proxy]

Set autoconnect to true and add a priority line to make this the last-resort priority (low negative value).

sudo nano /etc/NetworkManager/system-connections/Hotspot.nmconnection
# In the [connection] group, replace autoconnect=false with
autoconnect-priority=-50

RICbot Hotspot

2026-04-28T06:36:34Z

Jca: Created page with "Back to Ricbot == Raspberry hotspot == If Wi-Fi is not available, then start your own hotspot. === Network manager === Network Manager do it all in one go: sudo nmcli device wifi hotspot ssid <example-network-name> password <example-password> This will also make an entry in ''/etc/NetworkManager/system-connections/'' called ''Hotspot.nmconnection'' [connection] id=Hotspot uuid=407d1e04-7971-4c33-9a71-c760c803ce9b type=wifi autoconnect=false interface-na..."

Ricbot

2026-04-28T06:29:00Z

Jca: /* Installation notes */

== 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.

== User support ==

* [[RIC start and stop | Start, drive and stop]]
* [[RIC data recording | Data recording]]

== Installation notes ==

* [[Ricbot hardware]]
* Ricbot installation of [[Ricbot realsense | Realsense]]
* [[Ricbot ROS2 | ROS2]] including bridge from MQTT to ROS2 messaging
* [[Ricbot GNSS | GNSS]] installation, including 'gpsd'
* [[Ricbot PTP | PTP]] time synchronization.
* Raspberry as [[RICbot Hotspot | hotspot]].

Ricbot GNSS

2026-04-26T15:17:31Z

Jca: /* Raspberry pi issue */

Back to [[Ricbot]]

== GNSS ==

Satellite positioning is implemented using a NEO-M9V receiver.
The receiver is connected to the navigation Raspberry Pi.

Additional installation

sudo apt install gpsd gpsd-clients libgps-dev

Support added to teensy_interface (not fully tested) - part of Robobot software.

=== Raspberry Pi issue ===

Starting gpsd as a service fails, but manually starting it works fine:
sudo gpsd -n -N -D3 /dev/ttyACM1

Starting the service fails, like:
local@Saturn:~ $ systemctl status gpsd
○ gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/usr/lib/systemd/system/gpsd.service; enabled; preset: enabled)
Active: inactive (dead)
TriggeredBy: × gpsd.socket
Docs: man:gpsd

Apr 26 13:02:52 Saturn systemd[1]: Dependency failed for gpsd.service - GPS (Global Positioning System) Daemon.
Apr 26 13:02:52 Saturn systemd[1]: gpsd.service: Job gpsd.service/start failed with result 'dependency'.

After a long search by Ecosia, I found a fix.

The /lib/systemd/system/gpsd.socket looked like this:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
ListenStream=[::]:2947
ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
BindIPv6Only=both

[Install]
WantedBy=sockets.target

Then uncommented most of these dependencies to listen to only 127.0.0.1:2947:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
#ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
#ListenStream=[::]:2947
#ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
#BindIPv6Only=both

[Install]
WantedBy=sockets.target

Then I could do
systemctl start gpsd
and verify with
cgps

=== Decode and publish ===

Using the 'gpsd' publisher. This should be easily interfaced to ROS.

see: https://kickstartembedded.com/2022/07/23/a-beginners-guide-to-using-gpsd-in-linux/

Ricbot GNSS

2026-04-26T11:29:25Z

Jca: /* Raspberry pi issue */

Back to [[Ricbot]]

== GNSS ==

Satellite positioning is implemented using a NEO-M9V receiver.
The receiver is connected to the navigation Raspberry Pi.

Additional installation

sudo apt install gpsd gpsd-clients libgps-dev

Support added to teensy_interface (not fully tested) - part of Robobot software.

=== Raspberry pi issue ===

Starting gpsd as a service fails, but manualy start works fine:
sudo gpsd -n -N -D3 /dev/ttyACM1

Starting the service fails, like:
local@Saturn:~ $ systemctl status gpsd
○ gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/usr/lib/systemd/system/gpsd.service; enabled; preset: enabled)
Active: inactive (dead)
TriggeredBy: × gpsd.socket
Docs: man:gpsd

Apr 26 13:02:52 Saturn systemd[1]: Dependency failed for gpsd.service - GPS (Global Positioning System) Daemon.
Apr 26 13:02:52 Saturn systemd[1]: gpsd.service: Job gpsd.service/start failed with result 'dependency'.

After a long search by Ecosia, I found a fix

The /lib/systemd/system/gpsd.socket looked like this:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
ListenStream=[::]:2947
ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
BindIPv6Only=both

[Install]
WantedBy=sockets.target

I the uncommented most of these dependencies to listen only to 127.0.0.1:2947:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
#ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
#ListenStream=[::]:2947
#ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
#BindIPv6Only=both

[Install]
WantedBy=sockets.target

Then I could do
systemctl start gpsd
and verify with
cgps

=== Decode and publish ===

Using the 'gpsd' publisher. This should be easily interfaced to ROS.

see: https://kickstartembedded.com/2022/07/23/a-beginners-guide-to-using-gpsd-in-linux/

Ricbot GNSS

2026-04-26T11:28:19Z

Jca: /* GNSS */

Back to [[Ricbot]]

== GNSS ==

Satellite positioning is implemented using a NEO-M9V receiver.
The receiver is connected to the navigation Raspberry Pi.

Additional installation

sudo apt install gpsd gpsd-clients libgps-dev

Support added to teensy_interface (not fully tested) - part of Robobot software.

=== Raspberry pi issue ===

Starting gpsd as a service fails, but manualy start works fine:
sudo gpsd -n -N -D3 /dev/ttyACM1

Starting the service fails, like:
local@Saturn:~ $ systemctl status gpsd
○ gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/usr/lib/systemd/system/gpsd.service; enabled; preset: enabled)
Active: inactive (dead)
TriggeredBy: × gpsd.socket
Docs: man:gpsd

Apr 26 13:02:52 Saturn systemd[1]: Dependency failed for gpsd.service - GPS (Global Positioning System) Daemon.
Apr 26 13:02:52 Saturn systemd[1]: gpsd.service: Job gpsd.service/start failed with result 'dependency'.

After a long search by Ecosia, I found a fix

The /lib/systemd/system/gpsd.socket looked like this:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
ListenStream=[::]:2947
ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
BindIPv6Only=both

[Install]
WantedBy=sockets.target

I the uncommented most of these dependecies to:
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/run/gpsd.sock
#ListenStream=[::1]:2947
ListenStream=127.0.0.1:2947
# To allow gpsd remote access, start gpsd with the -G option and
# uncomment the next two lines:
#ListenStream=[::]:2947
#ListenStream=0.0.0.0:2947
SocketMode=0600
#BindIPv6Only=yes
#BindIPv6Only=both

[Install]
WantedBy=sockets.target

Then I could do
systemctl start gpsd
and verify with
cgps

=== Decode and publish ===

Using the 'gpsd' publisher. This should be easily interfaced to ROS.

see: https://kickstartembedded.com/2022/07/23/a-beginners-guide-to-using-gpsd-in-linux/

Ricbot hardware

2026-04-25T16:07:54Z

Jca: /* On-Off */

Back to [[Ricbot]]

== Hardware ==

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

[[file: ric-hw-interface-ann.png | 500px]]

=== Interface board (Regbor 6.3) ===

Regbot 6.3: [[Regbot hardware board]]

[[file: ric-regbot-6.3-ann.png | 500px]]

* a) Power management split into 3 cables
** 1) To j17: (b1, r1, h1, y1) on power distribution board
** 2) To j11: (r2, h2, y2) on power management board (temp sensors)
** 3) To on/off switch
* b) Motor driver PWM and direction, 3 pins
* c) Encoder (optical) 4 pins on original 6-pin motor connector.
* d) IMU (I2C connection)
* e) Serial (LED-band) Rx8, TX8 (not working with LED-band (not DMA?))

==== 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 distribution ===

[[RICBOT Power on-off board]] PCB

[[file: ric-power-distribute-ann.png | 500px]]

==== Power management ====
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

==== Temperature ====

Pin IDC10 Software Function
1 black (nc) -- --
2 (red) 7 LS_4 (A8) Temp on board (not mounted)
3 (white) 8 LS_5 (A11) Temp power distribute (T1)
4 (yellow) 9 LS_6 (A9) Temp motor driver Left

==== On-Off ====

Power on is the mechanical on switch; connect the pins to ON.

Power off is via the Teensy and the other set of contacts of the on-switch. This set goes to IDC-pin 5 and 10. When this set is not connected, the Teensy will set the power management pin to low (power off). It then takes about 10 seconds to turn off.

==== Encoder ====

The encoder connection connects one type of plug (5 pins) from the encoder to another (4 pins) on the HW-interface board.

==== Temperature sensors ====

The on-board temperature sensor is not mounted.
The others are of type MCP9700A, extended with a cable to the 3-pin plug.

=== 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]].

Ricbot hardware

2026-04-25T16:03:18Z

Jca: /* Power distribution */

Back to [[Ricbot]]

== Hardware ==

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

[[file: ric-hw-interface-ann.png | 500px]]

=== Interface board (Regbor 6.3) ===

Regbot 6.3: [[Regbot hardware board]]

[[file: ric-regbot-6.3-ann.png | 500px]]

* a) Power management split into 3 cables
** 1) To j17: (b1, r1, h1, y1) on power distribution board
** 2) To j11: (r2, h2, y2) on power management board (temp sensors)
** 3) To on/off switch
* b) Motor driver PWM and direction, 3 pins
* c) Encoder (optical) 4 pins on original 6-pin motor connector.
* d) IMU (I2C connection)
* e) Serial (LED-band) Rx8, TX8 (not working with LED-band (not DMA?))

==== 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 distribution ===

[[RICBOT Power on-off board]] PCB

[[file: ric-power-distribute-ann.png | 500px]]

==== Power management ====
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

==== Temperature ====

Pin IDC10 Software Function
1 black (nc) -- --
2 (red) 7 LS_4 (A8) Temp on board (not mounted)
3 (white) 8 LS_5 (A11) Temp power distribute (T1)
4 (yellow) 9 LS_6 (A9) Temp motor driver Left

==== On-Off ====

Power on is the mechanical on switch; connect the pins to ON.

Power off is via the Teensy and the other set of contacts of the on-switch. This set goes to IDC-pin 5 and 10. When this set is not connected, the Teensy will set the power management pin to low (power off). It then takes about 10 seconds to turn off.

=== 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]].

Ricbot hardware

2026-04-25T15:56:54Z

Jca: /* Power distribution */

Back to [[Ricbot]]

== Hardware ==

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

[[file: ric-hw-interface-ann.png | 500px]]

=== Interface board (Regbor 6.3) ===

Regbot 6.3: [[Regbot hardware board]]

[[file: ric-regbot-6.3-ann.png | 500px]]

* a) Power management split into 3 cables
** 1) To j17: (b1, r1, h1, y1) on power distribution board
** 2) To j11: (r2, h2, y2) on power management board (temp sensors)
** 3) To on/off switch
* b) Motor driver PWM and direction, 3 pins
* c) Encoder (optical) 4 pins on original 6-pin motor connector.
* d) IMU (I2C connection)
* e) Serial (LED-band) Rx8, TX8 (not working with LED-band (not DMA?))

==== 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 distribution ===

[[RICBOT Power on-off board]] PCB

[[file: ric-power-distribute-ann.png | 500px]]

==== Power management ====
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

==== Temperature ====

Pin IDC10 Software Function
1 black (nc) -- --
2 (red) 7 LS_4 (A8) Temp on board (not mounted)
3 (white) 8 LS_5 (A11) Temp power distribute (T1)
4 (yellow) 9 LS_6 (A9) Temp motor driver Left

=== 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]].

File:Ric-power-distribute-ann.png

2026-04-25T15:20:36Z

Jca:

File:Ric-regbot-6.3-ann.png

2026-04-25T15:20:13Z

Jca:

Network setup

2026-04-20T12:33:39Z

Jca: /* PTP */

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.

For PTP, see [[Ricbot PTP]].

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-04-20T12:33:05Z

Jca: /* NTP */

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.

== PTP ==

Precise Time Protocol (on Raspberry Pi 5)

Assuming 2 Raspberry Pis are connected with an Ethernet cable, and both have an IP on eth0.

==== Install ====

Install on both master and slave:
sudo apt install linuxptp

Verify that there is support on 'eth0'.
Should have hardware capabilities:

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock

==== Test time master ====

Start connection to eth0 hardware (as a process in the background)

sudo phc2sys -s CLOCK_REALTIME -c eth0 -w &

Start clock master service on eth0

sudo ptp4l -i eth0 -m -2 -s

It should be activated as a grand master soon.

==== Test time client ====

Run a PTP test slave (-s) with output to console (-m).

sudo ptp4l -i eth0 -m -2 -s

After a few minutes, this should yield a time offset on the order of 100 ns.

Kill the phc2sys on the time server after the client test:
sudo pkill phc2sys

==== Install as a service on Master ====

Most is copied from https://austinsnerdythings.com/2025/02/18/nanosecond-accurate-ptp-server-grandmaster-and-client-tutorial-for-raspberry-pi/.

Create a service file for the connection to eth0:

sudo nano /etc/systemd/system/phc2sys-grandmaster.service

With:
[Unit]
Description=sync PHC with system clock (grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/phc2sys -s CLOCK_REALTIME -c eth0 -w
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Create a service file for the ptp server:

sudo nano /etc/systemd/system/ptp4l-grandmaster.service

With:
[Unit]
Description=Precision Time Protocol (PTP) service (Grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Enable and start these services

sudo systemctl daemon-reload
sudo systemctl enable phc2sys-grandmaster.service
sudo systemctl enable ptp4l-grandmaster.service
sudo systemctl start phc2sys-grandmaster.service
sudo systemctl start ptp4l-grandmaster.service

==== Install as a service on the client ====

Make a new service file
sudo nano /etc/systemd/system/ptp4l-client.service
With:
[Unit]
Description=Precision Time Protocol (PTP) service (Client)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2 -m --summary_interval 3
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Also, enable and start this service:

sudo systemctl daemon-reload
sudo systemctl enable ptp4l-client.service
sudo systemctl start ptp4l-client.service

Check the status of the client when all is in place
sudo systemctl status ptp4l-client

== NTP ==

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

For PTP, see [[Ricbot PTP]].

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

Ricbot PTP

2026-04-20T12:30:57Z

Jca: /* Install as a service on the client */

Back to [[Ricbot]]

== PTP ==

Precise Time Protocol (on Raspberry Pi 5)

Assuming 2 Raspberry Pis are connected with an Ethernet cable, and both have an IP on eth0.

=== Install ===

Install on both master and slave:
sudo apt install linuxptp

Verify that there is support on 'eth0'.
Should have hardware capabilities:

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock

=== Test time master ===

Start connection to eth0 hardware (as a process in the background)

sudo phc2sys -s CLOCK_REALTIME -c eth0 -w &

Start clock master service on eth0

sudo ptp4l -i eth0 -m -2

It should be activated as a grand master soon.

=== Test time client ===

Run a PTP test slave (-s) with output to console (-m).

sudo ptp4l -i eth0 -m -2 -s

After a few minutes, this should yield a time offset on the order of 100 ns.

Kill the phc2sys on the time server after the client test:
sudo pkill phc2sys

=== Install as a service on Master ===

Most is copied from https://austinsnerdythings.com/2025/02/18/nanosecond-accurate-ptp-server-grandmaster-and-client-tutorial-for-raspberry-pi/.

Create a service file for the connection to eth0:

sudo nano /etc/systemd/system/phc2sys-grandmaster.service

With:
[Unit]
Description=sync PHC with system clock (grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/phc2sys -s CLOCK_REALTIME -c eth0 -w
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Create a service file for the ptp server:

sudo nano /etc/systemd/system/ptp4l-grandmaster.service

With:
[Unit]
Description=Precision Time Protocol (PTP) service (Grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Enable and start these services

sudo systemctl daemon-reload
sudo systemctl enable phc2sys-grandmaster.service
sudo systemctl enable ptp4l-grandmaster.service
sudo systemctl start phc2sys-grandmaster.service
sudo systemctl start ptp4l-grandmaster.service

=== Install as a service on the client ===

Make a new service file
sudo nano /etc/systemd/system/ptp4l-client.service
With:
[Unit]
Description=Precision Time Protocol (PTP) service (Client)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2 -m --summary_interval 3
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Also, enable and start this service:

sudo systemctl daemon-reload
sudo systemctl enable ptp4l-client.service
sudo systemctl start ptp4l-client.service

Check the status of the client when all is in place
sudo systemctl status ptp4l-client

Ricbot PTP

2026-04-20T12:29:08Z

Jca: /* Test time master */

Ricbot PTP

2026-04-20T12:28:36Z

Jca: /* Test time client */

Back to [[Ricbot]]

== PTP ==

Precise Time Protocol (on Raspberry Pi 5)

Assuming 2 Raspberry Pis are connected with an Ethernet cable, and both have an IP on eth0.

=== Install ===

Install on both master and slave:
sudo apt install linuxptp

Verify that there is support on 'eth0'.
Should have hardware capabilities:

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock

=== Test time master ===

Start connection to eth0 hardware (as a process in the background)

sudo phc2sys -s CLOCK_REALTIME -c eth0 -w &

Start clock master service on eth0

sudo ptp4l -i eth0 -m -2 -s

It should be activated as a grand master soon.

=== Test time client ===

Run a PTP test slave (-s) with output to console (-m).

sudo ptp4l -i eth0 -m -2 -s

After a few minutes, this should yield a time offset on the order of 100 ns.

Kill the phc2sys on the time server after the client test:
sudo pkill phc2sys

=== Install as a service on Master ===

Most is copied from https://austinsnerdythings.com/2025/02/18/nanosecond-accurate-ptp-server-grandmaster-and-client-tutorial-for-raspberry-pi/.

Create a service file for the connection to eth0:

sudo nano /etc/systemd/system/phc2sys-grandmaster.service

With:
[Unit]
Description=sync PHC with system clock (grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/phc2sys -s CLOCK_REALTIME -c eth0 -w
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Create a service file for the ptp server:

sudo nano /etc/systemd/system/ptp4l-grandmaster.service

With:
[Unit]
Description=Precision Time Protocol (PTP) service (Grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Enable and start these services

sudo systemctl daemon-reload
sudo systemctl enable phc2sys-grandmaster.service
sudo systemctl enable ptp4l-grandmaster.service
sudo systemctl start phc2sys-grandmaster.service
sudo systemctl start ptp4l-grandmaster.service

=== Install as a service on the client ===

Make a new service file
sudo nano /etc/systemd/system/ptp4l-client.service
With:
[Unit]
Description=Precision Time Protocol (PTP) service (Client)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2 -m --summary_interval 3
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Also, enable and start this service:

sudo systemctl daemon-reload
sudo systemctl enable ptp4l-client.service
sudo systemctl start ptp4l-client.service

Check the status of the client when all is in place
sudo systemctl status ptp4l-client

Ricbot PTP

2026-04-20T12:27:32Z

Jca: Created page with "Back to Ricbot == PTP == Precise Time Protocol (on Raspberry Pi 5) Assuming 2 Raspberry Pis are connected with an Ethernet cable, and both have an IP on eth0. === Install === Install on both master and slave: sudo apt install linuxptp Verify that there is support on 'eth0'. Should have hardware capabilities: $ ethtool -T eth0 Time stamping parameters for eth0: Capabilities: hardware-transmit software-transmit hardware-receive..."

Back to [[Ricbot]]

== PTP ==

Precise Time Protocol (on Raspberry Pi 5)

Assuming 2 Raspberry Pis are connected with an Ethernet cable, and both have an IP on eth0.

=== Install ===

Install on both master and slave:
sudo apt install linuxptp

Verify that there is support on 'eth0'.
Should have hardware capabilities:

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock

=== Test time master ===

Start connection to eth0 hardware (as a process in the background)

sudo phc2sys -s CLOCK_REALTIME -c eth0 -w &

Start clock master service on eth0

sudo ptp4l -i eth0 -m -2 -s

It should be activated as a grand master soon.

=== Test time client ===

Run a PTP test slave (-s) with output to console (-m).

sudo ptp4l -i eth0 -m -2 -s

After a few minutes, this should yield a time offset on the order of 100 ns.

Kill the phc2sys on the time server after the client test:
sudo pkill phc2sys

=== Install as a service on Master ===

Most is copied from https://austinsnerdythings.com/2025/02/18/nanosecond-accurate-ptp-server-grandmaster-and-client-tutorial-for-raspberry-pi/.

Create a service file for the connection to eth0:

sudo nano /etc/systemd/system/phc2sys-grandmaster.service

With:
[Unit]
Description=sync PHC with system clock (grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/phc2sys -s CLOCK_REALTIME -c eth0 -w
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Create a service file for the ptp server:

sudo nano /etc/systemd/system/ptp4l-grandmaster.service

With:
[Unit]
Description=Precision Time Protocol (PTP) service (Grandmaster)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Enable and start these services

sudo systemctl daemon-reload
sudo systemctl enable phc2sys-grandmaster.service
sudo systemctl enable ptp4l-grandmaster.service
sudo systemctl start phc2sys-grandmaster.service
sudo systemctl start ptp4l-grandmaster.service

=== Install as a service on the client ===

Make a new service file
sudo nano /etc/systemd/system/ptp4l-client.service
With:
[Unit]
Description=Precision Time Protocol (PTP) service (Client)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/sbin/ptp4l -i eth0 -2 -m --summary_interval 3
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Also, enable and start this service:

sudo systemctl daemon-reload
sudo systemctl enable ptp4l-client.service
sudo systemctl start ptp4l-client.service

Check the status of the client when all is in place
sudo systemctl status ptp4l-client

Ricbot

2026-04-20T12:26:41Z

Jca: /* Installation notes */

Ricbot

2026-04-20T12:21:48Z

Jca: /* User support */

Ricbot GNSS

2026-04-20T12:20:15Z

Jca: Created page with "Back to Ricbot == GNSS == Satellite positioning is implemented using a NEO-M9V receiver. The receiver is connected to the navigation Raspberry Pi. === Decode and publish === Using the 'gpsd' publisher. This should be easily interfaced to ROS. (not implemented yet)"

Back to [[Ricbot]]

== GNSS ==

Satellite positioning is implemented using a NEO-M9V receiver.
The receiver is connected to the navigation Raspberry Pi.

=== Decode and publish ===

Using the 'gpsd' publisher. This should be easily interfaced to ROS.
(not implemented yet)

RIC data recording

2026-04-20T12:16:17Z

Jca: /* Camera data */

Back to [[Ricbot]]

== Data recording ==

=== Internal robot data ===

Handled by the (left) navigation Raspberry Pi.

By default, the Teensy interface (teensy_interface) runs on the Raspberry Pi.
This will record most of the available data, like:
* Odometry
* Gyro and accelerometer data from the on-board IMU.
* Motor voltage and velocity of each wheel.
* MQTT communication
* GNSS data (when operational)

This data will be on the Pi in this directory
/home/local/svn/robobot/teensy_interface/build/log_yyyymmdd_hhmmss
The date and time part will be when the interface started. Note that for now, it requires the Pi to be on a public network. If not, the date will be the last proper shutdown date.

The intention is to adjust the time if GNSS coverage is available, but this has not yet been implemented.

=== Camera data ===

Handled by the right Raspberry Pi.

For now, image capture starts at boot via the script 'on_reboot.bash' in the home directory of the user 'local'.

The RealSense example code 'rs-save-to-disk' has been modified to save data from a single camera.

It takes 2 parameters, like:
rs-save-to-disk 1234567890 D455
where the camera serial number is the first parameter, and the camera type is the second.

For now, D455 will run at 5 FPS, and D435 at 6 FPS.
Both camera types will save one imageset per second. An imageset consists of an RGB image (in PNG format) and a coloured point cloud (in PYR format).

=== Time stamping ===

The two Raspberry Pis are connected via a network cable and time-synchronised using PTP.
The navigation Raspberry is the time master.