One of the more recent tasks of my custom drone show drones is the LED light mounts. Getting started, I had only one real option material-wise, based on looking at Stan Humphries’s video covering his complete build, which is 3D printing the attachment.
The concept: An easily detachable clip-on assembly to the legs of the drone. Has mounting for up to LED modules shining in all directions. A diffuser is mounted on the bottom to enclose the whole assembly. With some inspiration from Stan Humphries’s design, I was able to get started designing in Fusion.
Full AssemblyBottom Bowl(Stan Humphries design)
The first task was getting the CAD files for the frame assembly. This was more diffuse than expected; a quick search on GrabCad yielded nothing useful. But with some Googling, I found that HolyBro (the frame manufacturer) had uploaded the full CAD reference files onto Wikifactory. With that, I could roughly assemble the frame parts in Fusion 360.
The first concept was testing the fit of a clip and how much pressure could be held before it could come off. And rather basic screw mounting for the Adafruit LEDs:
After printing this initial prototype, I realized two important things:
The clip style of starting from the middle and moving outward on either side makes it challenging to mount from the bottom quickly
The LED mounting was not bidirectional. There would be no proper light distribution.
The second design fixed both of those issues. Stan fixed the first problem by doing an opposing hook style on both ends. Mounting could be done by rotating it when aligned to the middle of the frame.
Old VersionNew Version
Another feature in the new version is adding a second component: Light Base. The light base has 4 LEDs mounted in all directions at angles to disperse the light as much as possible.
Both components can be mounted together with standard M3 screws threading directly into the plastic. (Adding heat inserts only adds to the complexity, significantly scaling the number of drones)
My next version will include more quality-of-life updates, textured hooks to snap attachments more easily off, a mount for the future diffuser, and more holes in hook attachment for routing LED wiring.
I’m about two months into my Front End Web Development course, and it’s about time I update.
As of this writing, I’ve completed four out of nine of the certificate program’s courses. Since my last post, I’ve finished “Programming with Javascript,” “Version Control,” and “HTML and CSS in Depth.” I’m currently in the middle of “React Basics.”
Programming with Javascript
So far, this is one of my favorite courses in the program. This is mainly because it’s the only language I never really understood the basics of. It covers the basics from logging into the console to editing and integrating with HTML, how to use event handlers, and editing basic HTML with the console in inspect element.
One of the more significant concepts introduced was OOP or Object-Oriented Programming. OOP is a recommended programming model for developing applications, where some parts of a website are thought of as modules that can be removed, duplicated, and quickly edited for reusability.
For example, instead of writing new code every time you want to show the latest blog post, you can create a reusable template that knows how to do this. Then, whenever you need it, you can use that template to automatically grab and display the newest blog post on any page without having to write the code again. A big part of that is being demonstrated in my current course I’m taking on React Basics.
There’s a much better explanation of how it works and more in-depth here.
Version Control
Version control covers the basics of GitHub. As with Javascript, this course was also informative. I’ve used GitHub occasionally for small projects and downloaded many open-source apps, but I never really understood how to use it and how it works. This course covered creating repositories, forking, branching, and basic terminal commands.
One of the neat things I learned about GitHub that I previously did not know about is the branching system for repositories. In a barebones repository, you have the Main branch, which has the (usually) fully fleshed-out main releases for a project. For example, I’m developing docs for the Drone Project (https://ezraharris.com/category/tech/drone/ series I’m doing on building drones for a drone show). With that, I chose a free template for creating docs called “Read-the-Docs.” Read the Docs has a template with GitHub, which makes it super easy to create a copy from the template page and host it for free using their deployment system. The branching is part of the automatic deployment system; I have two branches in GitHub: a Testing branch and a Main branch. I can make changes to the testing branch that may break the formatting, but that’s not on the main page and won’t affect the primary traffic of users. I can preview edits before pushing the testing branch into the main branch.
GitHub has much better documentation on using branching and managing pull requests here.
HTML and CSS in Depth
This also introduced many new concepts I had no idea were natively possible, like animations, using keyframes for more than just linear animations, and creating super smooth effects with only a couple of lines of code.
At the end of this course, I had to create a basic homepage using the concepts covered in the course. I was given a choice of four clients. I ended up choosing Lucky Shrub. I was provided a basic description with info about the client, logos, and a couple of preparation videos outlining the site’s basic framework I would create.
What made this assignment different from the other courses was the peer-reviewed grading. This is where I had some issues with Coursera. The downside is that they only support uploading HTML and CSS files, for the final project, making it challenging to review my peers’ websites because the links between files and folder structures were strange or because they used images outside of what Coursera provided. In the end, it made for a more complicated grading system than what it needed to be.
I ended up uploading the whole site to a GitHub repository and hosted it on Pages.dev. Cloudflare provides free basic web hosting and testing applications. (You can view my finished site for the project here)
I think it’d be a much easier process if Coursera worked with Pages.dev and/or Github to host the sites for previews instead of the mangled way of downloading and hosting it locally they have now.
Overall, I enjoyed all of the courses, but Javascript and React are quickly becoming the most interesting.
Certificates I’ve earned so far for completing mini-courses
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:
The first test with LEDs remotely powered and controlled onboard by a drone
I got the NeoPixel LEDs working with Arducopter and natively updating with the Drone’s current status:
Green = Armed & Ready
Blinking Yellow = PreArm Check
Red = Error / Failsafe
The hardware setup for powering the lights was as easy as soldering my UBec to the output voltage pads to take power directly from the battery input.
Power Diagram for S500 Power Delivery Board
The wiring for controlling the LEDs was also fairly straightforward. I utilized one of the six open FMU PWM OUT ports’ signal pins. In PX4’s documentation, they list the FMU PWM OUT as AUX ports, which will be suitable for this case.
I also used an Arduino Dupont wire from (S) Signal for initial testing. The other end of the wire was connected to the Neopixel’s middle signal wire.
It was a bit of trial and error for software, but overall, it was not a big hurdle; I changed the following parameters to let ArduCopter know there is a Neopixel connected to one of the FMU PWM ports. (Which, in this case, is classified as an AUX port, according to ArduCopter):
SHOW_LED0_CHAN sets the channel for which the Neopixel is connected. In this case, channel five on the FMU OUT is equivalent to AUX 13.
As the parameter implies, SHOW_LED0_COUNT is the number of LEDs chained together since most people plan to chain more than one LED.
SHOW_LED0_TYPE is the type of LED that is connected. For my specific case, I have a Neopixel RGBW assigned to 10. There is a non-RGBW Neopixel variant which has the assigned value of 3.
A quick reboot will apply the settings, and from there, I was able to change the lights and test them using Skybrush Live.
This post is part of a series of posts on drone light shows. I am actively updating docs.ezraharris.com to provide more step-by-step instructions while configuring Drones for a light show.
