Rsewiki - User contributions [en]

Ricbot network issues

2026-09-02T13:36:50Z

Jca: /* Network Manager */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as default route ===

On robots with a cabled local network without internet access, it is annoying that the wifi connection is not the default route for, e.g., updating the operating system.

See the default connection, like:
ip route
default via 192.168.7.6 dev eth0 proto dhcp src 192.168.7.22 metric 52
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 600
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 600
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.22 metric 52

Here, the default is 192.168.7.6, the wired connection without internet access.

==== Solution ====

This can be fixed by using connection metrics. A low metric is the preferred connection.

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip route
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 24
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 24
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.4 metric 56
Now the default is wlan0, with the best metric.

Ricbot network issues

2026-09-02T13:26:38Z

Jca: /* Set Wi-Fi as the primary www channel */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as the primary www channel ===

On robots with a cabled local network without internet, it is annoying that the wifi connection is not the default route for e.g., updating the operating system.

See the default connection, like:
ip route
default via 192.168.7.6 dev eth0 proto dhcp src 192.168.7.22 metric 52
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 600
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 600
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.22 metric 52

Here, the default is 192.168.7.6, the wired connection without www access.

==== Solution ====

This can be fixed by using connection metrics. A low metric is the preferred connection.

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip route
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 24
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 24
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.4 metric 56
Now the default is wlan0, with the best metric.

Ricbot network issues

2026-09-02T13:26:21Z

Jca: /* Solution */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as the primary www channel ===

On robots with a cabled local network without internet, it is annoying that the wifi connection is not the default route for e.g., updating the operating system.

See the default connection, like:
ip r
default via 192.168.7.6 dev eth0 proto dhcp src 192.168.7.22 metric 52
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 600
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 600
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.22 metric 52

Here, the default is 192.168.7.6, the wired connection without www access.

==== Solution ====

This can be fixed by using connection metrics. A low metric is the preferred connection.

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip route
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 24
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 24
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.4 metric 56
Now the default is wlan0, with the best metric.

Ricbot network issues

2026-09-02T13:24:19Z

Jca: /* Solution */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as the primary www channel ===

On robots with a cabled local network without internet, it is annoying that the wifi connection is not the default route for e.g., updating the operating system.

See the default connection, like:
ip r
default via 192.168.7.6 dev eth0 proto dhcp src 192.168.7.22 metric 52
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 600
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 600
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.22 metric 52

Here, the default is 192.168.7.6, the wired connection without www access.

==== Solution ====

This can be fixed by using connection metrics. A low metric is the preferred connection.

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip r
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 24
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 24
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.4 metric 56
Now the default is wlan0, with the best metric.

Ricbot network issues

2026-09-02T13:22:50Z

Jca: /* Set Wi-Fi as the primary www channel */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as the primary www channel ===

On robots with a cabled local network without internet, it is annoying that the wifi connection is not the default route for e.g., updating the operating system.

See the default connection, like:
ip r
default via 192.168.7.6 dev eth0 proto dhcp src 192.168.7.22 metric 52
default via 10.197.208.1 dev wlan0 proto dhcp src 10.197.215.135 metric 600
10.197.208.0/21 dev wlan0 proto kernel scope link src 10.197.215.135 metric 600
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.22 metric 52

Here, the default is 192.168.7.6, the wired connection without www access.

==== Solution ====

This can be fixed by using connection metrics. A low metric is the preferred connection.

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip r

Ricbot network issues

2026-09-02T13:17:20Z

Jca: /* Set Wi-Fi as the primary www channel */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of some items found on the internet.

=== Set Wi-Fi as the primary www channel ===

Need a package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Restart NetworkManager
sudo systemctl restart NetworkManager.service

Check default connection with
ip r

Ricbot network issues

2026-09-02T13:13:48Z

Jca: /* Network Manager */

Ricbot network issues

2026-09-02T13:12:31Z

Jca: /* Set Wi-Fi as the primary www channel */

Back to [[Ricbot]]

== Network Manager ==

Just a summary of items found on the internet.

=== Set Wi-Fi as the primary www channel ===

Need an extra package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52

And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod mje6 ipv4.route-metric 23

Ricbot network issues

2026-09-02T13:11:40Z

Jca: Created page with "Back to Ricbot == Network Manager == Just a summary of items found on the internet. === Set Wi-Fi as the primary www channel === Need an extra package: sudo apt install ifmetric Get the connection names nmcli c NAME UUID TYPE DEVICE Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0 DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0 lo 8..."

Back to [[Ricbot]]

== Network Manager ==

Just a summary of items found on the internet.

=== Set Wi-Fi as the primary www channel ===

Need an extra package:
sudo apt install ifmetric

Get the connection names
nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 80468912-0922-305a-b845-e038e6a97530 ethernet eth0
DTUdevice 40daedca-0933-4103-87b9-e481d6db6fa4 wifi wlan0
lo 8de6fa00-08f6-4e2d-8251-9db7c4107077 loopback lo
mje6 3469ffdb-50a9-4af4-ac8d-2dd6bf1680ab wifi --

The first column is the name. Remember to escape any spaces.

Then change the metric for the cabled network - with a high metric
sudo nmcli c mod Wired\ connection\ 1 ipv4.route-metric 52
And the same for the Wi-Fi network - with a lower metric
sudo nmcli c mod DTUdevice ipv4.route-metric 22
sudo nmcli c mod DTUdevice ipv4.route-metric 23

Ricbot

2026-09-02T12:36:07Z

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) with a common trigger.
* GNSS recording.
* Manual remote control.

== User support ==

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

== Installation notes ==

* [[Ricbot hardware]] for driving and odometry.
* 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]].
* [[Basler Pylon]] installation
* [[Ricbot sensorbox | Sensorbox]] configuration
* [[Ricbot network issues]] especially when both cable and wifi is enabled.

Prepare for compile

2026-09-01T07:38:27Z

Jca: /* Visual Studio Code */

Back to [[Basebot]]

== Development environment (IDE) ==

The Basebot code can be maintained in either Arduino IDE, by Microsoft Visual Studio Code, or from the command line (using any editor).

Arduino and MS Code has requirements to the file name and directory structure.
The default naming follows the Arduino standard (the directory name and the ino file name must be the same).

== Arduino ==

Install Arduino support; see [[Arduino and Teensy libraries]]

Open Arduino and select the '''basebot_6.ino'''.

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

Then, set the board to Teensy 4.1.

[[file:arduino_set board.png | 500px]]

You should now be able to compile and upload the code to the robot.

==== Note ====

Editing the '''basebot ''' files in the '''src''' subdirectory can not be done in the Arduino IDE, but maybe that is unnecessary.

The '''basebot''' will send data to the serial monitor. This data needs to be stored in a file for Matlab use, and another serial monitor or other tool probably has to be used.

== Visual Studio Code ==

To use this tool, some directory structure and file names are required.

So; rename two files:
* In the directory (where the platformio.ini resides):
** rename the directory ''basebot_6'' to ''src''. (Otherwise, the code will not be found by MS Code.)
* In this renamed directory:
** rename basebot_6.ino to basebot_6.cpp. (Otherwise, code editor tools will be limited.)
** Note! On Windows, this changes the file type, so it must be visible. In the File Explorer, select ''View'' > ''Show'' > ''File name extensions'' before renaming.

Install MS Visual Studio and PlatformIO; see [[Visual studio support | Visual studio install]]

In MS-Code, open the basebot code using the PlatformIO icon [[file:MS_Visual_Studio_Code_Platform_IO_icon.png]]:

PlatformIO -> "QUICK ACCESS" -> "PIO Home" -> "Open" and here press "Open Project"

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

Find the ''Basebot'' directory - it contains the ''platformio.ini'' file needed to configure the project (i.e., Teensy 4.1 and the required libraries).

Then, PlatformIO will install dependencies and check the project. If there is an error, read the error text and try to fix it.

== Command line compile and upload ==

This is a possibility when running Linux.

Refer to the command-line installation instructions for Arduino.

There are two files in the project for compiling (compile) and uploading (upload); these assume that the command-line tools are installed.

Prepare for compile

2026-09-01T07:36:50Z

Jca: /* Development environment (IDE) */

Back to [[Basebot]]

== Development environment (IDE) ==

The Basebot code can be maintained in either Arduino IDE, by Microsoft Visual Studio Code, or from the command line (using any editor).

Arduino and MS Code has requirements to the file name and directory structure.
The default naming follows the Arduino standard (the directory name and the ino file name must be the same).

== Arduino ==

Install Arduino support; see [[Arduino and Teensy libraries]]

Open Arduino and select the '''basebot_6.ino'''.

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

Then, set the board to Teensy 4.1.

[[file:arduino_set board.png | 500px]]

You should now be able to compile and upload the code to the robot.

==== Note ====

Editing the '''basebot ''' files in the '''src''' subdirectory can not be done in the Arduino IDE, but maybe that is unnecessary.

The '''basebot''' will send data to the serial monitor. This data needs to be stored in a file for Matlab use, and another serial monitor or other tool probably has to be used.

== Visual Studio Code ==

To use this tool, some directory structure and file names are required.

So; rename two files:
* In the ''basebot'' directory (where the platformio.ini resides):
** rename the directory ''basebot_6'' to ''src''. (Otherwise, the code will not be found by Code.)
* In this renamed directory:
** rename basebot_6.ino to basebot_6.cpp. (Otherwise, code editor tools will be limited.)
** On Windows, this changes the file type, so the file type must be visible. In the File Explorer, select ''View'' > ''Show'' > ''File name extensions'' before renaming.

Install MS Visual Studio and PlatformIO; see [[Visual studio support | Visual studio install]]

In MS-Code, open the basebot code using the PlatformIO icon [[file:MS_Visual_Studio_Code_Platform_IO_icon.png]]:

PlatformIO -> "QUICK ACCESS" -> "PIO Home" -> "Open" and here press "Open Project"

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

Find the ''Basebot'' directory - it contains the ''platformio.ini'' file needed to configure the project (i.e., Teensy 4.1 and the required libraries).

Then, PlatformIO will install dependencies and check the project. If there is an error, read the error text and try to fix it.

== Command line compile and upload ==

This is a possibility when running Linux.

Refer to the command-line installation instructions for Arduino.

There are two files in the project for compiling (compile) and uploading (upload); these assume that the command-line tools are installed.

Prepare for compile

2026-09-01T07:34:39Z

Jca: /* Visual Studio Code */

Back to [[Basebot]]

== Development environment (IDE) ==

The Basebot code can be maintained in either Arduino IDE, by Microsoft Visual Studio Code, or from the command line (using any editor).

== Arduino ==

Install Arduino support; see [[Arduino and Teensy libraries]]

Open Arduino and select the '''basebot_6.ino'''.

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

Then, set the board to Teensy 4.1.

[[file:arduino_set board.png | 500px]]

You should now be able to compile and upload the code to the robot.

==== Note ====

Editing the '''basebot ''' files in the '''src''' subdirectory can not be done in the Arduino IDE, but maybe that is unnecessary.

The '''basebot''' will send data to the serial monitor. This data needs to be stored in a file for Matlab use, and another serial monitor or other tool probably has to be used.

== Visual Studio Code ==

To use this tool, some directory structure and file names are required.

So; rename two files:
* In the ''basebot'' directory (where the platformio.ini resides):
** rename the directory ''basebot_6'' to ''src''. (Otherwise, the code will not be found by Code.)
* In this renamed directory:
** rename basebot_6.ino to basebot_6.cpp. (Otherwise, code editor tools will be limited.)
** On Windows, this changes the file type, so the file type must be visible. In the File Explorer, select ''View'' > ''Show'' > ''File name extensions'' before renaming.

Install MS Visual Studio and PlatformIO; see [[Visual studio support | Visual studio install]]

In MS-Code, open the basebot code using the PlatformIO icon [[file:MS_Visual_Studio_Code_Platform_IO_icon.png]]:

PlatformIO -> "QUICK ACCESS" -> "PIO Home" -> "Open" and here press "Open Project"

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

Find the ''Basebot'' directory - it contains the ''platformio.ini'' file needed to configure the project (i.e., Teensy 4.1 and the required libraries).

Then, PlatformIO will install dependencies and check the project. If there is an error, read the error text and try to fix it.

== Command line compile and upload ==

This is a possibility when running Linux.

Refer to the command-line installation instructions for Arduino.

There are two files in the project for compiling (compile) and uploading (upload); these assume that the command-line tools are installed.

Visual studio support

2026-08-31T08:31:31Z

Jca: /* Visual Studio install */

Back to [[Basebot]]

== Install ==

=== Visual Studio Code install ===

Use your DTU account to get a free version of Visual Studio Code.

* Go to https://www.inside.dtu.dk/da/medarbejder under IT and software; there is a menu item "MS Visual Studio" that refers to https://azureforeducation.microsoft.com/devtools; go to this link.
* Sign in with your DTU mail and DTU password.
* Look for education software; this should get you to a long list of software.
[[File:MS_Visual_Studio_Azure_1.png | 500px]]
* Select "MS Visual Studio Code" and press the "download" button.
[[File:MS_Visual_Studio_Azure_2.png | 500px]]
* You can now download the software for your platform.
[[File:MS_Visual_Studio_Download_3.png | 500px]]

Install and start the app.

=== Visual Studio configure ===

Some extensions are needed.

In extensions, install C++

[[File:MS_Visual_Studio_Extension_1.png | 500px]]

== PlatformIO ==

Install the PlatformIO extension.

[[File:MS_Visual_Studio_Extension_2.png | 500px]]

=== Linux ===

The Python package python3-venv need to be installed.

sudo apt install python3-venv

Otherwise the installation stops and complains about no working Python.

Network setup

2026-08-18T09:03:47Z

Jca: /* DHCP with static IP fallback */

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 device wifi list

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

==== As its own hotspot ====

See [[RICbot Hotspot | hotspot]].

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

==== DHCP with static IP fallback ====

I found this method (Google AI) to use DHCP with higher priority, and then a 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.6
dns=192.168.7.6;
method=manual
never-default=yes

[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 efficiently, 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 ====

May be deprecated; use the alternative method above with fallback to a static IP.

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

sudo apt install dnsmasq

Configure its 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.60 to 192.168.7.70.

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

Restart dnsmasq

sudo service dnsmasq restart

To see the status of the dnsmasq service, use:

journalctl -b0 -u dnsmasq.service

After this, when you plug a cable into a PC, both the robot and the PC should have IP addresses in the 192.168.7. range within a minute or so. 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.
=== PTP ===
For PTP, see [[Ricbot PTP]].

=== NTP (depricated) ===
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

ASTA

2026-08-14T08:25:52Z

Jca: /* ASTA insides */

=Autonomous Systems Test Arena (building 330D)=

Our new facility for cooperating autonomous systems - in air, on the ground, on water and below the water surface.

[[File:asta_as_of_06_apr_2020_1.jpg | 450px]]

===Status===

28 June 2021:
Fully operational.

Official homepage: https://asta.dtu.dk/

Guidance for use: https://asta.dtu.dk/-/media/subsites/asta/documents/guidelines-and-instructions-for-using-asta-30-07-2024.pdf

DTU Electro page: https://electro.dtu.dk/research/research-facilities/autonomous-systems-test-arena

=== Instructions ===

* [[ASTA access]] - instruction for access

* [[ASTA pool]] - instructions for pool use and maintenance.

* [[ASTA motion capture]] - instructions for use

* [[ASTA booking]] - instructions for booking.

=== ASTA insides ===

* Looking [http://10.59.9.201:7123 South] [http://10.59.9.236:7123/?action=stream West] [http://10.59.9.222:8080/?action=stream North] (works on local net (10.59.8/9.x) only)

* [[Building history]] - pictures from process

===Maintainer===

This page is (mainly) maintained by Christian Andersen (jcan@dtu.dk)

ASTA

2026-08-14T08:25:35Z

Jca: /* ASTA insides */

=Autonomous Systems Test Arena (building 330D)=

Our new facility for cooperating autonomous systems - in air, on the ground, on water and below the water surface.

[[File:asta_as_of_06_apr_2020_1.jpg | 450px]]

===Status===

28 June 2021:
Fully operational.

Official homepage: https://asta.dtu.dk/

Guidance for use: https://asta.dtu.dk/-/media/subsites/asta/documents/guidelines-and-instructions-for-using-asta-30-07-2024.pdf

DTU Electro page: https://electro.dtu.dk/research/research-facilities/autonomous-systems-test-arena

=== Instructions ===

* [[ASTA access]] - instruction for access

* [[ASTA pool]] - instructions for pool use and maintenance.

* [[ASTA motion capture]] - instructions for use

* [[ASTA booking]] - instructions for booking.

=== ASTA insides ===

* Looking [http://10.59.9.201:7123 South] [http://10.59.9.236:8080/?action=stream West] [http://10.59.9.222:8080/?action=stream North] (works on local net (10.59.8/9.x) only)

* [[Building history]] - pictures from process

===Maintainer===

This page is (mainly) maintained by Christian Andersen (jcan@dtu.dk)

File:Ric-sensorbox-cables.png

2026-08-13T14:02:27Z

Jca: Cabling

== Summary ==
Cabling

Ricbot sensorbox

2026-08-13T14:01:49Z

Jca: /* Configuration */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system, 5V power from a separate 5V buck converter.
* Flash boards can further be connected and controlled by the common trigger system.

=== Cabling ===

[[file: ric-sensorbox-cables.png | 700px]]

Cabling overview for RIC sensorbox. A network connection can be established to RICBOT and/or to other networks or PCs.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

[[file: hv_gen_RIC_plug_use.png | 550px]]

Camera trigger control board and cable connections for cameras and power control for RIC sensor box.
Most components are for the high voltage driver and are not mounted.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 550px]]

Cable connections when used in the sensor box.

Ricbot sensorbox

2026-08-10T19:43:43Z

Jca: /* Configuration */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system, 5V power from a separate 5V buck converter.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

[[file: hv_gen_RIC_plug_use.png | 550px]]

Camera trigger control board and cable connections for cameras and power control for RIC sensor box.
Most components are for the high voltage driver and are not mounted.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 550px]]

Cable connections when used in the sensor box.

Ricbot sensorbox

2026-08-10T19:41:48Z

Jca: /* Camera trigger board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

[[file: hv_gen_RIC_plug_use.png | 550px]]

Camera trigger control board and cable connections for cameras and power control for RIC sensor box.
Most components are for the high voltage driver and are not mounted.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 550px]]

Cable connections when used in the sensor box.

File:Hv gen RIC plug use.png

2026-08-10T19:40:22Z

Jca: Used connectors

== Summary ==
Used connectors

Ricbot sensorbox

2026-08-10T19:39:12Z

Jca: /* Camera trigger board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

[[file: hv_gen_RIC_plug_use.png | 550px]]

Camera trigger control board, and cable connections for cameras and power control.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 550px]]

Cable connections when used in the sensor box.

Ricbot sensorbox

2026-08-10T17:48:59Z

Jca: /* Power distribute */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 550px]]

Cable connections when used in the sensor box.

Ricbot sensorbox

2026-08-10T17:48:47Z

Jca: /* Power distribute */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 500px]]

Cable connections when used in the sensor box.

File:Power-dist-RIC-use.png

2026-08-10T17:48:25Z

Jca: Connections on PCB

== Summary ==
Connections on PCB

Ricbot sensorbox

2026-08-10T17:47:49Z

Jca: /* Power distribute */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

[[file: power-dist-RIC-use.png | 400px]]

Cable connections when used in the sensor box.

Ricbot sensorbox

2026-08-09T19:00:44Z

Jca: /* LED flash board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses up to 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

Ricbot sensorbox

2026-08-09T18:59:01Z

Jca: /* Camera trigger board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is used to control one or two potential LED flash boards. The board also has a serial channel used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

The board sends a message to the Raspberry Pi every time the cameras are triggered. This message includes the trigger number used when images are saved.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

Ricbot sensorbox

2026-08-09T18:56:12Z

Jca: /* Camera trigger board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high-voltage generator, but this part is probably not populated.

The Teensy controls the power board through three plugs: J2 for system off and current status, J3 for temperature measurements and J4 for delayed on for cameras.

The camera trigger is J15 for the first camera and J16 for another camera, that can be delayed relative to the first camera.

J21 is to control one or two potential LED flash boards. The board further has a serial channel that is used to control the LED band.
A small display is used to display the IP (and other status) of the connected Raspberry Pi.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

Ricbot sensorbox

2026-08-09T18:46:24Z

Jca: /* Power distribute */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high voltage generator, but this part is probably not populated.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Q9, a P-channel power MOSFET, delivers power to the electronics, up to 10 A in total.

Q3 and Q4 deliver power to other circuits, e.g. motor drivers. This power can be switched on and off separately. Q1 and Q13 can switch this power off, using the emergency switch, or from software through Q14 and Q15.

Q5 and Q8 form a bistable switch. The output (drain on Q5) switches on the power. This can be overwritten by the on-switch through J5. From software, it can be switched off through Q6, delayed by C6 and R12. Q7 delivers 3.5V for the switch and for the temperature sensors, U1 and two external sensors, through J10 and J11.

Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off.

Ricbot sensorbox

2026-08-09T16:27:12Z

Jca: /* LED flash board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. Current control is done indirectly by the gate voltages of Q6, Q7, and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

The LEDs can tolerate 0.7A without degrading the colour temperature, and up to 1.4A.
The LED takes about 2.5V at 0.7A; this requires the supply voltage to be above 16V.
Each LED uses 1.75W, or the entire board uses 63W in pulses. At 3 images per second and a 300us illumination time, this then requires about 0.5W from the battery.

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high voltage generator, but this part is probably not populated.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

Ricbot sensorbox

2026-08-09T16:18:09Z

Jca: /* LED flash board */

Back to [[Ricbot]]

== Sensorbox ==

The sensorbox is a relatively self-contained box with camera sensors and electronics to support and record data from these sensors.

External requirements are power (14-29V) and about 20W.

Connection to odometry and GNSS are through cabled Ethernet and MQTT.

== Configuration ==

[[file: sensorbox-cabling.png | 500px]]

* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
* Raspberry Pi 5 (2) with SSD hard disk. This handles recording of all images. It has a cabled interface to the drive system of the RICbot (mainly for MQTT odometry). A recording start-pause button is connected to the Pi.
* 5V power board for the Raspberry Pi.
* The Pi cam is intended for forward-looking recording (a 12Mpixels camera with CS lens).
* A trigger management microprocessor (Teensy 4.0) that also manages the power distribution, the on-off switching and the status LED-band.
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* Possibly 2 multispectral IR cameras with their own recording system.
* Flash boards can further be connected and controlled by the common trigger system.

== Function ==

=== Startup ===

When power is connected (XT60 plug), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

==== Start-up issue ====

When everything is powered on at the same time, it happens that the cameras do not (all) get an IP in the right way, and thus are unavailable.

The reason is that the Raspberry Pi is running the DNS server providing the camera IP, but takes time to start, as does the network switch.
This could be handled by using a static camera IP, but at times it is appropriate to connect the camera switch to an established cabled network, where the camera IP should follow that network. This is needed to fully utilise the Basler Pylon software.

To solve this, the cameras will be supplied with a delayed turn-on.
The delayed turn-on utilises one of the two power plugs on the power distribution intended for motor power.
This allows the Raspberry Pi and the network switch to be ready before the cameras are turned on.
The turn-on delay is controlled by the microprocessor.

Delayed turn-on is not implemented yet (July 2026).

=== Trigger control ===

The microprocessor controls the triggers. It can issue 2 camera triggers and control an LED-based flash.

* Camera trigger 1 is intended for the Baslar cameras. It is a 3.3V signal, where the leading edge (low to high) is the trigger signal. The trailing edge should not be used. The pulse is at least 3ms.
* Camera trigger 2 is intended for the multi-spectral cameras and is also a 3.3V leading-edge signal. This signal can be delayed relative to the camera 1 signal.
* The flash signal is a positive pulse, where the delay and length are controllable.

Triggering is activated by a command from the Raspberry Pi by an MQTT message
* topic: 'dtubot/cmd/T0' message 'cam A B F R', where:
** 'cam' is the trigger command.
** 'A' is the delay from camera 1 trigger to camera 2 trigger in us. If zero, then there is no camera 2 trigger.
** 'B' is the delay to the start of the flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is the repeat timing in ms.
* Camera 1 is always triggered when the message is received.

Example:
* 'cam 0 0 0 1000': No camera 2 trigger, no flash, camera 1 trigger every 1000ms (1 sec).
* 'cam 100 200 50 1000': Camera 2 trigger 100us after camera 1, flash starts 200us after camera 1 and illuminates for 50us. All are retriggered every 1000ms (1 sec).
The trigger command is initiated by the ''cam_mqtt'' app in the ''svn/ricbot/cam_mqtt'' directory.
The trigger command is specified in the ''svn/ricbot/cam_mqtt/build'' directory, in the ''robot.ini'' file. The ''trigger'' group configures the trigger.

The robot.ini file, trigger part:
[trigger]
log = true
use = true
trigger_interval_ms = 1000
trigger_cam2_us = 0
trigger_flash_delay_us = 0
trigger_flash_duration_us = 0

== Recording control ==

The red button on the side of the box controls the recording.
* Pressed once starts recording.
* Pressing again will pause the recording.

When recording, there is an LED in the LED-band that will illuminate (orange) for every camera that is recording. If the camera is not found or has failed, the corresponding LED will not illuminate.

The red recording button is connected directly to the Raspberry Pi and monitored by the ''cam_mqtt'' app.

The recording is saved in the ''build'' directory for the ''cam_mqtt'' app. A new recording directory is generated with every reboot of the Raspberry Pi.

Images are saved at full camera resolution in .jpg format.

== Hardware PCB ==

=== LED flash board ===

[[file: LED_light_sch.png | 600px]]

PCB board for LED flash. 36 LEDs of type Osram GW-PLLRA2.PM-N4P4-XX57-1, a white LED with colour temperature 3000K. The current control is done indirectly by the gate voltage of Q6, Q7 and Q8. The gate voltage is controlled on-off by Q4 and Q5 from the ''pulse'' input. From about 3us and up. The maximum gate voltage is available from Q1, and the voltage is filtered by a low-pass filter R6/C4 from the ''intens_PWM'' input; this input should be above 50kHz.
An LED/driver temperature is available from the U3 sensor (analogue).

=== Camera trigger board ===

[[file: hv_gen_sch.png | 600px]]

Teensy 4.0 board for camera trigger. The same PCB is also used as an experimental high voltage generator, but this part is probably not populated.

=== Power distribute ===

[[file: power_distribute_sch.png | 600px]]

Power control board. Three separate power outlets, two high-power (XT60), originally for motors, but here for delayed power to cameras. Six XT30 plugs for electronics. And sockets for voltage display and temperature measurements.

File:LED light sch.png

2026-08-09T16:08:20Z

Jca: Jca uploaded a new version of File:LED light sch.png

== Summary ==
Schematig flash board

File:Power distribute sch.png

2026-08-08T17:13:57Z

Jca:

Ricbot sensorbox

2026-08-08T17:13:20Z

Jca: /* Hardware PCB */

File:Hv gen sch.png

2026-08-04T17:27:37Z

Jca: Camera trigger board

== Summary ==
Camera trigger board

File:LED light sch.png

2026-08-04T17:27:07Z

Jca: Schematig flash board

== Summary ==
Schematig flash board

Ricbot sensorbox

2026-08-04T17:26:32Z

Jca:

RIC start and stop

2026-07-31T05:31:52Z

Jca: /* Stop */

Back to [[Ricbot]]

== Drive system ==

Connect the big battery (60Ah 24V) using the red Anderson plug.

Turn on the on-off switch on the top of the electronics box.

It should now turn on.
* The two displays should show battery voltage (between 24.5 and 26.6V).
** The right is the electronics voltage
** The left is the voltage to the motor controllers. This should be off if the emergency switch is pushed.
* After a while (approx 90 seconds), the small (blue) display on the Teensy board should show the IP of the drive Raspberry Pi (currently named "Saturn").

=== Remote control ===

Use the Logitech gamepad marked 'ricbot'.

Press the 'back' button to get into manual control. The right joystick controls the driving.
The right-hand switch allows a faster speed when pressed.

=== Stop ===

To stop and shut down, turn off the on-off switch. There will be a delay of up to 60 seconds before the shutdown is implemented. If it is still on after 2 minutes, unplug the battery.

The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pis.

== Sensor box ==

=== Startup ===

When power is connected (XT60 plug to either a 15-29V supply or connected to the XT60 plug on the drive box), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

=== Start and pause recording ===

Press the red button to start and pause image recording. An LED in the LED band will be on for the camera's recording.
One or 2 green LEDS will be flashing to indicate that the cameras are triggered.

=== Shutdown ===

With the switch in the off position, an LED in the LED band will turn purple, and the Raspberry Pi will shut down, and power will be off after about 1 minute.

RIC start and stop

2026-07-31T05:30:39Z

Jca: /* Sensor box */

Back to [[Ricbot]]

== Drive system ==

Connect the big battery (60Ah 24V) using the red Anderson plug.

Turn on the on-off switch on the top of the electronics box.

It should now turn on.
* The two displays should show battery voltage (between 24.5 and 26.6V).
** The right is the electronics voltage
** The left is the voltage to the motor controllers. This should be off if the emergency switch is pushed.
* After a while (approx 90 seconds), the small (blue) display on the Teensy board should show the IP of the drive Raspberry Pi (currently named "Saturn").

=== Remote control ===

Use the Logitech gamepad marked 'ricbot'.

Press the 'back' button to get into manual control. The right joystick controls the driving.
The right-hand switch allows a faster speed when pressed.

=== Stop ===

To stop and shut down, turn off the on-off switch. There will be a delay of up to 60 seconds before the shutdown is implemented. If it is still on after 2 minutes, unplug the battery.

The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pi.

== Sensor box ==

=== Startup ===

When power is connected (XT60 plug to either a 15-29V supply or connected to the XT60 plug on the drive box), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

=== Start and pause recording ===

Press the red button to start and pause image recording. An LED in the LED band will be on for the camera's recording.
One or 2 green LEDS will be flashing to indicate that the cameras are triggered.

=== Shutdown ===

With the switch in the off position, an LED in the LED band will turn purple, and the Raspberry Pi will shut down, and power will be off after about 1 minute.

RIC start and stop

2026-07-31T05:25:37Z

Jca: /* shutdown */

Back to [[Ricbot]]

== Drive system ==

Connect the big battery (60Ah 24V) using the red Anderson plug.

Turn on the on-off switch on the top of the electronics box.

It should now turn on.
* The two displays should show battery voltage (between 24.5 and 26.6V).
** The right is the electronics voltage
** The left is the voltage to the motor controllers. This should be off if the emergency switch is pushed.
* After a while (approx 90 seconds), the small (blue) display on the Teensy board should show the IP of the drive Raspberry Pi (currently named "Saturn").

=== Remote control ===

Use the Logitech gamepad marked 'ricbot'.

Press the 'back' button to get into manual control. The right joystick controls the driving.
The right-hand switch allows a faster speed when pressed.

=== Stop ===

To stop and shut down, turn off the on-off switch. There will be a delay of up to 60 seconds before the shutdown is implemented. If it is still on after 2 minutes, unplug the battery.

The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pi.

== Sensor box ==

=== Startup ===

When power is connected (XT60 plug to either a 15-29V supply or connected to the XT60 plug on the drive box), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

=== Shutdown ===

With the switch in the off position, an LED in the LED band will turn purple, and the Raspberry Pi will shut down, and power will be off after about 1 minute.

RIC start and stop

2026-07-31T05:25:21Z

Jca:

Back to [[Ricbot]]

== Drive system ==

Connect the big battery (60Ah 24V) using the red Anderson plug.

Turn on the on-off switch on the top of the electronics box.

It should now turn on.
* The two displays should show battery voltage (between 24.5 and 26.6V).
** The right is the electronics voltage
** The left is the voltage to the motor controllers. This should be off if the emergency switch is pushed.
* After a while (approx 90 seconds), the small (blue) display on the Teensy board should show the IP of the drive Raspberry Pi (currently named "Saturn").

=== Remote control ===

Use the Logitech gamepad marked 'ricbot'.

Press the 'back' button to get into manual control. The right joystick controls the driving.
The right-hand switch allows a faster speed when pressed.

=== Stop ===

To stop and shut down, turn off the on-off switch. There will be a delay of up to 60 seconds before the shutdown is implemented. If it is still on after 2 minutes, unplug the battery.

The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pi.

== Sensor box ==

=== Startup ===

When power is connected (XT60 plug to either a 15-29V supply or connected to the XT60 plug on the drive box), nothing happens. The power board requires a start signal.

The power switch has 3 positions:
* The down position gives an on signal to the power distribution board.
* Centre position is neutral (on or off)
* Up is delayed off; leave in this position when off (forced off).

=== shutdown ===

With the switch in the off position, an LED in the LED band will turn purple, and the Raspberry Pi will shut down, and power will be off after about 1 minute.

RIC start and stop

2026-07-31T05:20:05Z

Jca:

RIC start and stop

2026-07-31T05:17:58Z

Jca: /* Stop */

Back to [[Ricbot]]

== Start ==

Connect the big battery (60Ah 24V) using the read Anderson plug.

Turn on the on-off switch on the top of the electronics box.

It should now turn on.
* The two displays should show battery voltage (between 24.5 and 26.6V).
** The right is the electronics voltage
** The left is the voltage to the motor controllers. This should be off if the emergency switch is pushed.
* After a while (approx 90 seconds), the small (blue) display on the Teensy board should show the IP of the drive Raspberry Pi (currently named "Saturn").

== Remote control ==

The Logitech gamepad marked 'ricbot' should be used.

Press the 'back' button to get into manual control. The right joystick controls the driving.
The right-hand switch allows a faster speed when pressed.

== Stop ==

To stop and shut down, turn off the on-off switch. There will be a delay of up to 60 seconds before the shutdown is implemented. If it is still on after 2 minutes, unplug the battery.

The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pi.

Ricbot sensorbox

2026-07-30T05:36:56Z

Jca: /* Configuration */

Ricbot sensorbox

2026-07-30T05:33:38Z

Jca: /* Configuration */

Ricbot sensorbox

2026-07-30T05:30:40Z

Jca: /* Start-up issue */

Ricbot sensorbox

2026-07-30T05:30:10Z

Jca: /* Startup */

Ricbot sensorbox

2026-07-30T05:27:16Z

Jca: /* Configuration */