We do not support DSHOT when using Voxl2 + IO Expander board. However, OneShot125 is supported (though you would need to re-build voxl-px4 pakage and change the following scale factor : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/voxl2_io/voxl2_io.hpp#L133) -- set MIXER_OUTPUT_TO_CMD_SCALE = 125 instead of 1000. This would reduce the actuator latency by 1-2ms (as long as the ESC supports OneShot125).

@vinny @alex-kushleyev @tom Thanks for the input guys! Happy to report it is all working as intended. Much appreciated.

Hi @Jetson-Nano, Can you please clarify the following - in your original post, you mentioned that the third party ESC also had issues, however in the post above you said no issues. I am quoting your notes from above: " Scenario 3 – Third-Party ESC Evaluation To further isolate the issue, we replaced the VOXL FPV ESC with a NeutronRC X-CLASS 4IN1 ESC V2 (3–8S, 70A) configured using the DShot protocol. During testing, we observed the following: ESC temperature increased rapidly, reaching approximately 80°C to 90°C within two minutes of flight. One motor would subsequently stop during flight. The aircraft would lose stability and crash. " I just wanted to clarify what actually happened and then we can investigate further. Than, you for providing the diagram, i think it looks OK. I have never seen this behavior where the ESC reports incorrect voltage and these short spikes in temperature. This may point to a hardware issue on the ESC board, but i do not actually know where it might be or what would cause it. Have you visually inspected the FPV ESC that has this issue to see if any components appear damaged or anything looks unusual? Alex

@qubotics-admin , thanks for doing the motor swap test. From this result, it does appear that one of the ESC channels is not working properly. We would like to take a look at the ESC - are you able to send it back for inspection? We can send you a replacement ESC in return. Alex

@extmoddain , Can you please send a picture of the damaged ESCs? Which component blew up? Also what do the labels on the ESD bags from those ESCs say? The 6s version of M0129 (mini ESC) should have a small label on the white 4-pin connector that says either -63 or -65 (meaning 6S and either 3.8V or 5.0V output for VOXL2 mini or VOXL2). We can also check using the serial number (label should be present on the ESC) https://docs.modalai.com/voxl-mini-esc-datasheet/#specifications [image: 1777179257146-aa7bc73c-90f7-41ae-9f28-cacb800c72eb-image.png] Alex

@boron Please submit an RMA, https://modalai.com/rma and just refer to this thread. Include your shipping information and we'll send you a new one

Hi @austin-c , You can find the latest M0138 firmware with regen completely disabled here Also, I added the esc config that i've been using for testing here For step tests, i have been using pretty aggressive step command: ./voxl-esc-spin-step.py --id 2 --rpm 2000 --step-amplitude 4000 --step-frequency 2.0 --timeout 2.0 --cmd-rate 2000 --enable-plot 1 In order to make the ESC not de-sync (due to long demag time of the motor), the following params were adjusted: max_rpm_delta set to 4000 (you can go lower), to cap the maximum rpm transitions. Although in my test, the step is 4000, so this had no effect timing_advance: 45 -- this is pretty high commutation advance to trigger commutation earlier so that there is more time for back-emf sensing -- high advance wiil reduce motor efficiency and will cause the motor to heat up a bit more sense_advance: 30 -- delay back-emf sensing so that we don't sample back-emf during the motor coil demagnetization more details : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md I had another thought.. What if you use a small battery to absorb the voltage spikes? Basically hook up a 6-7S battery with a beefy Schottyky diode (10A) set up with Cathode (negative) pointing to the battery. you will have to make sure the power supply voltage never exceeds battery voltage + diode drop. you will also need to make sure that you don't over-charge the battery with repeated spike absorption.. It is possible to have some sort of self-discharge circuit to slowly discharge the battery to a certain voltage (using a Zener diode + resistor or something similar). Anyway, just an idea.. Try out the no-regen firmware.. Alex

@sjt277 , The simplest approach is to use a separate USB-to-serial adapter for each ESC. You can set up udev rules to map and distinguish the specific usb-to-serial adapters (using their unique serial numbers) to aliases in /dev/, such as /dev/esc0, /dev/esc1, etc. Then run your testing using different USB devices to access each ESC (i am assuming you are using voxl-esc tools?). For example, here is some relevant information: https://askubuntu.com/questions/49910/how-to-distinguish-between-identical-usb-to-serial-adapters Does that help? Alex

Hi @Martin-Lukac , Thank you for the update. I am glad to see that your new tests went fine. As I mentioned before, i was quite surprised to see the ESC fail in such a way, which may suggest some kind of anomaly. I will provide a longer answer soon, but for now some quick notes: non-zero kp / ki parameters will speed up the ESC's RPM response. I will provide some examples you can test whether the ESC closed-loop controller is stable using voxl-esc tools, using step inputs, etc. if unstable, lower Kp. Then lower Ki to avoid slow overshoots. Ki will definitely not contribute to high frequency oscillations. assuming the ESC closed loop response is stable, if the Flight Controller is commanding noisy RPMs, the ESC with aggressive tuning (high kp) will try to track the noisy rpm commands, resulting in motor and ESC heating up. there are generally two main sources of oscillations: unstable attitude controller or vibrations / noisy gyro unstable attitude controller : characterized by lower frequency oscillations (in the range of 10-30Hz, depending on your frame, motors, etc) vibrations can result from drone frame twisting at the frequency of motor RPM, or loose flight controller board / IMU, if flight board is shock mounted, the connected wires can potentially carry vibrations or cause the board to flex due to the wires vibrating / moving (very quickly). These vibrations will be at the frequency of motor RPM. aggressive (high) values of ESC kp will amplify these vibrations, so you can end up in a situation when the ESC's closed loop RPM controller is feeding back and contributing to higher oscillations. by analyzing the gyro logs (will need to enable high rate logging), using FFT you can determine if your frame is mechanically unstable / noisy or the attitude controller is unstable. if you set kp and ki to 0, you still have the advantage of calibrated (and voltage-compensated) RPM control. However, the control will only have feed-forward term. So behavior will be close to response of a traditional ESC with added calibrated feed-forward rpm control with voltage compensation. regarding whether you need a bigger ESC.. it depends on the maximum total current that you plan to pull. The M0138 ESC has been tested with similar motor / prop combo (3110 motor, 900kV with a 10x4.5 tri-blade) . During bench testing, each motor could pull close to 40A at 6S, however in practice you are never going to have all 4 motors spinning at absolute maximum rpm (then you will not have any control margin for attitude). We have tested full punch-out flights for 100+ Amps for over a minute and the ESC was perfectly fine (airflow required for cooling). The mosfets on M0138 are rated for 100A+ continuous (each), so 40A continuous an issue. It will come down to the total current draw and cooling. For high power applications like this, you should definitely start at lighter loads and try to push the ESC to the limit. You will also need to worry about power connector(s) if you are drawing 100A+ continuously (battery connector may melt). px4 params: the min and max rpm params in px4 should match the min and max in your esc params. the px4 params do not override the limits in the esc params - the ESC will cap the incoming rpm commands if they are outside of the ESC params limits. Also, if you have incorrect px4 rpm limits, the thrust calculation in px4 will be incorrectly scaled from 0 to 100%, so you definitely want to get those rpm limits to be in sync between the ESC and px4. Also, you can use our custom version of flight-review to display additional data specific to our ESC (rpm commands, actual rpms, esc temps, etc) : https://github.com/modalai/px4-flight-review (you can run it locally in docker). Alex

@awagner , I think the main issue that started the failure mode was the spin-up type was set to 0 in params, which I do see that you got from the seeker_v1 xml file you mentioned. It is not your fault. The non-sinusoidal spinup is not as reliable and it is mostly not used any more. I will look at removing the old param files that use that option. Let me explain the reasoning behind using a larger ESC, especially during initial testing: the larger (FPV) ESC can handle much larger currents and dissipate a lot more heat, so it can handle much larger glitches, which could arise from mis-configuration during initial testing the ESC firmware does have some timeouts for protection, which generally do prevent fatal issues like this, but if the glitch results in enough current to quickly burn out a mosfet, the ESC cannot recover. The larger ESC (with larger mosfets and larger thermal mass will take longer to burn out, so the ESC's timeout / glitch detector should save it) larger motors in general have larger stall current, which would result in large current if there is some glitch during start-up. based on the numbers that you provided for the motor spec calculator (3.75A hover / 17A max), it should be possible to tune the mini ESC to work, however there are still some things to consider: may need to add more bypass capacitance to handle larger current transients if the motor is stalled (due to impact, etc), there is still a bit higher risk of ESC burning out due to stall detection being a bit too late. As for the xml to use as a starting point.. You can start with this one: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0020/m0138_3110_900kv_gemfan_10x4.5_tri.xml This is tuned for a 6S application 3110-size 900kV motor with a 10x4.5 tri-blade motor (pretty powerful configuration). You will need to update: voltage (6s to 4s) motor params (kv, rpm curve, etc) you can set the timing advance and sense advance from 20 to 0 (your application is likely not aggressive enough to require tweaking that), although you can do some bench testing to determine if you encounter de-syncs during large rpm transitions : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md you may need to adjust the spinup power / latch power -- generally keep it between 70-100 (7-10%) but when i tune this, i also usually find the minimum spin-up power that is able to reliably spin up the motor and then add a 10% extra (so 70->80). You can set spin-up power to a higher value in sinusoidal spin-up mode and it will produce a lot more torque, but will also consume more current. I usually try to limit a per motor spin-up current to 1-2 amps as a rule of thumb. for a fixed prop (not folding), your spin-up time can be anywhere between 500-1000ms, you can experiment. If you see the motor skipping during spinup and re-starting, you can increase either spin-up time or spinup power. may want to re-enable start-up beeps (disabled in this config) you can set kp (proportional gain) to 50 first (softer), then bump up to 100 or so, as you build confidence. higher kp will result in snappier response (faster than traditional ESCs without rpm control) but will also draw more current during transitions. (with M0138, you should not need to add more bulk capacitance to ESC power). With correctly tuned sinusoidal spin-up procedure, it should work pretty much 100% of the time (spin up on the first try every time). If you are seeing some inconsistent spin-up behavior, then it is possible there is some parameter issue and it needs to be investigated. When you get your M0138, i suggest updating the params per my notes above and doing some bench testing using voxl-esc tools where you just spin up and stop motors many times in a row and make sure the spin-up is reliable. Please let me know if you have any other questions! Alex

@Alex-Kushleyev Thanks for detailed information and analysis. I am going ahead with further testing with this ESC as per your suggestion. I have changed my propulsion system as follows: Emax Eco II seroes 2306 2400kv motor, propeller Gemfan 5177 and 15000 mah 4S battery. Here is my file with ESC calibration : https://drive.google.com/file/d/1uzbx9MGwF1EvRqJx6tXBqqc-j3XZSgu_/view?usp=sharing All the motor directions are checked and they are correct as per airframe reference. My UAV is able to takeoff a bit but at around 0.5 meters it again decreases its altitude and then after scratching the surface is flipping over. Here is the logs : https://review.px4.io/plot_app?log=08691d7d-887d-41d8-b00d-d543febeea59 Can you spot is my ESC configuration wrong or anything I am missing in PX4 configuration? This flip happened twice in a row and all motor direction are verified to be correct since UAV is able to takeoff. Also any advantage of RPM vs PWM control in VOXL ESC PX4 parameter setup? Also my voxl2 is unpside down so I have set ROLL_180 in Autopilot orientation, but is this creating some problem anywhere is unknown since I can see yaw reset EKF2 estimator flag set as soon as I takeoff.

@schew The ESC states are as follows: 0: idle / not spinning or trying to spin 1: spinning up 2,3: unused 4: very brief transition between spin-up and full back-emf sensing mode (user's commands are not yet executing) 5: back-emf sensing mode (rpm or power control based on user's command) If there is any issue that causes ESC to think it's stalled or communication timed out, it will go through state 0 and then to 1 if non-zero commands are sent via UART. The typical start-up sequence is basically 0->1->4->5 and should stay at 5 until you send a zero command or stop sending commands.

@mkriesel , a few tips.. I suspect FETtec ESC is using a pretty accurate xtal or accurate RC oscillator, so you should not need to calibrate the ESC You can check the current calibration by using QGC to control the individual motors to see at which command they start up and make sure that is very close to the same (typically around 1000us or a bit more) Additionally, you can spin up each motor with propeller at certain % power, lets say 20% or 30% and using an optical tachometer (RPM meter) to measure the speed of each motor Those are some sanity checks you can do without being able to calibrate and without having any ESC telemetry. Regarding the ESC PWM range, the procedure is documented for VOXL2 IO board : https://docs.modalai.com/voxl2-io-user-guide/#how-to-perform-esc-calibration -- please go over that and make sure you did it correctly. Alex

@박지현 Unfortunately, for Ardupilot, our ESCs are only supported with UART interface when using the VOXL 2 / VOXL 2 mini as the flight controller. When using Flight Core v2 that is not supported.

Hello @LV-Office-Holder, The M0138 racing ESC only has two I/O pins and they are used for aux PWM output. PWM input is disabled for this ESC due to lack of PWM input for each ESC channel. The ESC protocol example can be found here : https://gitlab.com/voxl-public/support/esc-driver as well as part of PX4 implementation : https://github.com/modalai/px4-firmware/tree/voxl-dev/src/drivers/actuators/voxl_esc . I would suggest referencing the PX4 implementation since it has the latest updates. Additionally, we have voxl-esc test tools (python) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc . The test tools allow you to spin motors, plot data, perform firmware and parameter updates. Please let me know if you have any other questions. Alex

Here are the links to the test firmware: M0129-3 M0129-6 After you update, you should see the following version after running voxl-esc-scan.py (except yours will be M0129-6). The firmware version will be 39.23 and this version will be reserved only for this test firmware: INFO: ESC Information: INFO: --------------------- ID : 0 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555304003F0029 Firmware : version 39.23, hash 30c088dc Bootloader : version 184, hash 10bf24c8 ... In case you need help updating ESC firmware: https://docs.modalai.com/voxl-escs/faq/#q-how-do-i-update-esc-firmware We won't officially release this firmware version in order to avoid the aforementioned risk of turning on 5.0V by just installing a firmware update, however we will work on enabling this in the ESC params. Also, just as a reminder, please be careful soldering to the AUX test points, use high quality flexible cables, and use strain relief to avoid lifting the pads. Alex

@Vinny Yes, thank you very much!

We have updated the M0129 in the past few months to support 2S-6S, it looks like the datasheet is out of date. Thanks for pointing that out. If it is marked M0129-63 or M0129-65 it supports 6S M0129-3 and M0129-5 are the older version and they only go up to 4S

Hello @Aaky , If you have a new motor / prop, please follow these instructions for initial tuning : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md?ref_type=heads We don't have this specific motor / propeller combo, but if you send a link where I can purchase these, I would be happy to do a tuning pass and some testing for you. Alex

@tomverstappen , I am glad you got this resolved. The "unknown board" message you were receiving was due to the older release of voxl-esc package, which did not recognize (and did not have firmware for) the M0129-6 ESC, which is the 6S-compatible version of the M0129 ESC. I hope this clarifies that issue. Alex