Ricbot sensorbox: Difference between revisions
| Line 136: | Line 136: | ||
Q11 and Q12 allow display of battery voltage (one or two batteries in series), without using energy, if the power is off. | 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 | | [[file: power-dist-RIC-use.png | 500px]] | ||
Cable connections when used in the sensor box. | Cable connections when used in the sensor box. | ||
Revision as of 19:48, 10 August 2026
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
- 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
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
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
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.
Cable connections when used in the sensor box.