@Alex-Kushleyev The fix is available in this build: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.77-202406051703_arm64.deb

@restore , yeah, good plan..

@Jeremy-Frederick, can you specify which ESC you are asking about? The PWM pins on the ModalAI ESCs (which have the pwm signals on a connector or test pads) are bi-directional, and yes they could be used as PWM output. However, a firmware change is required and enabling PX4 to send out PWM signals is another change We were considering enabling this feature but it is not yet implemented. Can you please provide more information about your requirements? what type of PWM signal are you trying to send ? min/max range, update frequency, (is it one shot, or just preriodic) how often are you planning to update the value of this PWM signal? how many PWM signals do you need? what is the source for the control of PWM signal in your application (RC or something else?). The reason why I am asking, the ESC would need to receive a serial data packet from voxl_esc driver in px4, so somehow that pwm output information would need to enter the voxl_esc driver. Alex

@schew, Regenerative braking happens when you command the ESC to transition from a higher speed to a lower speed. Also, if brake_to_stop parameter is set to 1, the ESC will apply braking when it is commanded to stop (0 rpm or 0 power) or it times out. If the brake_to_stop parameter is set to 0, the ESC will not brake during stopping or time out, instead the motor will spin freely (coast) to a stop. So, brake_to_stop parameter does not affect normal operation and you should just keep that at zero, unless you REALLY need the motor to stop very fast when you disarm. (but then if you are connected to a power supply at that point, it can cause issues described here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/regenerative_braking.md ) Turning off Regenerative Braking completely is possible on M0129 ESC, but it is not currently supported in the firmware. So, to answer your question, if you run the ESC calibration using voxl-calibrate-esc.py script (according to these instructions : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md), there will not be a regenerative braking event during this procedure (unless you set brake_to_stop to 1, see above). In the calibration procedure, the ESC is commanded to increase the applied power in small steps and at the end the commands from the script stop, so ESC times out and spins down. I have just run a test using a power supply (set to 12V) and modified calibration script, which shows voltage and current data after the calibration has finished. See plot below: [image: 1717037084592-ad88ce7f-2a54-48a5-96cb-970af729443a-image-resized.png] From the plot you can see that at t=12s, the test stops, the voltage (which was dipping during the test as current increased) comes back to 12V without overshoot and the current just drops to zero (does not become negative, which would be the case, if regenerative current was present). I have explained what will happen if you run the esc calibration procedure (in its current version) while using a power supply. However, you should not do any aggressive spin testing with a power supply, especially step tests, where the ESC is commanded to ramp up and then down. The reason why we do not recommend doing any testing with a power supply is that it is possible to forget that the ESC is plugged into the power supply (not battery) and start performing tests which can damage the ESC or power supply. If you start hitting the Power Supply's over-current limit, voltage may drop and there could be strange behavior and ESC could de-sync. You also need to ensure that the Power Supply can source enough current to perform the calibration. If needed, you can decrease the maximum power that is applied during calibration (using --pwm-max parameter) So, with all that being said.. We still do not recommend testing the ESC with a power supply. If you still choose to do it, it would be at your own risk and i suggest starting by limiting --pwm-max parameter to a low value, say 40-50 and looking at the plot to ensure all the data looks similar to the plot in the calibration doc. Then gradually increase the --pwm-max parameter to 60, 70, 80, 90, checking the plot each time. You could stop at 90 and use that calibration result. Alex

@0x45 , each of the 4 ESCs sends back telemetry to PX4 at 1/4 of the update rate of PX4. On voxl2, the PX4 update rate is 800hz, so each ESC channel sends back telemetry at 200hz (round robin fashion). Only one of the four ESC channels actually measures current on the 4-in-1 mini and FPV ESCs, so you will have the current update (and hence the battery status) received at 200hz, but px4 is throttling publishing of battery status to 10hz. Alex

@Jeremy-Frederick, that is great! Luckily (or by design ) the camera connector reversal is typically not fatal, but DO NOT push your luck, please . Technically, if damage occurs due to incorrect insertion of the camera connectors, this will void the warranty for the main board. Always verify connector orientation when changing camera configuration. Alex

@iparra , There is no need to re-calibrate the ESC parameters if you replace the damaged motor and / or propeller with the identical parts. The ESC parameters are tuned to a motor/propeller type, not a specific motor / propeller unit. You can replace only the damaged components. If the flight feels more wobbly after you replaced the damaged propeller with new one, it is possible the remaining propellers are also damaged or bent, which is causing more vibration. Alex

@Gary-Holmgren , camera server does not support rotating images by 90 degrees (or multiples of 90). You could do this yourself in your image processing application. If you mount the cameras rotated by 90 degrees (while keeping the baseline along the left-right direction of the drone), you would need to modify your extrinsics to account for this rotation. If you perform a stereo camera calibration in this rotated configuration, then the output of the stereo calibration should give you the baseline result between the cameras in the Y direction in the camera frame (as opposed to X direction in normal case). If you have a question about a specific configuration, please make a drawing that shows reference frames of the vehicle, imu, and both cameras and I can help you double check the extrinsics. Alex

@Chase-Riley yes, we can work with Doodle Labs to get this resolved

@dlee we don't have those benchmarks yet, sorry. The IRS2975C based TOF should go 1-2m further than the old one

@Alex-Kushleyev Oh, very fascinating. Thank you for the update! I'd actually somewhat given up on DFS and started testing your new ToF beta product, but when I can I'll try boot my DFS rig back up and see if the fix helps. Edit: Nevermind, I just checked and my DFS rig is on SDK v1.1.2, so this fix shouldn't be applicable. I might still try it out just in case, though.

@Denver-Bennett Great, glad to hear that helped!

@Moderator No, it does not. You need to rely on QGC or other reporting tools.

@Eric-Katzfey okay - too bad. Is it still on the to-do list or no longer in the plans?

@Chase-Riley Yes, as Alex said, most standard builds do not include the voxl_esc driver. Only the ModalAI products include it as a standard part of the build. So you will need to add that to you build configuration.

@K-Stute , sounds great! if it happens again, let us know, we can debug. Alex

@blue , i just fixed (a few days ago) the calibration script (on voxl-esc dev branch) to plot the total current for M0138 in the calibration procedure, however, yes you still need to run the calibration test using ID2. This is because ID2 measures the total current and it only sends back the data if the feedback is requested from it. If you are running a test on a single ESC which is not ID2, then ID2 is not asked to send any data back, this allows for 4x the feedback rate for that single ESC that is being tested. So on M0138 if you want to see the current output, you should use ID2 for testing: ./voxl-esc-calibrate.py --id 2 --pwm-min 10 --pwm-max 95 Currently, the current ( ) is not used for anything in the calibration procedure, but it is good to look at it to make sure it follows a smooth curve as the power ramps up. Thanks, I try to add as much data to plot as possible because it is often easier to spot issues by looking at the plots. By the way, it seems your data time scale is kind of coarse (seems like 14-15hz). Sometimes this can happen if your USB-to-serial adapter buffers too much data.. are you using a PC or VOXL for this test? if you are using FTDI, this may be helpful to test out : https://granitedevices.com/wiki/FTDI_Linux_USB_latency You should be able to get really nice plots when using 2Mbit baud rate and --cmd-rate 1000 or even 2000 helps catch any small spikes or anomalies. In your calibration test that you originally posted (where the current was reported zero), it looks like towards the end, the top left curve (commanded motor voltage vs rpm) starts curving up a bit more, that can suggest that the motor is not operating optimally at that point. I am not sure which motor / propeller you are testing, but sometimes it helps to adjust the ESC commutation advance from 0 to 20 or so (esc param <param name="timing_advance" value="20"/>). You could try that and see if the high end shape of the curve does not curve up as much. Alex

After multiple tries of updating the firmware and uploading the parameters, it seems to have finally worked!!

@mark SDK 1.1.1 and greater is required https://docs.modalai.com/M0107/