Posts made by brandon

Platform: Starling 2 Max (M0054 / MRB-D0012)
Software: voxl-suite 1.5.0, system-image 1.8.04, PX4 1.14.0

We've tested 3 Modal AI EKF2 helper configs across 15+ outdoor flights on Starling 2 Max. VIO+GPS causes yaw-reset and crashes. GPS with baro height ref reports negative altitude. GPS with GPS height ref balloons. None produce stable altitude. We need reliable altitude for autonomous precision landing on a containerized system. What config do other operators use?

Reference logs:

• GPS+baro height ref: https://review.px4.io/plot_app?log=55f037ae-36d2-4ce1-bbd6-919ddc6da630. Negative altitude while clearly airborne, unstable vertical velocity
• GPS+GPS height ref: https://review.px4.io/plot_app?log=fd7a0bba-991c-44fe-95e7-238caeda5c5f. Altitude ballooning, floating around in safety pilot joystick control. Best example showing altitude instability over an extended period.
• GPS+GPS height ref: https://review.px4.io/plot_app?log=5f1ae22c-d6a5-4963-a57d-3970c9d34e5b. Best example of successful flight yet, but still has significant altitude issues.

We've tried the ekf2_universal_tweaks.params file as well as the outdoor_gps.params and outdoor_gps_baro.params files. When using the barometer we've also applied the exposed_baro.params file. We've recalibrated the barometer using the VOXL web portal. We've run IMU calibration repeatedly both in QGC and the terminal interface in VOXL. We also tried upgrading the SDK to 1.6.3 on one of our test drones.

We have many more logs but this is the best scattering of what we've been struggling with. Please help, thank you.

Sentien Robotics.

@Moderator Thanks for the quick response!

Which helper would you recommend for outdoor flight configuration with GPS? I see there are several available for different variations.

An added detail: we need good relative altitude measurements at low altitudes for our custom precision landing solution.

Hi,

Is there recommended default configuration for out-of-the-box Starling 2 Max's for generic outdoor flight?

We've been experiencing the following problems across 1 LTE drone and 5 non-LTE drones, intermittently. The primary symptom was originally unreliable altitude/height measurements on the LTE drone. Sometimes reporting height wrong by 10m+ or more, or negative altitudes. There also has been consistent "Preflight fail: height estimate unstable" and similar messages, though the LTE drone manages to arm more often with these displayed errors.

After swapping to the non-LTE drones we had some crashes. Here are the two flights we had that crashed, and despite being able to arm, they were fighting against control inputs from the pilot once in the air and seemed like they had little or no GPS fix based on our review of the logs:

• https://logs.px4.io/plot_app?log=ec33a5ca-db61-4b26-a72a-d0678973d501
• https://review.px4.io/plot_app?log=fa945bd6-3734-4f78-8567-c008234c8042

starling2-max (D0012):~$ voxl-version
system-image: 1.8.04-M0054-14.1a-perf
kernel:       #1 SMP PREEMPT Mon Mar 24 22:31:58 UTC 2025 4.19.125
hw platform:  M0054
mach.var:     1.0.1
SKU:          MRB-D0012-4-V2-C29-T9-M28-X0
voxl-suite:   1.5.0

Thank you for any guidance or support

@Eric-Katzfey Is this fix in the new 1.5.0 binary? We received a new Starling 2 Max but I think I had to downgrade to this binary to get connectivity.

@Eric-Katzfey This works! Thank you!

@Eric-Katzfey I have this issue as well. The voxl-mavlink-server only replies to 14550 even when GCS initiates connection. This prevents multiple drones from communicating to separate processes on a common computer. Please see my response here where I tried to outline the issue: https://forum.modalai.com/post/24187

If this command worked all of the posts relating to the port issue would be resolved: mavproxy.py --master=udpout:<voxl_ip>:14550

I am also having this issue. I think that the voxl-mavlink-server may have an incorrect implementation of the "server" side of the UDP connection. My evidence would be that using mavproxy.py from a remote computer in client mode (e.g. mavproxy.py --master=udpout:192.168.83.254:14550) does not receive packets from the server, but the server does detect the connection.

I took a look at wireshark and saw that the voxl-mavlink-server in "server" mode is not replying to the mavproxy.py client on the correct port. It is replying to 14550 at the client (incorrect). See the picture below, but ignore IPs as data capture was on a different network. You can see the mavproxy client sending from port 33935 to voxl at 14550, but the voxl incorrectly replies back to 14550 on the client computer when it should be replying back to 33935.

The side-effect of this is that you cannot have two independent clients (talking to different drones) running on the same computer because both drones will send their data to the same port. Computers only allow one process to be a server on a given port.

@Dobry-Kolacz Here is another connector that I think is relevant that I didn't include in the last post. I'm not sure how I should apply force but I tried to push them in a little bit as instructed. Nothing seemed to move and there is no change on the Voxl Portal.

@Dobry-Kolacz I’ve seen a few frames come through before, and one time I’ve seen half a valid frame and static noise on the other half of the frame. I didn’t take a picture at the time because I didn’t know it was a problem yet. I was just learning how to ssh in and connect the drone to my WiFi network.

@Dobry-Kolacz

@Alex-Kushleyev What did your team recommend? Should I reach out to ModalAI directly?

@Alex-Kushleyev I performed the next test and the voxl-camera-server crash occurs after a short period of time. I was able to bring up a few camera feeds and then the service died. I was never able to see a frame from the hires_front.

@Alex-Kushleyev I have not seen the camera work before. I just started developing with it and thought it might be related to a software bug I was seeing on the forum.

Hi @Alex-Kushleyev, thanks for the feedback.

I disabled the hires_front and things seem a lot more stable. What steps can I take to debug the hires_front crc errors?

@brandon Just posting some more context. When looking around the forum I found that I should provide a dmesg log because it looked like voxl-camera-server was aborting.

Hello,

I just started developing with the Starling 2 Max (sku:MRB-D0012-4-V2-C29-T9-M24-X0) and am unable to see video from the hires_front camera. I saw a post here: https://forum.modalai.com/topic/4139/voxl-portal-wont-display-live-camera-feeds-after-sdk-1-4-0-upgrade that might have a similar issue, but my model has the latest software. Does anyone have ideas on what steps I can take to debug this?

The voxl-inspect-cam -a output is garbled with messages like "ERROR in pipe_client_open opening request pipe: No such device or address".