Posts made by 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

@tom they do not appear in qgc when I manually start up the second streamer.
Your original response seemed promising to me, how can I automate starting up a second rtsp stream if not through the voxl-streamer?

Additionally, I am not sure about the exact behavior of the different parameters for each mavcam in the voxl-mavcam-manager.conf, why exactly do I need to specify the pipes for video and and snapshots? Are they just for if mavlink commands are sent to start recording or capture a screenshot? But why do we need to send a video record command if the GCS is already receiving the video stream?

Are the mavcams in the .conf file also what create the camera components that are visible as mavlink heartbeats when connected to the drone? Do you know what command I can use to request the RTSP URI via mavlink (as I assume QGC does)?

Sorry for the barrage of questions, just trying to understand how to wrangle a mutlicam RTSP setup nicely.

@tom regarding your previous response about /etc/systemd/system/voxl-streamer.service, I don't see a call to the voxl-streamer.conf file in there, only to the .pid and binary files. Do you know how I can modify the configuration loaded into a secondary voxl-streamer process?

@tom yes, I have tried viewing the streams independently and verified that they work using gstreamer and opencv. For some reason VLC errors out but that seems to be a VLC issue

Hello all,

I am using the RTSP streams from a Starling 2 Max drone, it is unclear to me how voxl-streamer and voxl-mavcam-manager interplay with the produced RTSP streams. Ideally, I want to be able to automatically setup several streams for different cameras. I already have a setup to intercept the streams and just need to get the aircraft to broadcast the separate streams.

• Based on the voxl-streamer documentation, it seems that it is the RTSP streams which are what QGC is using to display video.
• The voxl-mavcam-manager documentation seems to indicate that it is the method by which QGC locates the necessary RTSP streams.
• My understanding is that the voxl-mavcam-manager is what creates the other, camera components that are visible as mavlink heartbeats and which QGC can query to get the RTSP URI and send commands to.
• However, I do not understand why the voxl-mavcam-manager.conf includes snapshot, video record pipes, and URI fields.
• Is the URI assumed to be the input to voxl-mavcam-manager, where it can find the RTSP stream to send to QGC? Or is this the output, i.e. where voxl-mavcam-manager will send the stream. Based on other wording in the doc I would assume the former but am not sure, I have not been able to view 2 streams from QGC.
• Since it seems I will need to have 2 instances of voxl-streamer running, how can I set this up programmatically such that the 2 instances are started on startup. It does not seem like I can just add another streamer to the voxl-streamer.conf file.
• If I want to have 2 streams running while not in SoftAP mode, how can I setup the uri? The documentation indicates that using auto ip is only possible when streaming a single RTSP stream.
• How can I manage 2 streams when connected over 4G/5G? Will I need to hardcode in the ip address of the drone?

I have not yet been able to get 2 streams to appear in QGC with the following voxl-mavcam-manager.conf :

{
        "mavcam_inputs":        [{
                        "snapshot_pipe_name":   "hires_front_snapshot",
                        "video_record_pipe_name":       "hires_front_large_encoded",
                        "default_uri":  "rtsp://192.168.8.1:8900/live",
                        "enable_auto_ip":       true,
                        "mavlink_sys_id":       1
                },{
                        "snapshot_pipe_name":   "hires_down_snapshot",
                        "video_record_pipe_name":       "hires_down_large_encoded",
                        "default_uri":  "rtsp://192.168.8.1:8901/live",
                        "enable_auto_ip":       true,
                        "mavlink_sys_id":       1
                }]
}

and a second stream started manually with voxl-streamer -s on port 8901.

Any help is appreciated,
Griffin

The starling 2 max datasheet lists the motors as 3000KV 1504 motors, the motors on the aircraft we have appear to be 1500kv not 3000kv. Which number is correct?

Hey all,

After an unfortunate crash the 2 front motors on our Starling 2 Max are damaged (they stick in one portion of the rotation) and need to be replaced. I have ordered 2 new Tmotor 2203.5 1500kv motors but it looks like the motor cables go under the main VOXL boards to the ESCs.

Are there any disassembly or repair instructions for the Starling 2 Max?

Kind regards,
Griffin

P.S. Do not command the drone to do a position change with a simultaneous 1m xy reposition and a 2m z change. The drone commanded a 10m/s acceleration and flew into a wall

@navin_kaviyarasu I got stuck at the same point earlier, you need to swap the EKF to use the VIO instead of waiting for GPS.

@tom said in Position Mode Unavailable:

You can load the indoor VIO parameters by doing the following:

Open PX4 param wizard

voxl-configure-px4-params -w

Select EKF2_helpers

Select indoor_vio.params

Load the parameters and power cycle your drone

edit: use mavutil.mavlink.MAVLINK_MSG_ID_LOCAL_POSITION_NED* instead of magic number 32 for message ID

For anyone running into similar issues, here is the solution I found:

You can manually adjust the interval times of mavlink messages with the MAV_CMD_SET_MESSAGE_INTERVAL command, in this case for the LOCAL_POSITION_NED message.

Using pymavlink this can be accomplished with:

        # [...]
        self.client = mavutil.mavlink_connection(
            connection_string,
        )
        # [...]
        self.client.mav.command_long_send(
            self.client.target_system,
            self.client.target_component,
            mavutil.mavlink.MAV_CMD_SET_MESSAGE_INTERVAL,
            0,  # confirmation
            32, # LOCAL_POSITION_NED
            10000, # Wait time in us
            0, 0, 0, 0, 0  # param3-7: unused
        )

Hope this helps anyone else who wants higher rate data!

Hey all,

I'm trying to use offboard control mode to give velocity commands to a starling 2 max and need position information at higher than 10 Hz (the default rate at which mavlink position messages are published)

Is it possible to access this information at a higher rate either by increasing the mavlink publishing rate or using MPA?

Kind regards,
Griffin

@admin @Moderator Any suggestions on how to prevent this altitude divergence? This happens somewhat regularly and requires reversion to manual control.

Hey Everyone,

Working on a mavlink connection API for a starling max 2 and encountered some unknown messages being output from the drone:

Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', 'fd', '1', '1', '9a', '1', '0', 'b9', '1b', 'd3', '1', '8b', 'a0', '12', '0', 'c0', '1', '0', '0', '33', '3c', '0', '7e', '0', '14', '5', '39']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', 'fe', '1', '1', '9a', '1', '0', '73', 'c2', '98', '1', '8b', 'a0', '12', '0', 'c1', '1', '0', '0', '33', '38', '0', '0', '0', '14', 'b9', '3c']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', 'ff', '1', '1', '9a', '1', '0', 'd9', 'c2', '5', '1', '8b', 'a0', '12', '0', 'c2', '1', '0', '0', '66', '8', '0', '0', '0', '14', '89', '88']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', '0', '1', '1', '9a', '1', '0', 'c7', '1d', '2f', '1', '8b', 'a0', '12', '0', 'c3', '1', '0', '0', '33', '0', '40', '0', '0', '14', '67', 'cb']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', '1', '1', '1', '9a', '1', '0', '30', '36', '1', '1', '8b', 'a0', '12', '0', 'c4', '1', '0', '0', '66', '20', '0', '0', '0', '14', 'ad', '27']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', '2', '1', '1', '9a', '1', '0', '29', 'ed', '6', '1', '8b', 'a0', '12', '0', 'c5', '1', '0', '0', '44', 'ff', 'ff', 'ff', 'ff', '7', 'd8', '78']}
Unhandled message: UNKNOWN_410 UNKNOWN_410 {data:['fd', '12', '0', '0', '3', '1', '1', '9a', '1', '0', '27', '37', '1d', '1', '8b', 'a0', '12', '0', 'c6', '1', '0', '0', '88', '0', '2', '19', '2', '28', 'd7', '8f']}
Unhandled message: UNKNOWN_380 UNKNOWN_380 {data:['fd', '14', '0', '0', 'a', '1', '1', '7c', '1', '0', '0', '0', '0', '0', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', '5', '50']}
Unhandled message: UNKNOWN_290 UNKNOWN_290 {data:['fd', '2e', '0', '0', '30', '1', '1', '22', '1', '0', '59', '4f', 'd2', '48', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', 'b3', 'd1', '0', '0', '0', '0', '0', '0', '0', '0', '7c', '15', 'b4', '14', '18', '15', '7c', '15', '0', '4', '1', 'f', 'f8', 'cc']}
Unhandled message: UNKNOWN_291 UNKNOWN_291 {data:['fd', '28', '0', '0', '31', '1', '1', '23', '1', '0', '59', '4f', 'd2', '48', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', 'd6', '78', '47', '41', 'b3', '9d', '47', '41', 'c7', '4b', '47', '41', 'bd', '74', '47', '41', '77', '1e']}
Unhandled message: OPEN_DRONE_ID_LOCATION OPEN_DRONE_ID_LOCATION {target_system : 0, target_component : 0, id_or_mac : [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], status : 1, direction : 36100, speed_horizontal : 25500, speed_vertical : 6300, latitude : 0, longitude : 0, altitude_barometric : 111.9713363647461, altitude_geodetic : -1000.0, height_reference : 0, height : -1000.0, horizontal_accuracy : 0, vertical_accuracy : 0, barometer_accuracy : 1, speed_accuracy : 0, timestamp : 65535.0, timestamp_accuracy : 0}
Unhandled message: UNKNOWN_380 UNKNOWN_380 {data:['fd', '14', '0', '0', '3c', '1', '1', '7c', '1', '0', '0', '0', '0', '0', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'ff', 'db', 'a0']}
Unhandled message: UNKNOWN_411 UNKNOWN_411 {data:['fd', '2', '0', '0', '58', '1', '1', '9b', '1', '0', 'c6', '1', '79', '8d']}
Unhandled message: UNKNOWN_290 UNKNOWN_290 {data:['fd', '2e', '0', '0', '64', '1', '1', '22', '1', '0', 'af', '8b', 'e1', '48', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', 'd6', 'd4', '0', '0', '0', '0', '0', '0', '0', '0', '7c', '15', 'b4', '14', '18', '15', '7c', '15', '0', '4', '1', 'f', 'e8', 'e6']}
Unhandled message: UNKNOWN_291 UNKNOWN_291 {data:['fd', '28', '0', '0', '65', '1', '1', '23', '1', '0', 'a0', '90', 'e1', '48', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '73', '68', '47', '41', 'cb', 'a1', '47', '41', '7e', '3f', '47', '41', '7', '81', '47', '41', '9d', 'f5']}

I have been looking at the messages being broadcast from the drone and had not seen these specific messages until just now. The output is from a GCS script and throws the Unhandled message: exception when an unknown message type appears along with the type and content of the message.

• Where can I find the necessary definitions for these extra / unknown message types? I am only using the common.xml definitions (afaik)
• Why would the drone ID messages suddenly start appearing? This appears to be part of the remote ID system; does this mean that someone nearby is sending out pings?

Thanks for any help!

Kind regards,
Griffin