Ezra Harris

Category: Technology

Posts that are tech related

  • Meta Front-End Developer Course | 2 Months in

    Meta Front-End Developer Course | 2 Months in

    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.

    Screenshot of Luckshrub's client option given by coursera

    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.

    Preview of my homepage assignment for Coursera

    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

  • 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_ENABLE0
    ARMING_CHECK1048510

    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

  • NeoPixel With ArduCopter

    NeoPixel With ArduCopter

    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_CHAN13
    SHOW_LED0_COUNT1
    SHOW_LED0_TYPE10
    ArduCopter parameters to reflect Neopixel

    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.

  • Drone Light Show (Part 3) – Build Goes Sideways

    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.

Privacy Policy