Sensing · Chapter 15 · Time: 2 hours · Level: Intermediate · Status: Partly test-built
The Aurora 930 on the arm publishing colour, infrared, depth and a point cloud under /aurora from boot, run by the vendor driver kept apart in ~/vendor_ws, with the GitLab token removed from its copied repo and a watchdog that restarts it when it goes quiet.
The robot's eyes are a Deptrum Aurora 930 depth camera mounted on the arm. It gives a colour image, an infrared
image and a depth image (distance per pixel) about 14 times a second. The robot uses it to find Matt (chapter 21),
to see obstacles below the LiDAR's scan plane (nvblox, chapter 18) and to measure its own motion (cuVSLAM, chapter
16). It is the only part of this robot that runs vendor code: the camera has no standard USB video interface, and
the only driver that exists is Deptrum's. The owner approved that one exception on 2026-09-28, on the condition that
the driver lives in its own workspace and can be removed in one step.
New idea: a depth camera
A normal camera tells you what colour each pixel is. A depth camera also tells you how far away the thing in
each pixel is. The Aurora 930 lights the scene with its own infrared dot pattern, looks at it with an infrared
sensor, and computes a distance for each pixel inside the camera. You get three pictures: RGB (colour, for
people and objects), IR (what the infrared sensor sees, dots included) and depth (a 16-bit image where
each pixel value is a distance in millimetres; 0 means "no reading"). The driver also turns depth into a 3D
point cloud: one (x, y, z) point per valid pixel.
New idea: camera_info and intrinsics
A picture alone does not say which direction each pixel looks in. Every image topic has a partner topic,
camera_info, that carries the camera's intrinsics: the focal lengthsfx,fyand the image centrecx,
cy, in pixels. With them a program can turn "pixel (u, v) is 1.2 m away" into a 3D point. They sit in thek
field of the message as a 3x3 matrix written as 9 numbers:fx 0 cx 0 fy cy 0 0 1.
New idea: eye-in-hand
The camera is bolted to the arm, not to the body. Where it points depends on the arm's joints at that moment.
ROS works this out from the joint angles (/joint_statesfrom the driver, turned byrobot_state_publisher
into the chainlink4→camera_link0→camera_link→depth_camera_link, chapter 12). The vendor driver adds
depth_camera_link→rgb_camera_linkfrom extrinsics stored in the camera. The catch: while the arm moves,
the joint angles and the images are not in step, so for a moment the robot believes the camera points somewhere
it does not. Every program that places camera data in the room has to ignore frames taken while the arm moves.
You will see that rule invslam_odom(chapter 16) anddepth_gate(chapter 18).
The camera's identifiers, from docs/hardware.md (2026-09-28):
| Item | Value |
|---|---|
| USB id | 3251:1930 ("Linux Foundation Aurora 930") |
| USB position | 1-2.2.1, behind the USB 2 hub, 480 Mb/s |
| USB class | one interface, class 0xff (vendor specific): no UVC, so no /dev/video* |
| Serial, firmware | HY400586001016515G00505, firmware 2.0.8 |
| Picture sizes | 320x200, 480x300, 640x400 (IR 8-bit, RGB, depth 16-bit) |
| Driver | deptrum-ros-driver-aurora930 0.2.11 (source) + closed libdeptrum_stream_aurora900.so 1.1.22 (aarch64, built for Ubuntu 18.04) |
Look at it first:
On the robot:
lsusb | grep 3251
ls -l /dev/video*
Check
The camera is on the bus and has no video device:On the robot:
Bus 001 Device 006: ID 3251:1930 Linux Foundation Aurora 930and
lsfails (exit code 2 in the record): there is no/dev/video*. The device number can differ after a
re-plug.
That missing/dev/video0is whyffmpeg,v4l2-ctland every UVC tool cannot use this camera.
Why this step
The rebuild rule since 2026-09-26 is "no Hiwonder software or vendor code on the Jetson". The Aurora 930 breaks
it: it is USB class 0xff with no UVC, and the only driver is Deptrum's closedlibdeptrum_stream_aurora900.so
1.1.22. The owner approved an exception on 2026-09-28 (docs/decisions.md) with these conditions: the driver
lives only in~/vendor_ws(not~/ros2_ws, nothing in/usror/opt), the system gets one udev rule for
this one USB id, there is a rollback script, and it runs in its own service so it cannot take the base driver
down. The recorded fallback if the vendor driver ever becomes a problem is an Intel RealSense D435if (open SDK,
packaged in apt). It has not been bought.
The driver did not come from the internet. Hiwonder's factory install, which still sits untouched on the first
partition of the NVMe (APP_old, chapter 5), has the Deptrum driver source and the closed library in
/home/ubuntu/third_party/aurora_ws. The install script copies it from there, so the partition has to be mounted
first. Mounting it is the one step the script does not do.
On the robot:
lsblk -o NAME,PARTLABEL,SIZE /dev/nvme0n1 | head -3
sudo mkdir -p /mnt/factory
sudo mount -o ro /dev/nvme0n1p1 /mnt/factory && echo "mounted ro"
ls /mnt/factory/home/ubuntu/third_party/aurora_ws/src/
cat /mnt/factory/etc/udev/rules.d/99-deptrum-libusb.rules
Check
lsblkshows the factory partition as the first one:On the robot:
NAME PARTLABEL SIZE nvme0n1 476.9G ├─nvme0n1p1 APP_old 117.8GThe mount prints
mounted ro, thelsshowsdeptrum-ros-driver-aurora930-0.2.11, and the factory's own udev
rule for the camera reads:On the robot:
SUBSYSTEM=="usb", ATTRS{idVendor}=="3251", MODE:="0666", TAG+="uaccess", TAG+="udev-acl"That rule gives every user on the machine read and write access to every Deptrum device. You will not copy it;
the install script writes a narrower one.
Safety
MountAPP_oldread-only (-o ro) every time. It is the only copy of the factory install on the robot, and
/etc/nv_boot_control.confcame from it (chapter 5). Nothing in this guide writes to it.
If it fails
/mnt/factoryis empty. The partition is not mounted. It is not in/etc/fstab, so a reboot or an
umountremoves it. On 2026-09-28 a search of/mnt/factoryfound nothing until it was mounted again. Mount
it before running the install script; the script stops withfactory partition not mounted at /mnt/factory
if you forget.- There is no
APP_old. If you flashed a blank NVMe (chapter 5, path b), the factory partition does not
exist and neither does this copy of the driver. See the box below.
Not test-built: a robot without the factory partition
Everything in this chapter was done on a robot that still hadAPP_old. On a blank drive there is no factory
copy to mount. Two copies of the installed driver exist elsewhere:~/vendor_wson the running robot, and the
rootfs archive of every golden set made after 2026-09-28 (chapter 8;make_golden.sharchives the whole root
filesystem,/home/burgerbarnincluded). The golden set does not containAPP_olditself (it saves
partitions 2 to 15 and the root filesystem). Restoring~/vendor_wsfrom a golden archive instead of copying it
from/mnt/factoryhas never been done. Keep your own copy of
/mnt/factory/home/ubuntu/third_party/aurora_ws/src/deptrum-ros-driver-aurora930-0.2.11off the robot before you
ever wipe the NVMe, and remove the git remote from that copy (see below).
scripts/install_aurora930.sh is 20 lines. Read it before you run it:
On the robot:
#!/bin/bash
# OWNER-APPROVED EXCEPTION (2026-09-28): Deptrum Aurora 930 driver = vendor ROS wrapper 0.2.11 (source) +
# closed prebuilt libdeptrum_stream_aurora900.so 1.1.22 (aarch64, built for 18.04). Copied from the factory
# partition (mounted ro at /mnt/factory). Isolated: ~/vendor_ws only (NOT ~/ros2_ws, nothing in /usr, /opt).
# System change: one udev rule for 3251:1930 only, group video, 0660 (vendor rule was 0666 for all 3251:*).
# Rollback: bash ~/setup/rollback_aurora930.sh
set -euo pipefail
SRC=/mnt/factory/home/ubuntu/third_party/aurora_ws/src/deptrum-ros-driver-aurora930-0.2.11
WS=/home/burgerbarn/vendor_ws
[ -d "$SRC" ] || { echo "factory partition not mounted at /mnt/factory"; exit 1; }
[ -e "$WS" ] && { echo "$WS exists; rollback first"; exit 1; }
mkdir -p "$WS/src"
cp -a "$SRC" "$WS/src/"
sha256sum "$WS/src/deptrum-ros-driver-aurora930-0.2.11/ext/"*/lib/libdeptrum_stream_aurora900.so
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="3251", ATTRS{idProduct}=="1930", MODE="0660", GROUP="video"' \
| sudo tee /etc/udev/rules.d/60-rosorin-aurora930.rules >/dev/null
sudo udevadm control --reload && sudo udevadm trigger --subsystem-match=usb --attr-match=idVendor=3251
set +u; source /opt/ros/humble/setup.bash; set -u
cd "$WS" && colcon build --cmake-args -DSTREAM_SDK_TYPE=AURORA930 -DCMAKE_BUILD_TYPE=Release 2>&1 | tail -5
echo AURORA930_INSTALLED
What each part does:
~/vendor_ws.cp -a copies the vendor folder as it is, including its .git directory (that matters in the next section).sha256sum line prints the hash of the closed library so you can compare it with the record.video group open this one device (3251:1930) and nobody else. The userburgerbarn was created in video by prep_rootfs.sh (chapter 4). udevadm trigger applies the rule to theset +u around source /opt/ros/humble/setup.bash: ROS's setup script reads variables that may be unset, whichset -u turns into a fatal error.-DSTREAM_SDK_TYPE=AURORA930 picks the camera family. The same vendor package also has code for the Deptrumlaunch_nebula, launch_stellar400, launch_stellar420). Release builds withCopy the script and its rollback to the robot, then run it as burgerbarn (not with sudo; it calls sudo
itself for the udev rule):
On your laptop:
cd ~/CCode/rosorin-pro
scp scripts/install_aurora930.sh scripts/rollback_aurora930.sh rosorin-wifi:setup/
On the robot:
bash ~/setup/install_aurora930.sh
Check
The run on 2026-09-28 printed the library hash, then the build result:On the robot:
20de34b76345affa1bcb9141e7e1735cf85f600a2c6f039f08fa7176a2551aac /home/burgerbarn/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11/ext/deptrum-stream-aurora900-linux-aarch64-v1.1.22-18.04/lib/libdeptrum_stream_aurora900.so [Processing: deptrum-ros-driver-aurora930] Finished <<< deptrum-ros-driver-aurora930 [42.0s] Summary: 1 package finished [42.7s]Then check that the device node now belongs to the
videogroup (1-2.2.1 is the camera's USB position):On the robot:
ls -l /dev/bus/usb/001/$(printf %03d $(cat /sys/bus/usb/devices/1-2.2.1/devnum)) ls ~/vendor_ws/install/deptrum-ros-driver-aurora930/share/deptrum-ros-driver-aurora930/launchOn the robot:
crw-rw---- 1 root video 189, 5 Sep 28 15:52 /dev/bus/usb/001/006and the launch folder lists
aurora930_launch.py,aurora930_multi_launch.py,sub_node_ci_aurora930_launch.py
andviewer930_launch.py.
If it fails
/opt/ros/humble/setup.bash: line 8: AMENT_TRACE_SETUP_FILES: unbound variable. The first version of the
script sourced ROS underset -uand stopped there, after the copy. Theset +u ... set -uline is the fix
and is in the repo copy. Because the copy had already happened, the rerun needed the rollback first./home/burgerbarn/vendor_ws exists; rollback first. Runbash ~/setup/rollback_aurora930.sh. It stops
any running driver, deletes~/vendor_wsand the udev rule, and printsAURORA930_ROLLED_BACK.- The hash is different. You copied a different library than the one this robot runs. Roll back and find
out why before you use it.ls -lshows grouprootinstead ofvideo. The rule did not apply. Unplug and replug the camera, or
run theudevadm triggerline again.
When the build is done, unmount the factory partition:
On the robot:
sudo umount /mnt/factory && echo unmounted
The vendor folder is a git checkout (detached at commit c2bff34, 2025-05-19, with many files marked modified as
they were shipped). Its git remote URL contains a GitLab CI access token of the form
http://gitlab-ci-token:<removed>@heptagon/.... It arrived with the factory image, cp -a copied it into
~/vendor_ws, and from there it went into every golden set made since. On 2026-10-07 it was still on the robot.
Safety
Do not print the remote URL: nogit remote -v, nocat .git/config, before you remove it. Anything you print
can end up in a terminal log, a copied command or a backup. Remove the remote without looking at it:
On the robot:
git -C ~/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11 remote remove origin
Check
With the remote gone:On the robot:
git -C ~/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11 remote grep -c gitlab-ci-token ~/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11/.git/configThe first prints nothing (no remotes left). The second prints
0(the count of lines holding the token). The
build never uses the remote, so the camera keeps working.
Not test-built
This removal has not been run on this robot yet. The commands are standard git; the expected output above is
what git prints for a repository with no remote, not a recorded run.git remote set-url origin <something harmless>works too if you want to keep a remote namedorigin. Three places keep the token after you do this:
the factory partition (read-only, leave it), golden sets made before the removal (chapter 8), and any copy of
the vendor folder you made before. Every reinstall withinstall_aurora930.shbrings it back, becausecp -a
copies.git; run the removal again after each one.
Before giving it to systemd, start it in the foreground so you see what it says. Use an interactive ssh session,
not a background job: a job started with & from a non-interactive shell ignores Ctrl-C (docs/lessons.md), and a
forgotten driver holds the camera so the service cannot open it later.
On the robot:
source /opt/ros/humble/setup.bash
source ~/vendor_ws/install/setup.bash
ros2 launch deptrum-ros-driver-aurora930 aurora930_launch.py
Check
The first lines on 2026-09-28:On the robot:
[INFO] [aurora930_node-1]: process started with pid [7282] [aurora930_node-1] W0928 15:53:16.403342 7282 ros2_node.cc:35] hello aurora 900/930 [aurora930_node-1] 2026-09-28 15:53:16.414 ( 0.068s) [ 8B275020] device_manager_impl.cc:89 INFO| hotplug has registed by user [aurora930_node-1] device_count==========1 [aurora930_node-1] I0928 15:53:16.422406 7282 aurora900_ros2_device.cc:153] BOOT_ORDER_1
device_count==========1means it found the camera.
In a second ssh session, list the topics and measure them:
On the robot:
source /opt/ros/humble/setup.bash
ros2 topic list | grep aurora
for t in /aurora/rgb/image_raw /aurora/depth/image_raw /aurora/points2; do printf "%s " $t; timeout 7 ros2 topic hz $t 2>&1 | grep -m1 "average rate" || echo none; done
top -bn1 | grep -E "aurora|%Cpu" | head -3
Check
Six topics:On the robot:
/aurora/depth/image_raw /aurora/ir/camera_info /aurora/ir/image_raw /aurora/points2 /aurora/rgb/camera_info /aurora/rgb/image_rawRates measured on 2026-09-28 with this launch:
On the robot:
/aurora/rgb/image_raw average rate: 9.285 /aurora/depth/image_raw average rate: 14.004 /aurora/points2 average rate: 12.926and the node at 35 % of one core (
35.3intop). One captured frame of the living room:depth 640 400 mono16 depth_camera_link,rgb 640 400 bgr8 rgb_camera_link, depth valid in 34 % of pixels, 1270 to 3784 mm. Holes
are normal on black, shiny or dark things (TV, dark shelves).
If it fails
device_count==========0, or no/auroratopics. Another driver already holds the camera (check with
pgrep -af aurora930_node), the udev rule did not apply (see above), or the USB cable is loose.- The RGB rate differs from the record. It does. 9.3 Hz was this first hand launch; under the service the
RGB topic measured 14.7 Hz (2026-09-29) and 13.8 Hz (2026-10-07).docs/hardware.mdlists 9.3 Hz; the later
live numbers are what the robot does now.
Stop the driver with Ctrl-C in the first session.
The service runs the vendor's aurora930_launch.py unchanged. The settings live in that vendor file, not in this
repo. Read from the robot on 2026-10-07
(~/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11/launch_aurora930/launch/aurora930_launch.py):
| Setting | Value | Meaning |
|---|---|---|
namespace |
aurora |
all topics under /aurora |
rgb_enable, ir_enable, depth_enable, point_cloud_enable |
True | all four streams on |
rgb_fps, ir_fps |
15 | requested frame rate |
resolution_mode_index |
2 | the third mode in the camera's list = 640x400, the largest it offers |
align_mode |
True | depth registered to the RGB image (next section) |
minimum_filter_depth_value, maximum_filter_depth_value |
150, 4000 | depth limits in mm (0.15-4.0 m); the living-room frame stayed within 1.27-3.78 m |
depth_correction |
True | vendor setting, on |
laser_power |
1.0 | projector mode; the vendor header says "1-auto 2-indoor" |
heart_enable |
False | vendor setting, off |
On 2026-10-05 nothing subscribed to /aurora/ir/image_raw or /aurora/points2; three nodes read
/aurora/depth/image_raw.
With align_mode on, the driver redraws the depth image so that depth pixel (u, v) and colour pixel (u, v) look at
the same spot. That is what lets cuVSLAM use colour plus depth, and nvblox read depth with the colour camera's
intrinsics. The record checked it two ways on 2026-10-02: depth edges drawn over the RGB image lined up with it,
and the driver's own point cloud fits the RGB intrinsics exactly.
On the robot:
source /opt/ros/humble/setup.bash
timeout 12 ros2 topic echo --once /aurora/rgb/camera_info 2>/dev/null | grep -E "^height|^width"
timeout 12 ros2 topic echo --once /aurora/rgb/camera_info 2>/dev/null | sed -n "/^k:/,/^r:/p" | head -10 | tr -d " -" | tr "\n" " "; echo
Check
From 2026-09-29:On the robot:
height: 400 width: 640 k: 419.8874816894531 0.0 317.5320739746094 0.0 421.0333251953125 192.90916442871094 0.0 0.0 1.0So fx 419.9, cx 317.5, fy 421.0, cy 192.9. The IR camera's own intrinsics are different (fx 421.9, cx 318.2,
fy 422.7, cy 200.2). Fitting the driver's point cloud back onto the depth image gave
fitted fx 419.9 cx 317.5 fy 421.0 cy 192.9withmedian |dz| 0.0000 m: the depth image follows the RGB
camera.
Two details matter later:
frame_id: depth_camera_link, although its pixels follow the RGB camera. Code/aurora/rgb/camera_info (vslam_odom.py, and the nvblox remap innav.launch.py)....485000000 against ...413000000). That is why vslam_odom pairs them with a 0.09 s window.The camera gets its own service, separate from rosorin-base, so a crash in the closed library can never stop the
wheels' driver. The unit file is systemd/rosorin-camera.service in the repo; it is copied to the robot below:
On the robot:
[Unit]
Description=ROSOrin depth camera (Deptrum Aurora 930 vendor driver, owner-approved exception; /aurora/*)
After=network-online.target rosorin-base.service
Wants=network-online.target
[Service]
User=burgerbarn
Environment=ROS_DOMAIN_ID=0
ExecStart=/bin/bash -c 'source /opt/ros/humble/setup.bash && source /home/burgerbarn/ros2_ws/install/setup.bash && source /home/burgerbarn/vendor_ws/install/setup.bash && exec ros2 launch deptrum-ros-driver-aurora930 aurora930_launch.py'
KillSignal=SIGINT
KillMode=mixed
TimeoutStopSec=10
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
After=rosorin-base.service: start after the base, but no Requires=: the camera does not need the base, andvendor_ws is sourced last, on top of ros2_ws, so it is the only place the vendor package comes from.KillSignal=SIGINT with KillMode=mixed: systemd sends Ctrl-C to ros2 launch only, and launch passes it torosorin-base, chapter 11).Restart=always, 5 s: if the driver dies it comes back by itself.scripts/install_camera_service.sh installs and starts it:
On the robot:
#!/bin/bash
# Install + enable rosorin-camera.service (Aurora 930 driver at boot, separate from rosorin-base so the vendor
# driver can't take the base down). Rollback: sudo bash ~/setup/rollback_camera_service.sh
set -euo pipefail
[ "$(id -u)" = 0 ] || { echo "run with sudo"; exit 1; }
pkill -INT -f "aurora930_launch.py" 2>/dev/null && sleep 3 || true # a hand-started driver would hold the camera
install -m 0644 /home/burgerbarn/setup/rosorin-camera.service /etc/systemd/system/rosorin-camera.service
systemctl daemon-reload
systemctl enable --now rosorin-camera.service
sleep 12; systemctl --no-pager --lines=5 status rosorin-camera.service | head -8
Copy the unit and the two scripts, then run it with sudo:
On your laptop:
cd ~/CCode/rosorin-pro
scp systemd/rosorin-camera.service scripts/install_camera_service.sh scripts/rollback_camera_service.sh rosorin-wifi:setup/
On the robot:
sudo bash ~/setup/install_camera_service.sh
Then check from a normal shell:
On the robot:
source /opt/ros/humble/setup.bash
systemctl show rosorin-camera -p ActiveState -p SubState -p NRestarts
timeout 8 ros2 topic hz /aurora/rgb/image_raw 2>&1 | grep -m1 "average rate"
timeout 8 ros2 topic hz /aurora/depth/image_raw 2>&1 | grep -m1 "average rate"
Check
ActiveState=active,SubState=running, andNRestartsnot climbing when you run the command again a minute
later. On 2026-09-29 the service gave:On the robot:
average rate: 14.691 average rate: 13.185(RGB, then depth).
systemctl status rosorin-camerashows two processes in its CGroup:ros2 launchand
aurora930_node.
If it fails
Active: activating (auto-restart)andNRestartsgoing up (4, then 6 on 2026-09-29). A driver you
started by hand still holds the camera, so every service start finds it busy and exits. The script's
pkill -INTdoes not stop a driver that was started in the background from a non-interactive shell, because
such a process ignores SIGINT. Find it withpgrep -af aurora930, stop it withkill -TERM <pid>(the
record had to stop PIDs 3334 and 3336 by hand), and the service takes over within its 5 s restart.run with sudo.install_camera_service.shneeds root (sudo bash ...). The driver install script
earlier,install_aurora930.sh, is the opposite: run it asburgerbarn, without sudo.- Rollback:
sudo bash ~/setup/rollback_camera_service.shdisables and removes the unit.
A driver can stall with its process alive and its topics silent. That was already a lesson from the factory stack
("never trust 'node running'", docs/lessons.md), and it happened here on 2026-10-07: after a boot the service was
active (running) for 23 minutes and no frame arrived. The mind could not look for Matt and said nothing. The
record of that morning:
On the robot:
timeout 6 ros2 topic hz /aurora/rgb/image_raw 2>&1 | grep -m1 "average rate" || echo "NO camera frames on /aurora/rgb/image_raw in 6 s"
systemctl status rosorin-camera --no-pager 2>&1 | head -4
On the robot:
NO camera frames on /aurora/rgb/image_raw in 6 s
● rosorin-camera.service - ROSOrin depth camera (Deptrum Aurora 930 vendor driver, owner-approved exception; /aurora/*)
Loaded: loaded (/etc/systemd/system/rosorin-camera.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2026-10-07 01:12:59 UTC; 23min ago
sudo systemctl restart rosorin-camera fixed it (average rate: 13.848 twelve seconds later). The cause of the
stall is not known.
Two things now watch for this, both built in later chapters:
The mind's camera watchdog (vision/mind.py, chapter 21). Every step of the mind checks whether the newest
RGB frame's timestamp has changed:
On the robot:
CAM_STALE_S, CAM_RETRY_S = 20.0, 120.0 # 2026-10-07: camera "running" but silent after a boot -> restart it itself
On the robot:
def camera_watch(self, now):
"""2026-10-07: after a boot the camera service ran but published no frame for 23 min; every step returned
silently, so it could not look for the owner and nobody knew. No new frame for CAM_STALE_S -> restart the
camera (its own heal, at most once per CAM_RETRY_S, logged); still blind after a second try -> tell the owner."""
m = self.n.last.get('rgb')
stamp = None if m is None else (m.header.stamp.sec, m.header.stamp.nanosec)
if not hasattr(self, 'cam_t') or stamp != self.cam_stamp:
if hasattr(self, 'cam_t') and getattr(self, 'cam_restarts', 0):
self.event('camera_back', after_restarts=self.cam_restarts)
self.cam_stamp, self.cam_t, self.cam_restarts = stamp, now, 0
return
if now - self.cam_t < CAM_STALE_S or now - getattr(self, 'cam_fix_t', 0.0) < CAM_RETRY_S:
return
self.cam_fix_t = now; self.cam_restarts += 1
self.event('camera_silent', secs=round(now - self.cam_t), restart=self.cam_restarts)
subprocess.run(['sudo', 'systemctl', 'restart', '--no-block', 'rosorin-camera'], capture_output=True)
if self.cam_restarts >= 2:
try:
sys.path.insert(0, os.path.expanduser('~/selfcare'))
from say import enqueue
enqueue('camera_blind', 'My camera is not sending pictures, even after restarting it. I cannot see.',
'urgent', repeat_s=1800)
except Exception as e:
self.event('say_failed', err=str(e)[:100])
No new frame for 20 s: restart the camera service, at most once every 2 minutes, and log camera_silent. Still
nothing after the second restart: queue an urgent sentence for Buddy to say out loud. When frames come back it
logs camera_back. The mind can run sudo systemctl because burgerbarn has passwordless sudo (chapter 6).
Self-care (selfcare/, chapter 23) measures /aurora/rgb/camera_info against an expected 15 Hz every
15 minutes and restarts rosorin-camera if it is silent, after a second measurement, at most once an hour. It
watches camera_info, not the image, because a best-effort reader of a 768 kB image loses frames through the
default 512 kB Fast DDS shared-memory segment, which made the camera look slow when it was not
(docs/status.md, 2026-10-05).
The three depth readers are vslam_odom, depth_gate and the mind (its vision/scan.py reads RGB, depth and
/aurora/rgb/camera_info together). /aurora/ir/* and /aurora/points2 are published but unused. The IR image is
useless for motion tracking (chapter 16 shows why). The point cloud was a costmap source on 2026-09-29 and was
removed on 2026-09-30 after it marked 38 % of the global costmap lethal; since 2026-10-02 the depth camera reaches
the costmaps through nvblox instead (chapter 18).
lsusb | grep 3251 shows the Aurora 930, and /etc/udev/rules.d/60-rosorin-aurora930.rules holds exactly the one3251:1930, mode 0660, group video.systemctl is-enabled rosorin-camera says enabled, and after a reboot ros2 topic hz /aurora/rgb/image_raw/aurora/rgb/camera_info has k starting 419.88....git -C ~/vendor_ws/src/deptrum-ros-driver-aurora930-0.2.11 remote prints nothing.findmnt /mnt/factory prints nothing (the factory partition is unmounted again).Where this comes from
scripts/install_aurora930.sh,scripts/rollback_aurora930.sh,scripts/install_camera_service.sh,
scripts/rollback_camera_service.sh,systemd/rosorin-camera.service,vision/mind.py(camera_watch,
added 2026-10-07),selfcare/expected.json;docs/decisions.md2026-09-28 (vendor exception) and 2026-10-02
(depth registered to RGB, intrinsics);docs/hardware.md"Depth camera: Deptrum Aurora 930" and the
2026-10-05 picture sizes;docs/lessons.md(silent driver stalls, SIGINT ignored by background jobs);
docs/status.md2026-10-05 (camera watched throughcamera_info). Command log: factory mount 2026-09-27 and
2026-09-28, install and first launch 2026-09-28 15:52-15:54 UTC, service install 2026-09-29 18:15 UTC,
intrinsics 2026-09-29 and 2026-10-02, silent camera 2026-10-07 01:36 UTC. Read from the robot on 2026-10-07
(read-only):lsblk, the vendor launch file's defaults, the vendor repo's commit and status. The GitLab token
is reported insurvey_live_robot.md; its value is not reproduced anywhere in this guide.