I received [ReadyToSky SimonK 30A ESCs](Readytosky Simonk 30A Electronic Speed Controller as part of a PiHawk drone kit.
I’m wondering if the hardware has capabilities like Active braking, reverse operation, etc. Wondering if anybody had specsheets or a strong reason why or why not.
Thank you,
Joe
The specs do not list those features, so I doubt it. You could always ask them directly.
That’s what I figured, thanks for the confirmation. I’ve ordered a modern ESC, and anticipate designing a custom flight mode in Ardupilot for agile turning research. The included Pixhawk 2.4.8 is seemingly bottlenecked for off-board communication, otherwise I would just run occasional control injection off-board and stream rotor speed commands from the companion computer to the ESCs at 400hz. Granted there would be integral windup involved, so it seems like a custom flight mode is the best choice without changing the FC hardware/firmware.
Do you have any experience or recommendations regarding this Jax?
Once again thanks for replying to the original post.
This is not in my wheelhouse. But it is an interesting problem to read about.. I am sure you already used AI to give you some feedback, but for the benefit of other forum readers, I can summarize what I found from Gemini AI.
In flight controller firmware (like ArduPilot or PX4), the “fast loop” (sometimes called the main loop or primary control thread) is the core, high-priority software cycle that handles the immediate, real-time stability of the aircraft.
SENSORS > FILTERING > CONTROL (PID) > ACTUATION
ArduPilot’s fast loop runs inside Copter::fast_loop(). For an older FMUv2 board, this typically clocks at 400Hz by default (SCHED_LOOP_RATE).
The Pixhawk 2.4.8 uses an older processor (designed back in the early 2010s). Trying to push 400 packets of data every single second across that serial connection is like trying to force a firehose of data through a drinking straw. The Pixhawk’s processor gets overwhelmed just handling the data transfer, resulting in dropped packets, timing delays (jitter), and potential crashes.
The Pixhawk 2.4.8 STM32F427VIT6 main processor runs on an ARM Cortex-M4F architecture.
When you write a custom flight mode class (like ModeAgileTurn), ArduPilot automatically executes your custom run() function inside this fast loop. This gives the exact 400Hz update needed without overloading the processor with communication overhead.
The Windup Trap: During a violent, high-speed agile turn, the drone’s motors might physically maximize their power (saturate) trying to achieve the aggressive turn rate. Because the drone cannot instantaneously match the extreme command, error accumulates. The “I” (Integral) term keeps building up and “winding up” like a compressed spring.
When the turn ends, that wound-up “I” term causes the drone to aggressively overshoot the target, leading to violent wobbling or a crash.
Three ways to fix this in the custom code:
reset_I()) to instantly wipe out any old accumulated error before starting the turn.Even if the processor calculates the commands at 400Hz, it still has to physically send those signals to the ESCs. Modern ESCs use a digital protocol called DShot, which is incredibly fast and precise, but requires precise hardware timers inside the microchip.
Because the Pixhawk 2.4.8 is older hardware, its internal timers are shared across its output pins. Pushing high-speed digital DShot signals while the processor is already busy running the custom agile-turning math can overwhelm the chip.
Because it lacks dedicated, independent hardware drivers for every output pin, the main CPU has to manually manage the timing of these digital pulses using bit-banging or heavy DMA (Direct Memory Access) interrupts.
Every time a DShot packet is sent or a telemetry packet returns from the motor, it triggers an “interrupt.” This forces the CPU to instantly pause its current flight math, handle the motor signal, and switch back. At 400Hz across four or more motors, these constant interruptions add massive overhead.
If the drone starts skipping cycles (called loop slips), you will have to downgrade the signal type from digital DShot to high-speed analog PWM (Pulse Width Modulation) or OneShot125, which require less processing power.
To comfortably execute an internal 400Hz control loop , handle advanced state estimators (EKF3), and drive high-speed digital ESC protocols simultaneously without loop slips, you need a flight controller powered by an STM32H7 processor (running at 480MHz with a double-precision Floating Point Unit).
The optimal choices for this architecture are:
To match the 400Hz refresh rate calculated by the flight controller, you should discard traditional analog PWM and use a modern DShot capable electronic speed controller. A high-performance 4-in-1 ESC running modern 32-bit architecture allows for ultra-low latency, bidirectional communication, and rapid regenerative braking.
When moving your agile turning research to the suggested H7 hardware running ArduPilot, you can move past baseline workarounds and directly utilize the following firmware code adjustments:
MOT_PWM_TYPE = 6 (DShot600) and enable the underlying timer masks. This forces the ESCs to stream precise, hardware-measured motor RPM data directly back to the flight controller over the DShot telemetry lines. You can feed this real-time motor speed matrix directly into your custom flight mode calculations to verify true physical rotor acceleration versus commanded rates.AC_AttitudeControl files, inherit a new class within the AP_Motors library. Write a specialized function such as output_custom_agile_matrix(). This allows you to directly manipulate individual motor channels via code while ensuring ArduPilot’s core health-monitoring and failsafe loops remain fully active in the background.SCHED_LOOP_RATE up to 800Hz. This allows your custom algorithm to poll sensors and push fresh actuator commands at double your planned speed, completely removing timing jitter from your transient data sets.When connecting an FMUv6X architecture board (like the Pixhawk 6X) to a 32-bit ESC (like the Foxeer Reaper or T-Motor P60), you must utilize the I/O PWM Out or FMU PWM Out ports to map your DShot lines correctly to the hardware timers.
The schematic below maps out the direct interface between the Pixhawk 6X Standard Baseboard and a high-rate 4-in-1 ESC.
FMU PWM OUT rail and the ESC signal port. At 400Hz–800Hz DShot frequencies, high-power switching transients from the main battery leads can distort the digital logic unless a dedicated signal ground return pathway is pinned out.TLM pin from the ESC transmits asynchronous serial data at 115,200 baud. Route this directly to the RX pin of an open telemetry port on the Pixhawk (e.g., Telem 2). This delivers real-time per-motor RPM, voltage, and current arrays back into ArduPilot’s memory.To initialize this specific high-speed digital architecture, you will need to push the following adjustments through your Ground Control Station parameter tree:
Once this hardware pipeline is wired up, you don’t have to guess if the motors are keeping up with your custom flight loop. You can poll the filtered RPM feedback directly inside your custom flight mode (mode_agile_turn.cpp) using the underlying AP_ESC_Telem library:
/////////////////////////////////////////////////////////////////////////////////////////////////////
To execute rapid maneuvers with zero float and instantaneous direction reversals, you do not need specialty custom hardware. The physical hardware required is already present in standard 32-bit brushless ESCs. Active braking and reverse rotation are handled at the hardware level by the MOSFET gate drivers and microcontrollers on the ESC, controlled via specific firmware settings.
In older or simpler ESCs, cutting the throttle causes the motor to “freewheel,” meaning the propellers spin down slowly due to air resistance. For agile turning research, this introduces lag.
Modern 32-bit hardware handles this through Damped Light mode (often integrated automatically into modern ESC firmware packages):
To reverse a brushless motor, the ESC must instantly change the electrical commutation sequence driving the three motor phases.
