Tag: Tech

Neopixel Frustrations to Custom RGBW LED Modules
After having issues with the Neopixel LED modules on the two newer drones (a blog post about that headache is coming soon…), I decided to try a different design by Techventures Sean for an LED module based on the use case of Skybrush drones.

Heads up, this post is part of a more extensive series about building drones for a small drone show. This post is part six of the series, and previously, I covered 3D designing mounts for the LED modules from Adafruit.

I mentioned two separate LED module designs in the first paragraph. But what are these two options?

The option we have currently implemented is the 4W LEDs from Adafruit. These are cheap and offer a plug-and-play way to light up the sky. They also work under the NeoPixel branding, so documentation is extensive. I covered that setup in this post:

NeoPixel With ArduCopter

The second option is what I’ll be covering in this post. Sean, the creator of this design, recommended it to me on the Skybrush Discord when I expressed frustration with some problems with the Neopixel LEDs.

“That module is the equivalent to 8-10 of those Adafruit modules.”

-Sean (Mwd-Sean)

The design for the light module comprises four main controlling components, BGRW (as shown in the animation below. Each part is individually controlled via 4 PWM signals from the flight controller addressing each light color:

Sean’s RGBW LED Module https://oshwlab.com/sean1/skybrush-rgbw-led

After reviewing most diagrams and parts and looking at what tools I need for assembly, I ordered all the necessary parts from JLCPCB (which manufactures PCBs), LCSC Parts (which manufactures the elements, like resistors and capacitors), and the LED chips themselves from Amazon. Shipping took about a week to arrive.

img: Sean (TechVentures)

I began attempting to solder the first parts onto the PCB when it became more apparent how unprepared I was. One obstacle was the solder itself. I installed my TS101 soldering iron with a small tip, but the solder wasn’t flowing well, and flux made a mess of it.

I ordered a similar but thinner version of the solder I’d been using called Solder Paste. Solder paste comprises primarily micro solder beads, which, mixed with a flux-like liquid, lowers the melting temperature to about 180c instead of the 250c I had been accustomed to. ¹

img: Solder paste on PCB, with a closeup taken under the microscope.

With the soldering down and the assistance of a microscope, I could nail down the assembly: placing the components and eventually soldering them into place. Although the first attempt did come with its problems, more minor mistakes mostly – not being patient and forgiving when I misplaced a component. Remember how much solder paste needs to be pre-applied.

Also, realizing I made a small ordering mistake in the number of specific components I needed to place on the PCB, I am currently waiting for that order to complete the assembly.
1. Unfortunately, the PCB is designed with heat dissipation in mind. It is made almost entirely of aluminum, making it more challenging to get the solder to the required melting temperature. ↩︎
December 10, 2024
React State | Front-end Web Development
A new concept I’m starting to learn in my Coursera course on React Basics (view post series here) is React “States.” States in React is an interesting way of storing the “state” or current information about a variable or function.

ⓘ As a new topic, I’m still learning how React works. For an actual professional, please refer to a better explanation.

The first example of utilizing state is the “React.useState” hook. To use useState, you assign it to two array values that usually consist of one variable storing the value and another variable to set the value of the state. For example:
```
import { useState } from 'react';

function exampleApp() {
    const [user, setUser] = useState("ezra");
    
}
```
First, we import the state hook. Then, in the function, we assign two variables to the useState hook. Inside of the state, it has “Ezra,” which, in this case, sets the default value. If we wanted to add a function to update the state to a value, we could do so as follows:
```
    
    function updateUser(e) {
        setUser(e.target.value);
    }
```
Coursera outlines that you generally want to utilize separate functions to handle events. In this case, we have a function that, when called in combination with an input field, will grab the input’s value (e.target.value). We use the setUser that we already declared earlier.

The complete component example they taught me was:
```
import { useState } from 'react';

function ExampleApp() {
    const [user, setUser] = useState("ezra");

    function updateUser(e) {
        setUser(e.target.value);
    }
    return (
        <div>
            <h1>{user}</h1>
            <input onInput={updateUser}></input>
        </div>
    )
}
export default ExampleApp;
```
This creates a page with an H1 element and an Input field. By default, H1 says “Ezra,” but when you type into the input field, it actively changes to what you type.

It is an excellent and useful concept that will probably be used frequently in future React programming. Coursera also outlined a general guideline for creating components, specifically when and when not to use states.

As the name implies, you have Stateless and Stateful components, one without any state declarations and others with state declarations. It goes to the basics of how you want things formatted and makes it much easier to later grab the state of an object by passing it down from a parent to a child component rather than having to reinstate that state in each element.

credit: Coursera.org

States in react go a lot deeper and a lot more complex, but I’m excited to learn more about it.
September 27, 2024

Circumventing Safety Features

I recently encountered an interesting problem when configuring all three drones simultaneously with the Skybrush drone management software.

I would power up all three drones and connect them to the network I configured for them. All three would appear on my laptop. After double-checking that they were actively connected, I manually rebooted each one and confirmed the connection using the Skybrush software.

With propellers removed, pre-arm checks approved. I would go and arm each drone.

“Arming” is the last step before takeoff for a drone. “Pre-Arm” ensures all safety checks (foreshadowing) are completed but does not start up motors. Arming, on the other hand, starts the motors at a low rpm and listens for control inputs (i.e., throttle up) for takeoff. It disarms if no input is provided within 10 seconds of the motors spinning.

But here’s where the problem occurred. Only one drone would go into arming mode, while the other two reported an “unknown” error and blinked red.

After some research and trial and error, I discovered that the drone reported an “RC Not Found” error to the ground station.

Now, that’s strange; it should be configured to ignore whether or not it had an RC connection for Pre-Flight. I went into QGroundControl and manually configured it to ignore pre-flight checks for the RC. After a quick reboot, I tried again.

Still, no luck, except the behavior changed slightly. After the blinking red error, I tried arming the drones again… and they all spun up! But Skybrush still showed them as reporting an error. This is not ideal for my case, but as the classic saying goes, a different error is still in progress.

After more research, I found a forum post with someone asking a similar question and a super helpful user linking to a page about configuring ArduPilot with autonomous flight software like SkyBrush.

It ended up being two parameters that affected my problem.

FS_THR_ENABLE – Allow arming without checking for RC
ARMING_CHECK – Disable RC failsafe for pre-arm checks

Setting those two and a quick reboot resulted in all three drones being able to go into pre-arm, then arming mode, and ready for takeoff. The corrected values are:

FS_THR_ENABLE	0
ARMING_CHECK	1048510

The longer string for ARMING_CHECK signifies which failsafe options to disable; Arducopter gives you 19 total options for failsafe, from Compass to Battery Levels. A complete list is provided here.

And finally, here’s a quick reference list I had ChatGPT create based on the parameter’s instructions:

Bit	Check	Value	Description
0	All	1	Enables all checks
1	Barometer	2	Ensures the barometer is functioning correctly
2	Compass	4	Verifies compass calibration
3	GPS lock	8	Requires a valid GPS lock before arming
4	INS	16	Checks Inertial Navigation System (IMU) health
5	Parameters	32	Confirms parameters are set correctly
6	RC Channels	64	Ensures RC signal is valid
7	Board voltage	128	Monitors voltage levels of the flight controller
8	Battery Level	256	Verifies battery level is sufficient
10	Logging Available	1024	Checks if logging is available
11	Hardware safety switch	2048	Requires safety switch to be engaged
12	GPS Configuration	4096	Verifies GPS is configured correctly
13	System	8192	Checks system-level health
14	Mission	16384	Ensures a valid mission is loaded
15	Rangefinder	32768	Checks rangefinder sensors
16	Camera	65536	Verifies camera is functioning correctly
17	AuxAuth	131072	Checks auxiliary authorization systems
18	VisualOdometry	262144	Monitors visual odometry sensor health
19	FFT	524288	Verifies Fast Fourier Transform data availability

September 18, 2024

Drone Light Show (Part 3) – Build Goes Sideways

For the past few weeks, I’ve been working on getting a drone ready for takeoff and, ultimately, for formation in a light show. Since the last blog post on unboxing, I soldered the battery module onto the drone’s PDB (Power Distribution Board) with some success.

I access the flight controller using software called QGroundControl, which has all the necessary tools for setting up and pre-planning flight routes with the Drone’s GPS. I utilized a mixed connection of USB and Wi-Fi, the Wi-Fi setup was relatively easy. I only had to change one of the drone’s parameters to instruct it how to handle the Wi-Fi connection to Ground Control properly.

After initial setup, I was able to calibrate all of the sensors related to positioning and orientation. (Useful documentation for specific details) Next was to attach props and arm motors for takeoff. Once prepped and the battery connected, we started a slow takeoff to see the responsiveness (or, in this case, lack of responsiveness)

Unfortunately for me, the takeoff did not exactly go “up” but rather sideways. When pushing the throttle stick, the drone would start to lean backward and or start rotating when meant to fly straight up. After a lot of trial and error, I ended up installing the latest firmware for the board we’re using. But instead of the ArduPilot firmware platform I tried the Pixhawk firmware. This shouldn’t make a ton of difference, but it had a lot more options for setup and specific configurations related to the frame we’re using instead of the generic frame I selected before.

With flashing new firmware, it requires me to setup all of the compass and calibrations done before. One of the hurdles of calibrations was an error being thrown when we had the drone in the forward position. It would throw a generic “Test Failed” That was fixed with a simple parameter edit (parameters, in this case, are the manual settings for each part of the drone) that would change the primary sensor for all movement to the HolyBro RTK, instead of the flight controller. Which has a basic compass and accelerometer sensors.

Another small stumbling block was referencing a guide I had used before, which SkyBrush provides in their docs. Specifically for basic parameter setup, you need to make sure the Drone is using the RTK onboard for primary 3D sensing (basic tilt, pan, etc.) When referencing that guide, it had specific settings to change. I later figured out that PixHawk and Ardupilot each have their own parameters, and they do not carry across names. Skybrush provides firmware that is based on ArduPilot. Some are similar, but ArduPilot had a lot more advanced options; it was a stumbling block but not a huge deal as I was able to find the substitutes for PixHawk.

PixHawk Parameters list | docs.px4.io |

Ardupilot Parameters list | ardupilot.org |

After reviewing a couple of examples and online forums, I realized that my motor setup was all wrong. I had both the motors spinning in the wrong directions and the motor frame setup.

For example, this is what I believe I initially incorrectly set it up as and how it’s supposed to be laid out:

Correct layout

Incorrect layout

The incorrect layout had three motors that were going CCW, which I found out when rearranging the motors as the wires were flipped. (This inverts the spin direction of the motor.) Thus, there were essentially three CCW spinning props. This caused the drone to start spinning or try to flip on takeoff. Ardupilot tried to compensate for orientation, and it ended up being a mess.

After realizing this issue and fixing it, a quick takeoff showed that it was, in fact, the issue.

First successful takeoff

The day after, I reflashed Skybrush firmware and configured all of the recommended settings, and it took off as expected, showing that the motor orientation was, in fact, the main problem. The next step is to autotune and figure out what behavior changes are made in different flight modes.

First field test

This post includes the logos of Ardupilot and QGroundControl, which are the trademarks and property of their respective owners. I do not own any rights to these logos, and their use in this post is solely for informational and illustrative purposes. The inclusion of these logos does not imply any affiliation, sponsorship, endorsement, or approval by the respective companies. All trademarks and copyrights remain the property of their respective owners.

August 9, 2024

Tag: Tech

Neopixel Frustrations to Custom RGBW LED Modules

React State | Front-end Web Development

Circumventing Safety Features

Drone Light Show (Part 3) – Build Goes Sideways