Hey @Alex-Kushleyev
I finally found some time to test out the fix and got it working, but only after some additional modification: the voxl-camera-server seems to encode the frames as 240x180 when they are actually 180x240. This led to weird aliasing issues when inspecting the resulting RTSP streams.
The fix was just for me to swap the WxH resolutions. I am not 100% sure if this would be necessary to do in all cases but might be worth you looking into
Kind regards,
Griffin
@Alex-Kushleyev @tom any response or advice?
When this does occurs I see nothing unusual in the systemctl status messages:
● voxl-streamer-hires-down.service - voxl-streamer
Loaded: loaded (/usr/bin/voxl-streamer; enabled; vendor preset: enabled)
Active: active (running) since Thu 2025-02-27 23:48:55 UTC; 15min ago
Process: 1479 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS)
Main PID: 1955 (voxl-streamer)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/voxl-streamer-hires-down.service
└─1955 /usr/bin/voxl-streamer -s -p 8901 -i hires_down_small_encoded
Feb 27 23:48:55 m0054 voxl-streamer[1955]: w: 1024 h: 768 fps: 30 format: H264
Feb 27 23:48:55 m0054 voxl-streamer[1955]: Stream available at rtsp://127.0.0.1:8901/live
Feb 28 00:02:55 m0054 voxl-streamer[1955]: A new client rtsp://192.168.254.44:52848(null) has connected, total clients: 1
Feb 28 00:02:55 m0054 voxl-streamer[1955]: Camera server Connected
Feb 28 00:04:03 m0054 voxl-streamer[1955]: rtsp client disconnected, total clients: 0
Feb 28 00:04:03 m0054 voxl-streamer[1955]: no more rtsp clients, closing source pipe intentionally
Feb 28 00:04:04 m0054 voxl-streamer[1955]: A new client rtsp://192.168.254.44:38768(null) has connected, total clients: 1
Feb 28 00:04:04 m0054 voxl-streamer[1955]: Camera server Connected
Feb 28 00:04:10 m0054 voxl-streamer[1955]: rtsp client disconnected, total clients: 0
Feb 28 00:04:10 m0054 voxl-streamer[1955]: no more rtsp clients, closing source pipe intentionally
voxl-inspect-cpu returns:
Name Freq (MHz) Temp (C) Util (%)
-----------------------------------
cpu0 1075.2 85.3 19.45
cpu1 1075.2 84.1 10.51
cpu2 1075.2 84.1 12.28
cpu3 1075.2 84.9 10.03
cpu4 710.4 84.9 19.34
cpu5 710.4 86.1 20.54
cpu6 710.4 84.5 19.73
cpu7 844.8 84.9 4.80
Total 84.9 14.59
10s avg 15.06
-----------------------------------
small cores only 13.07
big cores only 16.11
-----------------------------------
GPU 587.0 80.7 7.43
GPU 10s avg 7.31
-----------------------------------
memory temp: 85.3 C
memory used: 4195/7671 MB
-----------------------------------
Flags
CPU freq scaling mode: auto
Standby Not Active
-----------------------------------
and top:
top - 00:07:09 up 10 min, 0 users, load average: 3.28, 2.91, 1.67
Tasks: 476 total, 2 running, 300 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.0 us, 14.0 sy, 0.0 ni, 67.3 id, 0.0 wa, 2.8 hi, 0.9 si, 0.0 st
KiB Mem : 7855496 total, 2772832 free, 4527956 used, 554708 buff/cache
KiB Swap: 3927744 total, 3927744 free, 0 used. 3552948 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1461 root -81 0 8650380 231620 66028 S 114.9 2.9 11:17.22 voxl-camera-ser
2134 root -51 0 1345204 107148 39084 S 77.2 1.4 7:28.22 voxl-open-vins-
1751 root 20 0 1011024 92336 11144 S 26.8 1.2 2:39.99 px4
1915 root 20 0 269308 6100 5524 S 4.3 0.1 0:25.73 voxl-mavlink-se
1503 root 20 0 852088 11892 6696 S 3.3 0.2 0:21.72 voxl-vision-hub
366 root 20 0 0 0 0 I 2.6 0.0 0:05.38 kworker/u16:11-
1953 root 20 0 617468 15208 9424 S 2.3 0.2 0:07.13 voxl-streamer
407 root 20 0 0 0 0 I 2.0 0.0 0:03.25 kworker/u16:14-
408 root 20 0 0 0 0 I 2.0 0.0 0:04.61 kworker/u16:15-
1592 root -2 0 0 0 0 S 1.7 0.0 0:10.26 qrtr_rx
262 root -3 0 0 0 0 S 1.3 0.0 0:06.29 kgsl_worker_thr
1673 root -81 0 195696 6204 5624 S 1.3 0.1 0:07.66 voxl-imu-server
1813 root 0 -20 0 0 0 I 1.3 0.0 0:04.09 kworker/u17:8-c
2179 root 20 0 0 0 0 I 1.0 0.0 0:04.12 kworker/u18:2-k
2211 root 20 0 0 0 0 I 1.0 0.0 0:03.58 kworker/u18:4-q
21475 root 0 -20 0 0 0 I 1.0 0.0 0:02.39 kworker/u17:0-c
30554 root 20 0 0 0 0 I 1.0 0.0 0:02.28 kworker/u18:6-k
48 root 20 0 0 0 0 S 0.7 0.0 0:02.29 rcuop/4
1183 logd 30 10 382204 3076 2504 S 0.7 0.0 0:03.33 logd
1279 root 20 0 97136 7620 6976 S 0.7 0.1 0:03.49 voxl-rangefinde
2146 root 20 0 0 0 0 I 0.7 0.0 0:02.28 kworker/u18:0-k
10 root 20 0 0 0 0 S 0.3 0.0 0:02.20 ksoftirqd/0
11 root 20 0 0 0 0 I 0.3 0.0 0:02.37 rcu_preempt
21 root 20 0 0 0 0 S 0.3 0.0 0:01.98 ksoftirqd/1
29 root 20 0 0 0 0 S 0.3 0.0 0:01.95 ksoftirqd/2
32 root 20 0 0 0 0 S 0.3 0.0 0:00.40 rcuop/2
37 root 20 0 0 0 0 S 0.3 0.0 0:02.04 ksoftirqd/3
56 root 20 0 0 0 0 S 0.3 0.0 0:01.03 rcuop/5
62 root 20 0 0 0 0 I 0.3 0.0 0:00.67 kworker/6:0-eve
64 root 20 0 0 0 0 S 0.3 0.0 0:01.59 rcuop/6
89 root 20 0 0 0 0 S 0.3 0.0 0:02.05 qmp_aop
301 root rt 0 0 0 0 S 0.3 0.0 0:01.34 spi3
1449 root 20 0 0 0 0 I 0.3 0.0 0:00.70 kworker/4:3-eve
1465 root 20 0 18868 1616 1472 S 0.3 0.0 0:02.68 voxl-cpu-monito
1472 root 20 0 6780 3660 3316 S 0.3 0.0 0:01.64 voxl-portal
The cpu load seems to be quite high, noticeably higher than before updating.
Hello All,
Is it possible to purchase replacement landing gear for the Starling 2 max? I believe I would also need new 5g antennas as these seem to be permanently glued to each leg.
Kind regards,
Griffin
Since updating from SDK 1.3.5 to 1.4.1 on a starling 2 max I am experiencing intermittent issues when connecting to the RTSP streams from the drone. Sometimes these connect quickly with no issues, other times they hang on waiting for progress to finish in the gstream pipeline. For example, running the command gst-launch-1.0 rtspsrc location=rtsp://192.168.254.138:8901/live latency=0 ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink may result in:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Pipeline is PREROLLED ...
Prerolled, waiting for progress to finish...
Progress: (connect) Connecting to rtsp://192.168.254.138:8901/live
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not open resource for reading and writing.
Additional debug info:
../gst/rtsp/gstrtspsrc.c(8130): gst_rtspsrc_retrieve_sdp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Failed to connect. (Generic error)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
after significant delay. These errors seem to correlate with how long the system has been on. Additionally, the VOXL 2 boards now get extremely hot and seem to be under significant load
@Eric-Katzfey yes it is on a starling 2 max SKU: MRB-D0012-4-V2-C29-T9-M24-X0
Hello all,
I am having some issues getting the TOF camera to stream it's data over RTSP.
I have a systemd process enabled to start up a voxl-streamer instance in /etc/systemd/system/voxl-streamer-tof-depth.service
#
# Copyright (c) 2021 ModalAI, Inc.
#
[Unit]
Description=voxl-streamer
SourcePath=/usr/bin/voxl-streamer
After=voxl-wait-for-fs.service
Requires=voxl-wait-for-fs.service
[Service]
Restart=no
User=root
Type=simple
PIDFile=/run/voxl-streamer.pid
ExecStartPre=/bin/sleep 5
ExecStart=/usr/bin/voxl-streamer -s -p 8902 -i tof_depth
[Install]
WantedBy=multi-user.target
When I try to open this stream using a gstreamer command gst-launch-1.0 rtspsrc location=rtsp://<my-drone-ip>:8902/live latency=0 ! "application/x-rtp, encoding-name=RAW, format=(string)GRAY8" ! videoconvert ! autovideosink I get a generic gstreamer error.
When I inspect that systemd status using systemctl status voxl-streamer-tof-depth I see internal errors of voxl-streamer:
● voxl-streamer-tof-depth.service - voxl-streamer
Loaded: loaded (/usr/bin/voxl-streamer; enabled; vendor preset: enabled)
Active: active (running) since Wed 2025-02-26 19:50:20 UTC; 14min ago
Process: 1469 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS)
Main PID: 1957 (voxl-streamer)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/voxl-streamer-tof-depth.service
‣ 1957 /usr/bin/voxl-streamer
Feb 26 19:50:31 m0054 voxl-streamer[1958]: ERROR: Frame size mismatch: got 43200 bytes from pipe, expected 38528
Feb 26 19:50:31 m0054 voxl-streamer[1958]: ERROR: Most Likely the publisher of the camera data made a mistake
Feb 26 19:50:31 m0054 voxl-streamer[1958]: ERROR: Shutting down voxl-streamer
Feb 26 19:50:31 m0054 voxl-streamer[1958]: Trying to quit g main loop due to program shutdown
Feb 26 19:50:31 m0054 voxl-streamer[1958]: cleaning up gstreamer
Feb 26 19:50:31 m0054 voxl-streamer[1958]: gst_rtsp_media_take_pipeline: assertion 'GST_IS_PIPELINE (pipeline)' failed
Feb 26 19:50:31 m0054 voxl-streamer[1958]: can't create pipeline
Feb 26 19:50:31 m0054 voxl-streamer[1958]: rtsp client disconnected, total clients: 0
Feb 26 19:50:31 m0054 voxl-streamer[1958]: no more rtsp clients, closing source pipe intentionally
Feb 26 19:50:31 m0054 voxl-streamer[1958]: Exited Cleanly
Note that when I use a similar gstreamer commands (adapted for h264) I am able to open other video streams without issues.
Additionally, since upgrading to SDK 1.4.1 from 1.3.5 whenever I run voxl-inspect-cam -a after approx 30s of running the camera servers all disconnect and a wall of:
Most likely the server stopped without cleaning up
Client is cleaning up pipes for the server
ERROR in pipe_client_open opening request pipe: No such device or address
appears. Should I be concerned?
@Dobry-Kolacz Thanks for the advice! After some further effort I ended up simply cutting the existing wires and splicing the new wires to these rather than desoldering from the ESC. The drone is back up and flying after being reassembled.
@Dobry-Kolacz I've tried some continued effort and still can't get the wires to budge. I am worried that there is a heatsink mounted to the ESC soaking up the heat from the soldering iron but I don't want to just hold the iron to the board for too long to prevent damaging it.
What is the ModalAI-approved technique for replacing motor wires?
thanks,
Griffin
@Dobry-Kolacz I ran into some delays due to missing parts/tools. Now I have encountered some difficulties getting the motors desoldered; even with significant flux I cannot get the motor wires to desolder from the ESC with a 650F iron held for 5-10s. The solder does not seem to heat up and become liquid.
Do you have any tips or advice for this step?
Kind regards,
Griffin
@Jeremy-Schmidt any update on being able to get the custom version? Thanks.
@Dobry-Kolacz thanks for the detailed instructions 
@tom thanks, that helped me get the drone and GCS connected over wifi!
Turns out I was slightly confused about exactly what was happening when I specified the mavlink connection ip.
Getting everything to talk correctly required editing /etc/modalai/voxl-mavlink-server.conf s.t. the primary_static_gcs_ip was my PC's address. Is there any way to automate this process so that I don't have to continually ssh into the drone to update the IP? Obviously the nuclear option is to assign everything fixed IP addresses.
Sorry for my lack of networking knowledge and thanks for the help,
Griffin
Hey all,
I am trying to find the primary GCS IP when the wifi is set to station mode. As per this diagram it is usually 192.168.8.10 when in softap mode and I am able to see the traffic via
sudo tcpdump -n -i any udp port 14550
However, when I setup the drone in station mode I do not see any traffic over 14550 and cannot find which IP address to send mavlink messages over. The instructions for connecting to QGC over 4G/5G do not clarify how the GCS IP address is specified in the case where both GCS and drone are connected to the same network.
Obviously I can find the drones ip via ifconfig
thanks for the help,
Griffin
P.S. running grep -r "192.168.8.10" . consistently crashes the drone
@Jeremy-Schmidt thanks for the response. Unfortunately, I didn't see the starling 2 max motors on the modalai website and ordered directly from a supplier. Is the cable adjustment difficult or tooling intensive? How would I order motors directly from you?
thanks,
Griffin
@tom Any updates or assistance available here? According to Motor Damaged @Jeremy-Schmidt is the best person to ask?
Kind regards,
Griffin
@Eric-Katzfey @tom unfortunately I don't see them in QGC with the 2 RTSP streams set up (and verified by connecting directly via openCV) and the voxl-mavcam-manager.conf as above.
Additionally, if I request camera information via mavlink I get result 2 (denied) when I request from the drone and result 4 (failed) when I request from the camera component.
Even with my mavcam setup as above I only see 1 camera component heartbeat over mavlink, not the 2 that I thought would be started with 2 mavcams inside the .conf.
@tom thanks! That seems to have allowed me to startup a second (and third) RTSP stream automatically which was my primary goal.
The reason I keep asking about QGC is because I am trying to get it so I can have my GCS automatically find any available RTSP streams, ideally without having to manually pass all of the individual URI. My understanding was that this is what the mavcam manager service is doing: creating mavlink camera objects which can be queried to get the rtsp streams, and that this is how QGC works. Since I do not yet have the querying setup I was trying to use QGC as test case, i.e. if QGC can do it, I should be able to do it with mavlink commands.
At the moment when I startup QGC and look at the camera output I see the following:
with my voxl-mavcam-manager.conf as above and my streamers:
voxl2:/$ systemctl status voxl-streamer
● voxl-streamer.service - voxl-streamer
Loaded: loaded (/usr/bin/voxl-streamer; enabled; vendor preset: enabled)
Active: active (running) since Fri 2024-12-06 22:40:09 UTC; 44s ago
Process: 1451 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS)
Main PID: 1942 (voxl-streamer)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/voxl-streamer.service
└─1942 /usr/bin/voxl-streamer
voxl2:/$ systemctl status voxl-streamer2
● voxl-streamer2.service - voxl-streamer
Loaded: loaded (/usr/bin/voxl-streamer; enabled; vendor preset: enabled)
Active: active (running) since Fri 2024-12-06 22:40:09 UTC; 53s ago
Process: 1450 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS)
Main PID: 1943 (voxl-streamer)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/voxl-streamer2.service
└─1943 /usr/bin/voxl-streamer -s -p 8901 -i hires_down_small_encoded