Uav toolbox VTOL Ref.App Plant model with PX4 Sitl

Hi. ı am trying to run Vtol plan model of Mathworks wıth PX4 sitl. I am taking HIL_ACTUATOR_CONTROL[16] array and using first 4 elements of it to conrol rotor of vtol. But when i observe the reponse of plant it was so late after i sent manual command from QGC. Almost seconds later and after a while uav will be out control and behaves independently from my commands. There is a big communication problem. How can solve that?

Thanks

[AbdulKadir]

[Umar]

Hi @AbdulKadir, thanks for your message. To better assist you, could you please provide a few more details?

• What version of PX4 and MATLAB/Simulink are you using?

• Are you running the SITL simulation on the same machine as Simulink, or are they on separate systems?

• What is the communication interface you're using (e.g., UDP, serial)?

• How exactly are you connecting and sending actuator commands from Simulink to PX4?

• Are you observing any delay or packet loss logs in PX4 or Simulink?

From your description, it sounds like a possible communication bottleneck or synchronization issue between Simulink and PX4 SITL, but more context would help narrow it down.

Looking forward to your response so we can help you troubleshoot further!

[AbdulKadir]

Hi Umar thank you very much for assisting.

I am running with PX4 v1.14.0.3 and MATLAB 2025B. (I hav aslo tried PX4 v1.15)

MATLAB and QGC runs in Windows, PX4 runs in WSL2.

As a interface i am using Kiril Boychev's model: https://www.mathworks.com/matlabcentral/fileexchange/114320-pixhawk-software-in-the-loop-sil-connector-for-simulink. So it connects via TCP 4560 and runs lockstep well. When i try to use UDP there were timeouts and other errors.

I have also used Simulink's TCP Send and recieve and server block. It shows timestamp error but allow me to arm vehicle. And they work good but same problem appeared. In this way i used MAVLink serializer and deserializer blocks, they works good i think.

As a third option used Michael Skadan's interface which use UDP, it show timestamp errors but allow to arm, but again same problem appeared.

I observe a big delay when i commanded on QGC, after a while plants shows behaves like it took commands again without i command it via QGC. And it begins turn around itself.

Because of model and px4 sitl show same behaviour with different interfaces, i think the problem is somewhere else.

I dont know how can i observe packet loss in TCP communication in Simulink-PX4 Simulink.

My model runs in 0.004s sample time. Plant model run as continuous. After i connect to px4 sitl and QGC, i observe in MavLink tab of QGC frquency of messages getting lower but in a case that frequiencies are high i have also saw same contol problem affected to plant.

[Umar]

Hi @AbdulKadir,

Thank you for reaching out. I've thoroughly researched your PX4 v1.14.0.3/v1.15 SITL + MATLAB 2025B issue with the VTOL plant model, and I've identified the root causes of the delayed response and erratic vehicle behavior you're experiencing. After examining your setup as shown in attached screenshots and reviewing MathWorks documentation, PX4 resources, and the interfaces you've tried (Kiril Boychev's connector, Simulink TCP blocks, and Michael Skadan's UDP interface), I can confirm your suspicion: the problem isn't the interface—it's fundamental configuration issues affecting all three approaches. You're experiencing classic lockstep synchronization failure combined with WSL2 networking problems. This explains why: * Commands take "almost seconds" to respond * The vehicle behaves independently and spins uncontrollably * Message frequencies drop in QGC's MAVLink Inspector * All three interfaces show identical symptoms

So, basically there are three critical problems

WSL2 Network Configuration (CRITICAL!) When PX4 SITL runs in WSL2 and MATLAB/QGC run in Windows, you cannot use localhost (127.0.0.1) for TCP connections. Windows applications must connect to WSL2's ethernet adapter IP address.

Fix:

In WSL2 terminal:

# Find your WSL2 IP address
ip addr show eth0 | grep inet
# Example output: inet 172.31.64.1/20

# Use this IP in your MATLAB TCP blocks instead of 127.0.0.1

In Windows Firewall: * Create inbound rules for TCP port 4560, UDP ports 14540 and 14550

In Simulink TCP blocks:

   tcpAddress = '172.31.64.1';  % Your actual WSL2 IP, NOT 127.0.0.1
   tcpPort = 4560;

This alone may be causing most of your delay issues, as packets are being routed through WSL2's network translation layer with significant latency.

Missing Simulation Pacing Your Simulink plant model is running as fast as possible without pacing, while PX4 lockstep expects real-time synchronized sensor updates. This causes timing drift and desynchronization.

Fix: In your plant model: * Go to Simulation > Pacing Options * Enable "*Enable pacing to slow down simulation*" * Set pacing rate to 1.0 (real-time)

Or programmatically:

set_param('your_plant_model', 'EnablePacing', 'on');
set_param('your_plant_model', 'PacingRate', '1.0');

Sample Time and Solver Configuration

Running your plant as continuous with a 0.004s discrete interface creates interpolation issues and timing jitter.

Fix:

% Model configuration:
set_param('your_model', 'SolverType', 'Fixed-step');
set_param('your_model', 'FixedStep', '0.004');  % 250 Hz

% Plant subsystem: Change from continuous to discrete
% Sample time: 0.004 (explicit, not inherited)

Some additional required checks along with that I will recommend

HIL_SENSOR Message Completeness

Your HIL_SENSOR messages must include ALL required fields with proper   
 timestamps:

% Critical fields that must be present:
hil_sensor.time_usec = monotonic_timestamp;  % Must increment by 4000 
each step
hil_sensor.xacc, yacc, zacc  % Accelerometer (m/s²)
hil_sensor.xgyro, ygyro, zgyro  % Gyroscope (rad/s)
hil_sensor.xmag, ymag, zmag  % Magnetometer (Gauss)
hil_sensor.abs_pressure  % Barometric pressure (hPa)
hil_sensor.pressure_alt  % Altitude from pressure (m)
hil_sensor.temperature  % Temperature (°C)
hil_sensor.fields_updated = uint32(127);  % Bitmask: 0x7F = all fields valid

The timestamp must be monotonically increasing by exactly 4000 microseconds per step. Any gaps, reversals, or incorrect increments will break lockstep.

HIL_STATE_QUATERNION Message

You also need to send vehicle state updates:

hil_state.time_usec = same_timestamp_as_sensor;
hil_state.attitude_quaternion = [q0, q1, q2, q3];
hil_state.rollspeed, pitchspeed, yawspeed  % rad/s
hil_state.lat, lon, alt  % Position (scaled: lat/lon *1e7, alt in mm)
hil_state.vx, vy, vz  % Velocity (cm/s)
hil_state.xacc, yacc, zacc  % Accelerometer (mg)

Here are debugging steps

1. Verify WSL2 IP connectivity first:
# In WSL2, start PX4: 2. cd ~/PX4-Autopilot 3. make px4_sitl none 4. # In Windows MATLAB, test TCP connection to WSL2 IP 5. Add diagnostic logging in Simulink: * Log timestamps sent in HIL_SENSOR messages * Log time intervals between received HIL_ACTUATOR_CONTROLS * Check for TCP send/receive errors 6. Verify timing after simulation:
time_diffs = diff(timestamps_sent); 7. % Should consistently equal 4000 microseconds 8. actuator_intervals = diff(actuator_receive_times); 9. % Should be ~4ms (250 Hz), not seconds 10. Check QGC MAVLink Inspector: * Look for HIL_SENSOR frequency (~250 Hz) * Verify ATTITUDE, GLOBAL_POSITION_INT rates (~50 Hz) * Check for dropped messages or rate degradation

If you continue experiencing issues, I strongly recommend switching to the official MathWorks UAV Toolbox approach, which handles all timing, lockstep, and message formatting automatically:

1. Install UAV Toolbox Support Package for PX4 Autopilots 2. Use two separate MATLAB instances: * Instance 1: Controller on PX4 Host Target * Instance 2: Plant model with simulation pacing 3. Follow the official example:openExample('px4/MonitorTunePX4HostTargetFlightPlantModelExample') This approach is specifically designed for your use case and eliminates manual timing management. Once properly configured, you should see:

• Immediate response to QGC commands (<100ms latency)
• Stable control throughout the flight with no autonomous spinning
• Steady message rates in MAVLink Inspector
• Successful arming without timestamp errors
• Proper vehicle dynamics matching your commanded inputs

Next Steps

I recommend addressing these issues in order: 1. Fix WSL2 networking (highest priority—likely causing most of your delay) 2. Enable simulation pacing 3. Convert plant to fixed-step discrete 4. Verify HIL message completeness 5. Add diagnostic logging to confirm timing

Please let me know which interface you'd like to continue with, and I can provide more specific implementation details for that particular connector. All three interfaces should work once these fundamental issues are resolved.

The fact that you're seeing identical behavior across all three interfaces confirms this is a timing/configuration problem, not an interface bug—which is actually good news, as it means the solution will work regardless of your interface choice.

Additional Resources:

• MathWorks PX4 SITL Integration

• PX4 Simulation Architecture

• MAVLink HIL Message Specs

[AbdulKadir]

Hi Umar thank you your rapid response and support.

1. Since beginning i connect the WSL2 to simulink with its IP adress and pacing option also.
2. When i look pxh output to listener sensor combined i show 4000mikrosec so 250 Hz.

In Michael Skadan´s interface i experienced timestep loss issue but with Kiril Boychev´s interface it works lockstep. But it shows in QGC low frequencies 10-20 Hz NOT 50 Hz. And there is no HIL_SENSOR AND HIL_GPS message names but the messages that can bee seen in the picture below.

The model have all the messages that you mentioned in your response except hil_state.attitude_quaternion = [q0, q1, q2, q3];.

But in a vVTOL plan model and quadcopter example which is come with Kiril Boyche´s interface also dont have quaternions but Euler angles. So i think it dont cause any problem.

Since i am using S-Func interface, not TCP send-receive blocks i dont know how can i log and show diagnostics. But i am working on it.

[AbdulKadir]

Below there are some images show that after i armed the uav the rotor commands change between 0-1 like a square wave. Then i command it to take off in Manual mode it behaves independently from my commands and takes nearly every value between 0 and zero.

[AbdulKadir]

When I look to sample time of model I saw there is some blocks runs in continuous but these blocks are part of 6DOF and Force blocks. And when i change the sample time to non-continuous it gives error. But in Kiril Boychev´s interface Quadcopter example these blocks worked in continious but didnt give any error also.

***And I dont know if I can use with PX4 Support package SITL simulation not HITL. Because I dont have Pixhawk hardware and in the User Guide I only saw hardware in the loop simualtion and Serial COM5 communication way. I will be very appreciate if you can inform me.

It is like after I give an rotor input command to UAV there will be second commander and my inputs are being secondary.

Thank you again for your support!

[Umar]

Hi @Abdulkadir,

That is good. You made some progress. Now, after going through your screen shots and comments, the caveat is Kiril’s S-func runs in lockstep but PX4 still sees low message rates. That usually means timing or message format mismatch, not network delay.

Try this next:

1. Run `listener sensor_combined` and `listener actuator_controls` in PX4 — check actual update rates (should be ~250 Hz). 2. Make sure `time_usec` increases exactly by 4000 µs each step and `fields_updated = 127`. 3. PX4 expects `HIL_STATE_QUATERNION`; Euler-only messages can cause drops. Try converting to quaternion before sending. 4. Log what your S-func sends (timestamps, attitude, accel, gyro) and compare with what PX4 reports. 5. If you still see 10–20 Hz, post a short `listener` dump and MAVLink Inspector screenshot — likely a field or scaling mismatch.

Let me know after going through these steps.

[AbdulKadir]

Hi Umar. Thanks again for your response.

When i run simualtion i dont know whay but frequencies change between 30-50 Hz. But i couldnt take a response when i write listener actuator_controls command to pxh. Is something missing?

dt=4000mikrosec i think it corresponds to 250Hz. Same error continuous again.

--------------------sensor_combined

pxh> listener sensor_combined

TOPIC: sensor_combined

sensor_combined

timestamp: 687612000 (0.000000 seconds ago)

gyro_rad: [-16.21060, -12.10875, -14.12814]

gyro_integral_dt: 4000

accelerometer_timestamp_relative: 0

accelerometer_m_s2: [-1.66517, 0.68474, -15.94180]

accelerometer_integral_dt: 4000

accelerometer_clipping: 0

gyro_clipping: 0

accel_calibration_count: 0

gyro_calibration_count: 1

pxh>

------------------actuator_controls

pxh> listener actuator_controls

Topic actuator_controls did not match any known topics

Command 'listener' failed, returned -1.

pxh> listener actuator_controls

Topic actuator_controls did not match any known topics

Command 'listener' failed, returned -1.

pxh> listener actuator_controls_0

Topic actuator_controls_0 did not match any known topics

Command 'listener' failed, returned -1.

pxh> listener actuator_controls_1

Topic actuator_controls_1 did not match any known topics

Command 'listener' failed, returned -1.

[AbdulKadir]

I also saw same response of rotor commands in a Quadcopter example which works properly. So i guess the response is normal but behaviour of Uav to this commands are not suitable, they make uav move and turn around itself. I tried to change rotation direction of rotors but it didnt worked.

[Umar]

Hi @AbdulKadir,

Let me think about this little more carefully, I will have response in few hours.

[AbdulKadir]

Sure, thanks so much Umar!

[Umar]

Hi @AbdulKadir,

Thanks for your patience. Let me walk through each of your observations step by step.

Comment #1: Understanding the actuator_controls Topic Issue

You're getting "Topic actuator_controls did not match any known topics" because this topic doesn't exist in the way you're trying to access it.Here's what's actually happening: In PX4's uORB messaging system, actuator_controls isn't a standalone topic you can listen to directly. Instead, you need to listen to one of these topics:

For HIL/SITL simulation (which is what you're running):

listener actuator_outputs_sim

For general actuator outputs:

listener actuator_outputs

The actuator_outputs_sim topic is specifically designed for SITL, HITL, and SIH (Simulation-In-Hardware) with an output range of [-1, 1], which matches what you're seeing in your rotor commands. This is documented in the PX4 uORB message reference: https://docs.px4.io/main/en/msg_docs/ActuatorOutputs.html

So try running:

   pxh> listener actuator_outputs_sim

This should show you exactly what PX4 is commanding to your motors in real-time. If you see the same 0-1 oscillations here that you're seeing in your Simulink model, then we know the problem is on the PX4 controller side, not in your plant or interface.

Comment #2: Your MAVLink Message Frequencies (30-50 Hz)

Looking at your QGC MAVLink Inspector screenshot, I can see: * ALTITUDE: 1.0 Hz * ATTITUDE: 40.2 Hz * ATTITUDE_QUATERNION: 40.2 Hz * ATTITUDE_TARGET: 40.2 Hz * GLOBAL_POSITION_INT: 39.4 Hz

This is completely normal. These are telemetry stream rates to QGC, not your internal simulation rates. Here's why: 1. Your internal PX4 simulation is running at 250 Hz (confirmed by your sensor_combined dt of 4000 microseconds) 2. Your HIL sensor updates from Simulink are also at 250 Hz (confirmed by the same dt) 3. But telemetry to QGC is intentionally downsampled to save bandwidth - attitude at 40 Hz, position at 40 Hz, and low-priority messages at 1 Hz

This is by design. PX4 doesn't send every internal update to QGC because: * It would overwhelm the MAVLink connection * QGC's UI only updates at 30-60 fps anyway * Bandwidth is limited, especially on radio links

So don't worry about the 30-50 Hz you're seeing in QGC - your simulation is still running at full 250 Hz internally.

Comment #3: CRITICAL Discovery in Your Sensor Data I noticed something very important in your sensor_combined output: gyro_rad: [-16.21060, -12.10875, -14.12814] accelerometer_m_s2: [-1.66517, 0.68474, -15.94180]

These gyro rates are extremely high! Specifically: * Roll rate: -16.2 rad/s ≈ -928 degrees/s * Pitch rate: -12.1 rad/s ≈ -693 degrees/s * Yaw rate: -14.1 rad/s ≈ -808 degrees/s

This means your vehicle is already spinning violently in your simulation, even before you command it to take off. A stable vehicle sitting on the ground (or hovering steadily) should show gyro rates close to zero, maybe ±0.1 rad/s at most.This confirms what you're experiencing - the "turning around itself" behavior. The vehicle is genuinely out of control, and these sensor readings prove it. The question is: why?

Comment #4: The Rotor Command Oscillations - This is Your Real Problem

You made a critical observation: "I also saw same response of rotor commands in a Quadcopter example which works properly. So i guess the response is normal but behaviour of Uav to this commands are not suitable"

You're absolutely right. If the quadcopter example shows similar command patterns but flies correctly, while your VTOL doesn't, then the issue is not the commands themselves - it's how your plant is responding to those commands. Combined with those massive gyro rates, this points to one primary issue: motor configuration mismatch.

Comment #5: "I tried to change rotation direction of rotors but it didn't work"

This is a crucial clue. Let me explain exactly what needs to be changed and why simply "reversing" motor direction often doesn't work: The Standard Quadcopter X Configuration:

• Motor 1 (front-right): Counter-clockwise
• Motor 2 (front-left): Clockwise
• Motor 3 (rear-left): Counter-clockwise
• Motor 4 (rear-right): Clockwise

What You Must Change in Your Simulink Plant Model:

When changing motor rotation direction, you need to modify TWO things simultaneously, not just one:

1. Thrust Vector (usually already correct):

% For all motors, thrust always points downward in body frame
Thrust_vector = [0; 0; -Thrust_magnitude];

2. Reaction Torque (this is what you probably missed):

% For CCW motors (1 and 3):
Torque_reaction = +K_torque * Thrust_magnitude;  % Positive = CCW

% For CW motors (2 and 4):
Torque_reaction = -K_torque * Thrust_magnitude;  % Negative = CW

The reaction torque is applied about the motor's axis (vertical Z-axis in body frame). This torque acts on the vehicle body in the opposite direction of the propeller spin.

Common mistake: People change the thrust vector direction or reverse the motor ordering, but forget to change the sign of the reaction torque. This causes exactly the spinning behavior you're seeing.

How to Verify Your Motor Configuration: In your Simulink plant model, find the section where motor forces and torques are applied to the 6DOF block. For each motor, verify:

Motor 1 (Front-Right): Position: [+L, -L, 0] % L = arm length Thrust: [0, 0, -T1] Torque: [0, 0, +K*T1] % Positive for CCW

Motor 2 (Front-Left): Position: [+L, +L, 0] Thrust: [0, 0, -T2] Torque: [0, 0, -K*T2] % Negative for CW

Motor 3 (Rear-Left): Position: [-L, +L, 0] Thrust: [0, 0, -T3] Torque: [0, 0, +K*T3] % Positive for CCW

Motor 4 (Rear-Right): Position: [-L, -L, 0] Thrust: [0, 0, -T4] Torque: [0, 0, -K*T4] % Negative for CW

Where K is your motor torque constant (typically 0.01 to 0.05 for small quads). If your torque signs don't match this pattern, that's why the vehicle spins uncontrollably.

Now some additional potential issues to consider

1. Motor Command Mapping

Verify that HIL_ACTUATOR_CONTROLS array indices map correctly: * HIL_ACTUATOR_CONTROLS[0] → Motor 1 (front-right) * HIL_ACTUATOR_CONTROLS[1] → Motor 2 (front-left) * HIL_ACTUATOR_CONTROLS[2] → Motor 3 (rear-left) * HIL_ACTUATOR_CONTROLS[3] → Motor 4 (rear-right) If these are swapped, even with correct torque signs, the vehicle won't fly correctly.

2. Thrust Scaling The actuator_outputs_sim outputs values in range [-1, 1]: * -1.0 = Full reverse thrust * 0.0 = No thrust * 1.0 = Full thrust

Your plant must map these to actual thrust. For most multirotors:

% Correct mapping:
Thrust_N = max(0, actuator_command) * Thrust_max;

% Or with quadratic relationship (more realistic):
Thrust_N = (max(0, actuator_command))^2 * Thrust_max;

If you're using a linear relationship when you should use quadratic, or vice versa, the controller gains will be mismatched.

3. Moments of Inertia

VTOL aircraft have different mass distributions than pure quadcopters. Your 6DOF block needs realistic inertia values:

% Typical small VTOL in quad mode:
Ixx = 0.01 to 0.05 kg⋅m^2 % Roll inertia
Iyy = 0.01 to 0.05 kg⋅m²^2 % Pitch inertia  
Izz = 0.02 to 0.08 kg⋅m^2 % Yaw inertia (usually highest)

If these are way off, the vehicle will respond too sluggishly or too aggressively.

So, here is summarized version of answers to your questions

1. "Is something missing with actuator_controls?"
No, nothing's missing. The topic name changed in newer PX4 versions. Use: listener actuator_outputs_sim This is the correct topic for SITL/HIL simulation and will show you the actual motor commands PX4 is sending.

2. "Why do frequencies change between 30-50 Hz in QGC?"
This is completely normal and expected. Those are just telemetry rates to QGC (downsampled to save bandwidth). Your internal simulation loop is still running at the full 250 Hz - confirmed by your sensor_combined dt of 4000 microseconds. No issues here.

3. "Same error continuous again"
The continuous blocks in your 6DOF dynamics are perfectly fine - don't change them. Those blocks represent physical dynamics which are naturally continuous. Only your interface blocks need to be discrete (0.004s), which you already have correct.

4. "Can I use PX4 Support Package for SITL without hardware?"
Yes, absolutely! Use "PX4 Host Target" mode - it runs PX4 SITL on your computer with no Pixhawk hardware needed. The UAV Toolbox Support Package specifically supports this. Try the MathWorks example: openExample('px4/MonitorTunePX4HostTargetFlightPlantModelExample') Or search for "Monitor and Tune PX4 Host Target with Simulink Plant Model" in MATLAB documentation.

5. "UAV behavior to commands is not suitable - spinning/uncontrolled"
Based on your massive gyro rates (-16 rad/s) and your observation that the quadcopter example works with similar commands, the problem is definitely in your plant model configuration. Most likely causes in order of probability:

1. Motor reaction torque signs are wrong (most common issue) 2. Motor position/ordering is incorrect 3. Thrust scaling doesn't match controller expectations 4. Inertia values are unrealistic 5. Wrong PX4 airframe/mixer configuration

So, please perform the following in order

Step 1: Verify What PX4 is Commanding pxh> listener actuator_outputs_sim Run this while commanding takeoff in QGC. Tell me: * Are the values smooth and reasonable (0.4 to 0.7 range for hover)? * Or are they oscillating wildly (0→1→0 square waves)? If they're smooth but your plant still spins, the problem is definitely in your plant. If they're oscillating, the problem is in PX4's controller tuning.

Step 2: Check Your Airframe Configuration pxh> param show SYS_AUTOSTART VTOL airframes should be: * 13xxx for Standard VTOL (QuadPlane) * 14xxx for Tailsitter VTOL * 15xxx for Tiltrotor VTOL If you're using 4xxx (standard quad), you need to change this. The mixer and control allocation will be wrong.

Step 3: Double-Check Motor Torque Signs

In your Simulink plant model, find where you apply motor torques to the 6DOF block. Print or log the torque values. Verify:

• Motors 1 and 3 (front-right, rear-left): Positive torque about Z-axis
• Motors 2 and 4 (front-left, rear-right): Negative torque about Z-axis If any of these are wrong, fix them immediately. This is almost certainly your issue.

Step 4: Compare with Working Quadcopter Example

Since you have Kiril Boychev's working quadcopter example: 1. Open that model 2. Find the motor torque application section 3. Note the exact torque signs and motor ordering 4. Compare with your VTOL plant 5. Make yours match exactly

Step 5: Test with Reduced Gains (Temporary Workaround) While you're debugging, you can reduce PX4's controller aggressiveness to make the vehicle more stable:

pxh> param set MC_ROLLRATE_P 0.05   # Default is usually 0.15
pxh> param set MC_PITCHRATE_P 0.05
pxh> param set MC_YAWRATE_P 0.1
pxh> param save

This won't fix the root cause, but it might make the vehicle controllable enough to test other things.

Given the complexity you're facing with manual MAVLink message handling and plant configuration, I strongly recommend switching to the official MathWorks UAV Toolbox approach. Here's why:

Current approach (manual): * You manually handle all MAVLink messages * You manually ensure timing synchronization * You manually configure motor mixing * You manually debug control issues * Any mismatch causes mysterious failures

Official UAV Toolbox approach: * Automatic MAVLink message handling * Built-in timing synchronization * Pre-configured motor mixing for standard vehicles * Better diagnostic tools * Works with PX4 SITL (no hardware needed)

The toolbox's "PX4 Host Target" mode is specifically designed for your exact use case - running PX4 SITL with a custom Simulink plant model. It eliminates 90% of the integration headaches you're experiencing.

To get started: 1. Install UAV Toolbox Support Package for PX4 Autopilots 2. Run: openExample('px4/MonitorTunePX4HostTargetFlightPlantModelExample') 3. Follow the example to connect your VTOL plant model 4. The toolbox handles all timing, messaging, and synchronization automatically Documentation: https://www.mathworks.com/help/supportpkg/px4/

Here is What I need from you To help diagnose this further, please share:

*Output of listener actuator_outputs_sim during a takeoff command (screenshot or copy-paste)

*Value of SYS_AUTOSTART parameter

*A screenshot or scope plot showing your 4 motor command values over 5-10 seconds

*If possible: The section of your Simulink model where motor torques are applied to the 6DOF block (just that subsystem, not the whole model)

With these pieces of information, I can pinpoint exactly which motor(s) have the wrong configuration and give you the precise fix.

Looking forward to hearing what you find! We're getting close to solving this - the sensor data tells us exactly what's wrong (vehicle spinning wildly), we just need to find which motor configuration is causing it.

P.S.- That -16 rad/s gyro rate you're seeing is actually helpful for debugging. When you fix the motor configuration, you should immediately see those rates drop to near-zero when the vehicle is sitting on the ground. That's how you'll know you've fixed it.

[AbdulKadir]

Hi Umar! I am grateful to you for this detailed response! I will try what you advise and write the results here.