navigation communication SITL Pixhawk simulation

SITL on Pixhawk Cube Orange: Deployment, Troubleshooting, and Calibration

1. Introduction

In this resource, we share our experience with setting up Software-In-The-Loop (SITL) on actual hardware using the Pixhawk Cube Orange flight controller. The goal of this setup was to run SITL on hardware to simulate a Copter vehicle (quadrotor), test basic flight commands, and resolve issues encountered during calibration and configuration.

The following sections will discuss the specific problems faced during the process, solutions implemented, and reasoning behind the choices. If you are working on a similar setup, this guide will help you avoid common pitfalls and save time troubleshooting.

2. SITL Deployment on Pixhawk Cube Orange

2.1 Objective

The primary objective was to set up SITL on the Pixhawk Cube Orange and simulate a Copter (quadrotor) vehicle using ArduPilot firmware. SITL allows us to test flight behavior and validate software control in a safe, controlled environment, without needing an actual vehicle or an outdoor test field. By integrating SITL with hardware, we could directly interact with real sensors and simulate flight behavior on actual hardware.

2.2 Initial Attempt and Problem

Our initial approach was to try modifying the serial port configuration in a custom launch file. However, this did not work as expected and failed to establish proper communication between the SITL software and the Cube Orange board. We hypothesized that the issue might be related to incorrect board detection or firmware upload.

2.3 Correct Procedure and Reasoning

After reviewing the official ArduPilot documentation, we discovered the recommended way to launch SITL on hardware using sitl-on-hw.py. This Python script ensures that the correct board type, vehicle type, and frame type are used during the initialization process, which is vital for proper communication between the SITL simulation and the Pixhawk Cube Orange.

The exact command used is:

./Tools/scripts/sitl-on-hardware/sitl-on-hw.py --board CubeOrange-SimOnHardWare --vehicle copter --frame quad --upload

  • --board CubeOrange-SimOnHardWare: Specifies that SITL should be run on a Cube Orange hardware simulation setup.

  • --vehicle copter: Specifies the vehicle type (in our case, a quadcopter).

  • --frame quad: Denotes the frame type (quadrotor).

  • --upload: Automatically builds and uploads the latest firmware to the Cube Orange, ensuring compatibility with the simulation.

This approach successfully connected to the Cube Orange and established communication with the vehicle, allowing us to proceed with further setup.

3. Sensor Calibration Issues

3.1 Problem

After successfully connecting the Cube Orange to SITL, we encountered an issue with sensor calibration. The system threw the error:

  • COMPASS NOT CALIBRATED

This error indicated that the compass sensor had not been calibrated correctly, which would prevent proper orientation and heading estimation during flight.

3.2 Why It Happened

Calibration errors like “COMPASS NOT CALIBRATED” are common in SITL and hardware setups because many sensors require initialization before they can be used correctly. Without calibrating the accelerometer and compass, the Pixhawk Cube Orange cannot compute the correct orientation of the vehicle.

3.3 Resolution and Why We Chose This Method

To resolve this, we followed a tutorial for calibrating both the accelerometer and the compass. We used Mission Planner to perform the sensor calibration:

  • Accelerometer Calibration: This process adjusts the sensor’s readings to account for any bias or misalignment in the hardware, ensuring accurate orientation data.

  • Compass Calibration: This corrects for any distortion or interference that might affect the compass readings, which are essential for flight stability.

Following the tutorial, we successfully calibrated the sensors, and the error message disappeared.

4. Setting Simulated Home Position

4.1 Problem

After sensor calibration, we encountered another issue: takeoff commands were not accepted. The vehicle remained grounded, and no altitude changes occurred despite sending the appropriate TAKEOFF command. We suspected that this could be due to missing home position parameters, which are required for SITL to function correctly.

4.2 Why Home Position is Critical

In SITL, the home position must be defined before any flight actions, such as takeoff, can occur. The home position serves as the reference point for the simulated vehicle. Without setting the home position parameters (latitude, longitude, and altitude), the vehicle would not know where it is located, preventing it from taking off or responding to commands.

4.3 Parameters Set and Reasoning

To resolve this, we needed to define the home position using the following parameters:

  • SIM_OPOS_LAT: The latitude of the home position.

  • SIM_OPOS_LNG: The longitude of the home position.

  • SIM_OPOS_ALT: The altitude of the home position.

These parameters simulate a home location in the SITL environment, allowing the vehicle to understand its starting position in the world.

We used Mission Planner to set these parameters, referencing the ArduPilot SITL Documentation:

plaintext
CopyEdit
SIM_OPOS_LAT = <Your_Latitude>
SIM_OPOS_LNG = <Your_Longitude>
SIM_OPOS_ALT = <Your_Altitude>

Once the parameters were set and the system was rebooted, the vehicle was able to accept takeoff commands and initiate flight as expected.

5. Additional Observations

5.1 Compass Health Warning

Initially, we encountered the warning “COMPASS NOT HEALTHY”. However, after recalibrating the compass and adjusting the altitude, this error did not appear in subsequent tests. The issue appeared to be linked to an improper altitude setting (default SIM_OPOS_ALT = 548) that caused sensor issues, which we resolved by setting the altitude to zero.

5.2 TAKEOFF Command Rejection

During the initial testing, despite setting the home position and ensuring proper mode transitions, the vehicle would not accept the TAKEOFF command. The issue turned out to be a misconfigured altitude. We had initially set the altitude to 548, which was too high, causing the vehicle to reject the takeoff request.

Fix:

  • We set SIM_OPOS_ALT to 0 and rebooted the system.

  • After this adjustment, the TAKEOFF command was successfully accepted, and the vehicle initiated takeoff as expected.

6. Validation

After applying all fixes, we validated the system’s functionality through the following observations:

  • The system correctly calibrated the compass and accelerometer.
  • The takeoff command was accepted, and the vehicle transitioned into flight mode (GUIDED).
  • All other modes and commands (e.g., STABILIZE) functioned correctly.
  • The home position parameters allowed for proper simulation of flight.

7. Conclusion

In summary, deploying SITL on Pixhawk Cube Orange required careful attention to board configuration, sensor calibration, and simulation parameters. Here are the key takeaways:

  • Correct board configuration is crucial for establishing communication.
  • Home position parameters are essential for proper SITL operation.
  • Altitude mismatches can block takeoff commands, even if other settings are correct.
  • Calibration of the compass and accelerometer ensures accurate orientation data, which is critical for flight stability.
Back to all resources