Rsewiki - Recent changes [en]

RIC start and stop

Jca — Fri, 31 Jul 2026 05:31:52 GMT

Stop

← Older revision		Revision as of 07:31, 31 July 2026
(5 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	Back to [[Ricbot]]		Back to [[Ricbot]]

	== ~~Start~~ ==		== Drive system ==

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

	Turn on the on-off switch on the top of the electronics box.		Turn on the on-off switch on the top of the electronics box.
Line 13:		Line 13:
	* 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").		* 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 ==		=== Remote control ===

	~~The~~ Logitech gamepad marked 'ricbot' ~~should be used~~.		Use the Logitech gamepad marked 'ricbot'.

	Press the 'back' button to get into manual control. The right joystick controls the driving.		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.		The right-hand switch allows a faster speed when pressed.

	== Stop ==		=== 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 still on after 2 minutes, ~~then~~ unplug the battery.		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.

	~~To stop and~~ ensure the integrity of the ~~logfiles,~~ the Raspberry ~~Pi should be shut~~ down ~~properly~~.		The delay is to ensure the integrity of the log files and proper shutdown of the Raspberry Pis.
	~~The hardware~~ is in ~~place~~, ~~but~~ the ~~software is not~~.
			== 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.

Ricbot sensorbox

Jca — Thu, 30 Jul 2026 05:36:56 GMT

Configuration

← Older revision		Revision as of 07:36, 30 July 2026
(5 intermediate revisions by the same user not shown)
Line 13:		Line 13:
	[[file: sensorbox-cabling.png \| 500px]]		[[file: sensorbox-cabling.png \| 500px]]

	~~The sensorbox contains~~		* 4 Basler cameras (a2A2448-23gcBAS) with a 6mm C lens.
	* 4 Basler cameras		* 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.
	* A Raspberry Pi ~~version~~ 5 with SSD hard disk.		* 5V power board for the Raspberry Pi.
	* A trigger management microprocessor (Teensy 4.0)		* 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.		* A power distribution board with the ability for sequenced turn-on and turn-off.
	* 12 V supply for cameras and common trigger junction board.		* 12 V supply for cameras and common trigger junction board.
	* A forward-looking Raspberry Pi camera (12 Mpixel)		* Possibly 2 multispectral IR cameras with their own recording system.
	* Possibly 2 multispectral cameras.		* Flash boards can further be connected and controlled by the common trigger system.

	== Function ==		== Function ==
Line 29:		Line 30:

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

	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.		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 ~~cameras~~ should follow that network. This is needed to fully utilise the Basler Pylon software.		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.		To solve this, the cameras will be supplied with a delayed turn-on.
Line 45:		Line 46:
	The turn-on delay is controlled by the microprocessor.		The turn-on delay is controlled by the microprocessor.

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

	=== Trigger control ===		=== Trigger control ===

File:Sensorbox-cabling.png

Jca — Thu, 30 Jul 2026 05:15:33 GMT

Jca uploaded File:Sensorbox-cabling.png

New page

Ricbot sensorbox

Jca — Thu, 30 Jul 2026 05:15:17 GMT

Configuration

← Older revision		Revision as of 07:15, 30 July 2026
Line 10:		Line 10:

	== Configuration ==		== Configuration ==

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

	The sensorbox contains		The sensorbox contains

Ricbot hardware

Jca — Thu, 30 Jul 2026 05:12:45 GMT

Cabling

← Older revision		Revision as of 07:12, 30 July 2026
(One intermediate revision by the same user not shown)
Line 24:		Line 24:
	[[file: ric_cabling.png \| 500px]]		[[file: ric_cabling.png \| 500px]]

	DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042		* The battery can be replaced by a power supply using the XT60 input plug. 15 to 29V and 2-4A will do.
			* The power board includes 3 MOS switch transistors, two for the motors, and one for the remaining electronics. The board further holds temperature interface (for power board and motor driver).
			* Motor driver DRI0042: https://wiki.dfrobot.com/15A_Single_DC_Motor_Driver_SKU__DRI0042
			* Regbot 6.3 is a version of the Regbot that can control the motors and take input from wheel encoders. It further controls the power board and interface the IMU (MPU9250).
			* The Raspberry Pi 1 controls the drive system through the USB interface to the Teensy 4.1. All data are made available on MQTT.
			* The gamepad is for driving the vehicle.
			* The GNSS is for recording the actual position (not RTK).
			* The Raspberry Pi 3 (aux) is (pt) used as a wifi hotspot.
			* The Net switch is used to connect the two Raspberry Pis and the sensor box on a cabled network.

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

			The Regbot 6.3, power distribution and motor drivers are mounted on a common 3D print. This includes a fan.

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

File:Ric cabling.png

Jca — Thu, 30 Jul 2026 04:53:49 GMT

Jca uploaded a new version of File:Ric cabling.png

New page

Ricbot sensorbox

Jca — Wed, 29 Jul 2026 13:43:53 GMT

@@ Line 57: / Line 57: @@
 ** '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 start of flash in us.
+** '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 repeat timing in ms.
+** '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).

Ricbot sensorbox

Jca — Wed, 29 Jul 2026 06:05:50 GMT

Created page with "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 == The sensorbox contains * 4 Basler cameras * A Raspberry Pi version 5 with SSD hard disk. * A trigger management microprocessor (Teensy 4.0) * A power distri..."

New page

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

The sensorbox contains
* 4 Basler cameras
* A Raspberry Pi version 5 with SSD hard disk.
* A trigger management microprocessor (Teensy 4.0)
* A power distribution board with the ability for sequenced turn-on and turn-off.
* 12 V supply for cameras and common trigger junction board.
* A forward-looking Raspberry Pi camera (12 Mpixel)
* Possibly 2 multispectral cameras.

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

=== 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 start of flash in us.
** 'F' is the duration of the flash in us. If zero, then there is no flash signal.
** 'R' is 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).

Ricbot

Jca — Wed, 29 Jul 2026 05:15:11 GMT

Installation notes

← Older revision		Revision as of 07:15, 29 July 2026
(One intermediate revision by the same user not shown)
Line 20:		Line 20:
	== Installation notes ==		== Installation notes ==

	* [[Ricbot hardware]]		* [[Ricbot hardware]] for driving and odometry.
	* Ricbot installation of [[Ricbot realsense \| Realsense]]		* Ricbot installation of [[Ricbot realsense \| Realsense]]
	* [[Ricbot ROS2 \| ROS2]] including bridge from MQTT to ROS2 messaging		* [[Ricbot ROS2 \| ROS2]] including bridge from MQTT to ROS2 messaging
Line 27:		Line 27:
	* Raspberry as [[RICbot Hotspot \| hotspot]].		* Raspberry as [[RICbot Hotspot \| hotspot]].
	* [[Basler Pylon]] installation		* [[Basler Pylon]] installation
			* [[Ricbot sensorbox \| Sensorbox]] configuration

Ricbot hardware

Jca — Wed, 29 Jul 2026 05:08:23 GMT

← Older revision		Revision as of 07:08, 29 July 2026
Line 2:		Line 2:


	== ~~Hardware~~ ==		== Drive hardware ==

	Tentative layout:		Tentative layout:

Ricbot

Jca — Wed, 29 Jul 2026 05:06:28 GMT

Ricbot, a wheeled sensor platform

← Older revision		Revision as of 07:06, 29 July 2026
Line 9:		Line 9:
	* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.		* No more than 25-30 kg, requiring 1 or 2 persons to load or unload.
	* Wheel-odometry recording (and timestamped)		* Wheel-odometry recording (and timestamped)
	* Camera image recording (and timestamped)~~, the intention is Realsense D435~~.		* Camera image recording (and timestamped) with a common trigger.
	* ~~Maybe~~ GNSS recording ~~too~~.		* GNSS recording.
	* Manual remote control.		* Manual remote control.

Basler Pylon

Jca — Mon, 13 Jul 2026 09:23:54 GMT

Install of Basler Pylon library

← Older revision		Revision as of 11:23, 13 July 2026
(One intermediate revision by the same user not shown)
Line 3:		Line 3:
	== Install of Basler Pylon library ==		== Install of Basler Pylon library ==

	~~@todo~~		Download the debian packages from
			https://www.baslerweb.com/en/downloads/software/?downloadCategory.values.label.data=pylon

			Unpack the packages
			tar -xf pylon*tar.gz

			Install
			sudo apt-get install ./pylon_.deb ./codemeter.deb

			This installs the package into /opt/pylon, and the code in
			/opt/pylon/bin

			The examples are in /opt/pylon/share/pylon/Samples

			=== add pylon to path ===

			You may add /opt/pylon/bin to the path
			nano ./bashrc

			add
			export PATH=$PATH:/opt/pylon/bin

			In a terminal run the viewer
			pylonviewer

			This may fain if your display manager is wayland - don't know how to solve

Basler Pylon

Jca — Mon, 13 Jul 2026 07:50:13 GMT

Created page with "Back to ricbot == Install of Basler Pylon library == @todo"

New page

Back to [[ricbot]]

== Install of Basler Pylon library ==

@todo

Ricbot

Jca — Mon, 13 Jul 2026 07:49:16 GMT

Installation notes

← Older revision		Revision as of 09:49, 13 July 2026
Line 26:		Line 26:
	* [[Ricbot PTP \| PTP]] time synchronization.		* [[Ricbot PTP \| PTP]] time synchronization.
	* Raspberry as [[RICbot Hotspot \| hotspot]].		* Raspberry as [[RICbot Hotspot \| hotspot]].
			* [[Basler Pylon]] installation

Network setup

Jca — Mon, 13 Jul 2026 07:24:43 GMT

Alternative

← Older revision		Revision as of 09:24, 13 July 2026
(2 intermediate revisions by the same user not shown)
Line 73:		Line 73:
	ping 192.168.7.7		ping 192.168.7.7

	==== ~~Alternative~~ ====		==== DHCP with static IP fallback ====

	I found this method (Google AI) to use DHCP with higher priority, and then static IP if DHCP fails		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 "Wired-DHCP" ifname eth0 ipv4.method auto autoconnect yes connect.autoconnect-priority 1
Line 116:		Line 116:

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

Line 143:		Line 143:
	==== Install DNS server on Raspberry ====		==== Install DNS server on Raspberry ====

	~~This section may~~ be deprecated, use the alternative method above with fallback to static IP.		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		Allow the connected PC to get an IP automatically; install DNSMASQ
Line 149:		Line 149:
	sudo apt install dnsmasq		sudo apt install dnsmasq

	Configure ~~the~~ use by editing /etc/dnsmasq.conf		Configure its use by editing /etc/dnsmasq.conf

	sudo nano /etc/dnsmasq.conf		sudo nano /etc/dnsmasq.conf

	Uncomment and change two lines. It is to be used on ETH0 only and in the IP range 192.168.7.50 to 192.168.7.99.		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		# DNS requests only on
Line 160:		Line 160:
	# range of addresses available for lease and optionally		# range of addresses available for lease and optionally
	# a lease time		# a lease time
	dhcp-range=192.168.7.50,192.168.7.~~99,255.255.255.0~~,12h		dhcp-range=192.168.7.60,192.168.7.70,12h

	Restart ~~the~~ dnsmasq		Restart dnsmasq

	sudo service dnsmasq restart		sudo service dnsmasq restart

	To see the status of the dnsmasq service use:		To see the status of the dnsmasq service, use:

	journalctl -b0 -u dnsmasq.service		journalctl -b0 -u dnsmasq.service

	After this, when you plug in a cable to a PC~~, then, after some seconds~~, both the robot and the PC should have an IP in the ~~range~~ 192.168.7.x. And the robot should display the new IP 192.168.7.7.		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		You can now access the robot using

Robobot MQTT topics

Jca — Fri, 10 Jul 2026 09:41:44 GMT

Send command

← Older revision		Revision as of 11:41, 10 July 2026
(One intermediate revision by the same user not shown)
Line 186:		Line 186:
	=== Send command ===		=== Send command ===

	To get gyro data faster, as an example:		To get gyro data faster, as an example (update every 1 ms):
	mosquitto_pub -h 10.197.218.72 -t dtubot/cmd/T0~~/sub~~ -m "gyro 1"		mosquitto_pub -h 10.197.218.72 -t dtubot/cmd/T0 -m "sub gyro 1"
	Or stopping gyro streaming		Or stopping gyro streaming
	mosquitto_pub -h 10.197.218.72 -t dtubot/cmd/T0~~/sub~~ -m "gyro 0"		mosquitto_pub -h 10.197.218.72 -t dtubot/cmd/T0 -m "sub gyro 0"

			Note there is a bandwidth limit at about 4000 messages per second, so the above will use about 25% of the available bandwidth.

Robobot teensy interface

Jca — Fri, 10 Jul 2026 09:36:27 GMT

← Older revision		Revision as of 11:36, 10 July 2026
Line 25:		Line 25:
	In MQTT, this will be split into a topic and a message.		In MQTT, this will be split into a topic and a message.

	topic: ''~~robobot~~/drive/T0/liv''		topic: ''dtubot/drive/T0/liv''
	message: ''1736776814.3819 731 928 962 866 888 902 828 613 50''		message: ''1736776814.3819 731 928 962 866 888 902 828 613 50''

	The first part of the topic, ''~~robobot~~/drive/T0'', is the same for all messages from the Teensy.		The first part of the topic, ''dtubot/drive/T0'', is the same for all messages from the Teensy.

	If you want to subscribe to all MQTT messages, the topic request could be ''~~robobot~~/drive/#.''		If you want to subscribe to all MQTT messages, the topic request could be ''dtubot/drive/#.''

	The message is preceded by a timestamp indicating when the message was received from Teensy. The timestamp is seconds from the start of the epoch (1 Jan 1970), which is standard for all PCs		The message is preceded by a timestamp indicating when the message was received from Teensy. The timestamp is seconds from the start of the epoch (1 Jan 1970), which is standard for all PCs
Line 135:		Line 135:
	context = drive		context = drive
	clientid = tif_data		clientid = tif_data
	system = ~~robobot~~/		system = dtubot/
	function = drive/		function = drive/
	print = false		print = false
Line 143:		Line 143:
	[mqttin]		[mqttin]
	broker = tcp://localhost:1883		broker = tcp://localhost:1883
			; context not used
	context = drive		context = drive
			; the client id must be unique on the host ''tif'' is for teensy interface.
	clientid = tif_cmd		clientid = tif_cmd
			; ''system'' and ''function'' are important here; these determine which topics the interface listens to:
			; Topic mask will here be: ''dtubot/cmd/#''.
	function = cmd/		function = cmd/
	system = ~~robobot~~/		system = dtubot/
	log = true		log = true
	print = false		print = false

Robobot MQTT-client

Jca — Fri, 10 Jul 2026 09:17:37 GMT

← Older revision		Revision as of 11:17, 10 July 2026
(2 intermediate revisions by the same user not shown)
Line 97:		Line 97:

	The commands to the robot, the MQTT messages, are a service function call:		The commands to the robot, the MQTT messages, are a service function call:
	service.send("~~robobot~~/cmd/ti","rc 0.25 0") # go straight		service.send("dtubot/cmd/ti","rc 0.25 0") # go straight
	The first parameter (''"~~robobot~~/cmd/ti"'') is the MQTT topic and indicates that it is a command for the ti (teensy_interface).		The first parameter (''"dtubot/cmd/ti"'') is the MQTT topic and indicates that it is a command for the ti (teensy_interface).

	The second parameter (''"rc 0.25 0"'') is the command, here rc (remote control), forward velocity in meters per second and the turn rate in radians per second (positive is CCW (counter-clockwise).		The second parameter (''"rc 0.25 0"'') is the command, here rc (remote control), forward velocity in meters per second and the turn rate in radians per second (positive is CCW (counter-clockwise).
Line 121:		Line 121:

	The streamed data is		The streamed data is
	* Wheel velocity (message topic ''~~robobot~~/drive/T0/vel'') in m/s.		* Wheel velocity (message topic ''dtubot/drive/T0/vel'') in m/s.
	* Motor velocity (message topic ''~~robobot~~/drive/T0/mvel'') before the gear. The unit is radians/sec. This stream is probably not needed.		* Motor velocity (message topic ''dtubot/drive/T0/mvel'') before the gear. The unit is radians/sec. This stream is probably not needed.
	* The robot pose (message topic ''~~robobot~~/drive/T0/pose'') is the x,y position and the robot heading as calculated in the Teensy.		* The robot pose (message topic ''dtubot/drive/T0/pose'') is the x,y position and the robot heading as calculated in the Teensy.

	=== Distance ===		=== Distance ===
Line 206:		Line 206:
	The ''Behave'' block sends a 'remote-control' MQTT message, like:		The ''Behave'' block sends a 'remote-control' MQTT message, like:

	topic: "~~robobot~~/cmd/ti", payload: "rc 0.1 0.5"		topic: "dtubot/cmd/ti", payload: "rc 0.1 0.5"

	where the topic ''~~robobot~~/cmd/ti'' indicates that it is for the ''teensy_interface''. The parameters are a forward velocity of 0.1 m/s and a turn rate of 0.5 rad/s (positive os CCW).		where the topic ''dtubot/cmd/ti'' indicates that it is for the ''teensy_interface''. The parameters are a forward velocity of 0.1 m/s and a turn rate of 0.5 rad/s (positive is CCW).

	The related Python command is		The related Python command is

	service.send("~~robobot~~/cmd/ti", "rc 0.1 0.5")		service.send("dtubot/cmd/ti", "rc 0.1 0.5")

	=== MQTT ===		=== MQTT ===
Line 220:		Line 220:
	All communication is through a network server on the robot's Raspberry PI. The port is 1883.		All communication is through a network server on the robot's Raspberry PI. The port is 1883.
	The result is that the Python MQTT client can run both on the Raspberry Py and on any other PC on the network with access to the robot.		The result is that the Python MQTT client can run both on the Raspberry Py and on any other PC on the network with access to the robot.

			=== Mosquito communication test ===

			Mosquito comes with a command-line interface.

			To test which messages are available on an MQTT server, this can be monitored with the command:

			mosquitto_sub -h 10.59.9.230 -t dtubot/# -v

			This assumes the server host is at 10.59.9.230 and that the topic to listen to is 'dtubot/#', where '#' indicates all topics within the 'dtubot' system. The last '-v' ensures that the topic is displayed along with the message.

			To publish MQTT commands could be like:

			mosquitto_pub -h 10.59.9.230 -t dtubot/cmd/T0 -m "sub flt 0"

			This is a command to the Teensy interface, and the message can be any message the Teensy understands.

	=== Teensy_interface ===		=== Teensy_interface ===

	The ''teensy_interface'' subscribes to all topics starting with ''~~robobot~~/cmd/ti''.		The ''teensy_interface'' subscribes to all topics starting with ''dtubot/cmd/ti''.
	The remote control message values are mixed to a desired ~~velocity~~ for the left and right wheels. The closed loop velocity control block generates a motor voltage sent to the Teensy 4.1 board.		The remote control message values are mixed to produce the desired velocities for the left and right wheels. The closed-loop velocity control block generates a motor voltage sent to the Teensy 4.1 board.

	The robot.ini configuration file allows you to select many sensor messages available from the Teensy 4.1 board. These messages can be logged for debugging or data analysis.		The robot.ini configuration file allows you to select many sensor messages available from the Teensy 4.1 board. These messages can be logged for debugging or data analysis.
	All messages are further published to the MQTT server.		All messages are further published to the MQTT server.

	Other data can be subscribed directly from the Teensy and ~~are~~ then published ~~directly~~ as MQTT topics.		Other data can be subscribed to directly from the Teensy and is then published as MQTT topics.

	=== Sensor data ===		=== Sensor data ===

	Sensor data in the MQTT client can be used to generate behaviour. Data ~~like~~ driven distance, heading change, line validity, distance sensor, and IMU data can be included.		Sensor data in the MQTT client can be used to generate behaviour. Data such as driven distance, heading change, line validity, distance sensor data, and IMU data can be included.

	== Line drive ==		== Line drive ==
Line 248:		Line 264:
	The line sensor data from MQTT looks like this.		The line sensor data from MQTT looks like this.

	'~~robobot~~/drive/T0/livn' 1738420382.4767 637 612 649 810 984 872 706 639 136		'dtubot/drive/T0/livn' 1738420382.4767 637 612 649 810 984 872 706 639 136
	'~~robobot~~/drive/T0/livn' 1738420382.4837 638 612 650 812 985 876 710 641 140		'dtubot/drive/T0/livn' 1738420382.4837 638 612 650 812 985 876 710 641 140
	'~~robobot~~/drive/T0/livn' 1738420382.4908 639 613 651 813 985 878 713 642 143		'dtubot/drive/T0/livn' 1738420382.4908 639 613 651 813 985 878 713 642 143

	The topic part ''livn'' is 'line sensor value, ~~normalized~~'. The first value is a timestamp and is ignored.		The topic part ''livn'' is 'line sensor value, normalised'. The first value is a timestamp and is ignored.

	The values are ~~normalized~~ to 1000, where 1000 is the calibrated reflectance for a white tape line. In this case, sensor 5 shows a value of about 980; this sensor sees a tape line. The far-right sensor (8) has a value of about 140; this is not a tape line (0 is black).		The values are normalised to 1000, where 1000 is the calibrated reflectance for a white tape line. In this case, sensor 5 shows a value of about 980; this sensor sees a tape line. The far-right sensor (8) has a value of about 140; this is not a tape line (0 is black).

	=== Line detect ===		=== Line detect ===
Line 281:		Line 297:
	The servo can be controlled by a message directly to the Teensy		The servo can be controlled by a message directly to the Teensy

	topic: "~~robobot~~/~~drive~~/T0", payload: "servo 1 400 200"		topic: "dtubot/cmd/T0", payload: "servo 1 400 200"

	where the topic ''~~robobot~~/~~drive~~/T0'' ~~is a topic where~~ the payload ~~is transferred~~ directly to the Teensy as a ''servo 1 400 200'' command.		where the topic ''dtubot/cmd/T0'' transfers the payload directly to the Teensy as a ''servo 1 400 200'' command.

	The command parameters are ''1'' for servo number one and ''400'' for the position (range is ca. -800 to 800 (us). The third parameter, ''200'', is velocity, the number of values per second. If the starting position is zero and the destination is 400, it takes about 2 seconds to reach position 400.		The command parameters are ''1'' for servo number one and ''400'' for the position (range is ca. -800 to 800 (us). The third parameter, ''200'', is velocity, the number of values per second. If the starting position is zero and the destination is 400, it takes about 2 seconds to reach position 400.

Robobot install on Raspberry

Jca — Fri, 10 Jul 2026 08:15:35 GMT

Additional packages

← Older revision		Revision as of 10:15, 10 July 2026
Line 95:		Line 95:
	libcpp-httplib-dev (for video streamer only)		libcpp-httplib-dev (for video streamer only)
	libpcl-dev (may not be needed - 3D pointcloud lib)		libpcl-dev (may not be needed - 3D pointcloud lib)
	sudo apt install libreadline-dev libopencv-dev libgpiod-dev gpiod cmake subversion aptitude telnet nmap lsof python3-paho-mqtt libpaho-mqtt-dev python3-opencv python3-setproctitle mosquitto mosquitto-dev mosquitto-clients libusb-dev libcli11-dev net-tools libssl-dev libcpp-httplib-dev libpcl-dev		gpsd gpsd-clients libgps-dev (for GPS NMEA support - part of Teensy_interface)
			---
			sudo apt install libreadline-dev libopencv-dev libgpiod-dev gpiod cmake subversion aptitude telnet nmap lsof python3-paho-mqtt libpaho-mqtt-dev python3-opencv python3-setproctitle mosquitto mosquitto-dev mosquitto-clients libusb-dev libcli11-dev net-tools libssl-dev libcpp-httplib-dev libpcl-dev gpsd gpsd-clients libgps-dev