@Jskim
Finally, I tried a test.
I tried changing the video player and the Streamer died immediately.
The conclusion is that the Streamer died even when it was in the foreground.
플레이어 변경하면 바로 죽음.jpg

Thanks,

JS, Kim

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

@Dronodev Using the M0065 on a UART on the WiFi add-on board may be the most straightforward way to do this. We've never tried to set one up like that but, in theory, it should work if configured correctly in px4. There is no direct way right now to send the RC channel PWM input out the VOXL esc PWM output. There are a number of different ways to approach that so we'll take a look and see if we can come up with something in the next couple of weeks.

@FIREBIRD Please reach out here: https://www.modalai.com/pages/contact-us

@jmltt Each microhard modem hosts a web server that can be accessed via it's IP address. You can see what data is available and can likely script a query for signal strength. (They may have an API but it's not something we've investigated)

@Alex-Kushleyev Thank you very much!

@FIREBIRD Sure, reach out at https://modalai.com/contact

Yes, it's supported in production volumes

@Rowan-Dempster No problem! Kind of primitive but effective 🙂

@Eric-Katzfey

Okay, then I'm gonna do that. Thanks for the assist.

@QSL Hi, thank you for reaching out. There are many ways to achieve what you are trying. Starling 2 is the best starting point. You can then learn about what will work and what will not work and build out your system design from there.

it's more likely I will be commanding attitude / body rate which are already available

Indeed. I highly suggest you to use those two unless your application stricly requires direct actuation control.

I just wanted to get a clear overview of what the information dds client / agent can give me access to in the modalai version of px4.

By editing src/modules/microdds_client/dds_topics.yaml you can access any PX4 uorb message so the limit here is just about what has been implemented on PX4 that is or is not available in the voxl version.

How do you know what types of control / input & output data are not directly supported in px4 voxl version, as you said?

the type of offboard control you can achieve is exposed by OffboardControlMode.msg. As you can see in main PX4 you have

bool position bool velocity bool acceleration bool attitude bool body_rate bool thrust_and_torque bool direct_actuator

I've added thrust_and_torque and direct_actuator one year ago (more or less). However, latest voxl is still using the old version: this old version let's you control via thrust and torque setpoints but does not let you control the single motor individually.

Hey @ashwin, inside the following path:

modal-qdl/qdl/qfil_app/src/data/qfil/cdt

Can you run the following command and post the output?:

sudo /usr/local/bin/qdl \ --debug --storage ufs \ --include . \ prog_firehose_ddr.elf \ rawprogram3_RB5.xml \ patch3.xml

This will give a more verbose output as to why your VOXL 2 is failing the CDT flash, thanks!

@jonathankampia Correct, The VectorNAV needs to have the serial port implementation changed to support SLPI. That can either be done by modifying the code on our branch or going to mainline PX4 and modifying the implementation to use the platform independent Serial port abstraction.

@teddy-zaremba Temporary fix by just installing missing package:

apt-get install -y libwayland-server0:arm64 libwayland-dev:arm64

Also have to install this for voxl-portal

apt-get install -y libglib2.0-0:arm64

@Vinny Thanks for all the info.

@nekolny You should be able to use voxl-mavlink-server --help to see the various debug options available. You can stop voxl-mavlink-server from running as a service and then start it manually from the command line with the desired debug options to see which messages it is getting from the autopilot and what it is sending to QGC (and vice-versa). Then you can also use tcpdump to look at the IP traffic on both VOXL 1 and the QGC computer to see which messages are being sent.