@Eric-Katzfey I am not familiar with the "modalai-slpi" codebase, could you elaborate on what that is.

@kestrelsystemsbp Perhaps you can do a fresh installation on 1.3.5 and see if the problem goes away? v1.3.5 has a lot of test time on it and nothing like the issue you are seeing has been encountered by us or any of our customers so this is a bit of a mystery. I would try the fresh install and, without making any modifications at all, see if it comes up and stays up. If so you can start introducing any configuration changes you need one by one to see if any of them are causing the issue.

@buem799 If it uses CRSF on the UART then should be fine. Do you have a pointer to the data sheet for the exact receiver you are considering?

For additional context, here is our voxl-streamer.conf:

{   "input-pipe":  "hires_front_small_encoded",   "bitrate":  1000000,   "rotation":  0,   "decimator":  1,   "port":  8900 }

@Alex-Kushleyev Here are the results of testing with a brand new GPS from a different manufacturer (https://holybro.com/products/micro-m10-gps?variant=42981482954941). The GPS is in the same position as the original, but connected to u-center. As with prior tests, Lepton is disconnected and ALFA is removed.

Top u-center screen shot is with drone powered OFF, bottom is drone powered ON. To me this Holybro GPS looks about the same as the 3DR GPS, i.e. satellite signals drop significantly with drone powered ON. Not shown are results where I found that the satellite signal increased significantly when I moved the GPS module farther away and/or added shielding.

What do you suggest as next steps?

Thanks for your help.

Holybro.jpg

holybro-gps-drone-off.png

holybro-gps-drone-on.png

Cheers @tom ill give it a try

@Eric-Katzfey thanks for the quick reply. Since 14550 is hard-coded into voxl-mavlink-server service, that answers my question re: customizing this port.

For additional context, I'm interested in replicating QGC's behavior of connecting to multiple UAVs simultaneously, each identified by their MAV_SYS_ID. As an example:

Set MAV_SYS_ID to "42" on one VOXL Leave MAV_SYS_ID as "1" on another VOXL Set secondary_static_gcs_ip to your GCS IP on both (/etc/modalai/voxl-mavlink-server.conf) QGC automatically connects to both and shows "Vehicle 42" and "Vehicle 1" in the dropdown in the top menu bar

I'm able to connect to my UAV using mavsdk at udp://:14550 but I can't tell which one connects since both are sending telemetry to my Mac's 14550.

Since posting this, I discovered https://github.com/mavlink-router/mavlink-router which may be what I'm looking for, but I'm still trying to get it working with my docker-compose setup. I was just wondering if there was a simpler configuration onboard the VOXL that I could easily change.

@Samuel-Lehman This is an issue with TensorFlow and your model. You could try enabling the v2 control flow ops as mentioned here (https://www.tensorflow.org/api_docs/python/tf/compat/v1/enable_control_flow_v2). Your model likely contains some older ops that are not compatible with Tflite (you mentioned having trained it a few years back). You could try the official solution given by tensorflow as linked or you could perhaps retrain your model with newer libraries.

Note that you do not necessarily need to train with TensorFlow; you can train using any other framework as well. Moreover, you are converting a frozen graph, and the official docs recommend converting from a saved model (https://ai.google.dev/edge/litert/models/convert_tf). Hope this resolves your issues!

@Käptnzursee There is no restriction for voxl-mapper running on VOXL 2 Mini. Is there any reason to believe it shouldn't?

I also found the following:

px4-commander does not start automatically. "Compasse sensor 0 missing" does not disappear with the following comannd, and the preflight check fails.

EKF2_EV_CTRL = 15
EKF2_HGT_REF = 3
COM_ARM_WO_GPS = 1
SENS_MAG_MODE = 0

@dan64 It may be helpful to post a picture of your setup so we can catch any wiring issues

@buem799 Hi, no worries, I am also very new to this space. ffplay is separate thing, part of the ffmpeg program, not something inside VLC. This is the reddit link that I posted in the thread I listed above

https://www.reddit.com/r/reolink/comments/yzhlxp/found_a_solution_for_rtsp_blackno_video_in_vlc/#:~:text=In VLC%2C under the Tools,video stream in VLC player

If you read through it, the fix was for a windows machine, which I was using at the time. It states further down in the reddit post that live555 support was removed in newer versions of ubuntu (linux operating system). From your screenshots, it looks like you are using ubuntu, so it could make sense that VLC may not work. I believe it is more a ubuntu issue rather than VLC. Don't try to dig into that, especially if you are new to linux. I would install ffmpeg on your system and try to access the RTSP stream using that. I just asked ChatGPT for the commands to do that and will paste below:

sudo apt install ffmpeg

Id recommend asking Chat how to access an RTSP stream using ffplay, or read the documentation 🙂

The other thing you could do, if you had a windows laptop, you could connect the windows laptop to the drone wifi and try to access the RTSP stream via VLC on windows and do the fix included in the reddit link

@voxl-phoenix , I think you also mentioned that you tried swapping the cables between tracking and imx412 camera, right? If so, it seems something got damaged in the IMX412 camera during connecting / disconnecting. For disconnecting the cables, we suggest using a special tool, please see https://docs.modalai.com/micro-coax-user-guide/#-proper-cable-and-adapter-handling- .

Also, it is hard to say for sure where exactly the issue is - M0173 board or IMX412 camera. the only good way find the cause is to replace components one at a time.

Just to elaborate on the symptoms that you are seeing : voxl-camera-server -l command essentially probes all the cameras (based on the sensormodule files located in /usr/lib/camera). Probing involves turning the camera on via the reset GPIO and attempting to talk to the camera via I2c interface. If the camera responds, the probe is successful, otherwise failed. In your case, the probe of IMX412 failed, which means either the camera could not be turned on for various reasons or the i2c communication was not working.

If you have another tracking camera AR0144, you could connect it instead of the IMX412 and see if the probe succeeds. You would need to add /usr/share/modalai/chi-cdk/ar0144/com.qti.sensormodule.ar0144_1.bin file to /usr/lib/camera (which is the AR0144 sensormodule for the camera slot 1, where the IMX412 is currently connected). Then if you run voxl-camera-server -l and detect two AR0144 cameras (3 cameras total) then i2c communication and power should be working).

Alex