Topics created by dan64

Hello @dan64,

The px4-esc-cal-tool does not apply to ModalAI uart-based ESCs. That tool was used for calibrating ESC response to PWM control signal for old-style ESCs.

There is no need to re-calibrate the ModalAI ESC if you use a stock configuration, such as the motor + propeller that comes with Starling 2 MAX.

The ESC parameters for this motor + propeller are located here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml

You could use voxl-esc tools to verify this. Since you already ran the spin test using voxl-esc tools, this should be somewhat familiar.

./voxl-esc-verify-params.py

This should query all the params on your ESC and they should match the same param file (which is also stored in /usr/share/modalai/voxl-esc-params/ folder.

From the test spin results, it does appear that a motor may be faulty. I am assuming this behavior happens every time you run the test. However, you can never know for sure that the motor is at fault - it could be an ESC issue. In such case, the best thing to do is to do a similar test with another motor attached to the ESC channel in question. The ESC with the correct params is tuned for this motor + propeller and has been thoroughly tested, so I do not recommend trying to fix this by modifying ESC parameters (this will most likely result in a wasted effort).

You can purchase the Starling 2 Max replacement motor here : https://www.modalai.com/products/starling-2-max-replacement-parts?variant=49704826896688 . It looks like the image for the motor has the wrong kV (2850), but the actual motor kV will be 1500.

The motor used on Starling 2 Max very similar to Tmotor 2203.5 1500kv, you could also replace it with this one without changing any parameters.

Testing a replacement motor should be relatively easy if you cut the motor leads on the motor arm and not disassemble the drone to get access to the ESC. Remove the old motor and solder and heat shrink the connections for the new motor and repeat the spin test (in order to make sure that the spin direction of the new motor matches the old motor, you can mark the wires before cutting and solder the new motor in the same wire order). If you wanted to not cut the motor wires along the arm, then you would need to do some disassembly to gain access to the ESC solder pads. (instructions outlined here : https://forum.modalai.com/topic/4023/motor-replacement-instructions-starling-2-max).

I am curious what the motor spinning actually looks / sounds like, so if you are able to record a short video of the motor spinning, starting from the spin-up (just the faulty ID), that could be helpful:

./voxl-esc-spin.py --id 1 --power 15

Alex

@paul-ammer , sorry for the delay. Initial version of the document that addresses latency in wifi streaming has been published : https://docs.modalai.com/camera-video/low-latency-video-streaming/

There is a lot of information there, please take a look and let me know where you get stuck.

I suggest starting to experiment without updating the camera drivers (as discussed in the document), so you reduce number of variables at the beginning. You can also use the Qualcomm ISP pipeline (using hires_front_small_encoded stream) and we can discuss what MISP can be used for at another time.

In general, you will find that the majority of the delay is going to be on the receiver side, with some additional delay possible in the server side after the camera pipeline (buffering of the encoded frames before sending them out - I believe gstreamer rtsp server adds some delay. voxl-streamer is based on gstreamer).

Regarding the earlier question of unused streams: yes it is true that if streams like large_video, etc, are enabled but not used, they will not consume significant resources, however, if enabled, the stream specifications (dimensions) will play a role when the camera pipeline selects the camera operating mode, which should satisfy requirements of all streams. The most extreme case is when you enable the snapshot at highest possible resolution (but use the snapshot very rarely), and your video streaming resolution is relatively low - the camera pipeline will have to select the camera mode that provides the largest image size (which will be the slowest in terms of latency) and then will downscale to get the video stream of the desired (small) resolution.

Please let me know what other questions you may have. I will continue updating the document in order to clarify things and based on feedback. If other users have questions, feel free to follow up in this thread.

Alex

Hi @dan64
That is not the standalone Modem board variant and many other components are missing to make this work.
We do not currently sell the "standalone" version of the M0090 (5G) or M0130 (4G LTE), so sadly your efforts will hit a dead end.

@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.