Troubleshooting

ArduPilot’s documentation is a great place to start. Start reading from here.

Lots of Skybrush users use an on-line tool called UAV Log Viewer. The advantage of this is that you do not need to install anything on your computer to analyze a log. Mission Planner also has facilities for log analysis. If you prefer the command line, you can also try MAVExplorer from the MAVProxy suite.

While there are not (yet) any seminars on log analysis specifically for Skybrush show drone related issues, this one hosted by ArduPilot developer Andrew Tridgell is a gold mine of information on the subject.

Disabling the internal compasses is usually not a problem. Internal compasses tend to be noisy due to all the electronics around them so if you have one or more reliable external compasses, it makes sense to disable the internal ones — for one thing, you wouldn’t get compass inconsistency errors before takeoff just because the internal ones are pointing in the wrong direction.

This is usually caused by compass calibration issues or interference between the compass and the motors. If the drone is moving, the position and velocity information from the GPS, combined with motor outputs is enough for the EKF to provide a good yaw estimate. Compass-based yaw measurements come into play mostly when the drone is hovering because the velocity is close to zero at that point so it cannot be used to estimate the yaw accurately. That’s why compass errors trigger toiletbowling mostly while hovering and not while the drone is going from point A to B.

One thing that might help is to look at the early boot messages in Mission Planner; there should be a line that looks like this:

This indicates which PWM groups (pins) are assigned to which functions. DS1200 is DShot1200 (i.e. an ESC protocol), NeoP is NeoPixel. This should help in debugging which functionality was assigned to which PWM group by the firmware early at boot. Typically you’ll want PWM or a DShot variant on pins 1-4 (that go to the ESCs) and NeoP in some later group that goes to the LED light. With a PixHawk 6C, the boot message is:

If you are still having problems, you could grab an oscilloscope and check what’s going out on the PWM pins. NeoPixel signals should look like square waves with a bit rate of 800 kHz (so 1.25 usec per bit). You should get square waves consisting of chunks of 24 bits with RGB=(170, 170, 170) (i.e #aaaaaa), followed by 8 bits of "silence" (full zeros). While checking with a scope it’s best to leave the drone in a GPS-denied location so it keeps on flashing its LEDs with yellow, and then you can watch the wire signal as it will change constantly.

Here are parameter settings which work for a Pixhawk 6C:

The Pixhawk 6C has two physical PWM output rails. The first is labeled ‘I/O PWM OUT’ (the MAIN outputs) which is used for motors. The second is labeled ‘FMU PWM OUT’ which maps to the AUX outputs. In this example, the lights are connected to PWM channel 1 of the FMU PWM OUT rail, which maps to AUX1, and is set by Skybrush as SHOW_LED0_CHAN 9.

On the Pixhawk 6C, there is a grouping concept with regard to PWM servo use. SMT32 MCU has the limited number of timer channels, whose motor or servo PWM are depended on. NeoPixel need a specific use case of PWM and timer. The documentation can be found here.