With taking on more projects that involve more than just myself, I’ve been working on writing documentation to share the knowledge around a project and store information with relevant tips to the project I’m working on.
While searching for a somewhat easy-to-configure, preferably free solution to documentation hosting, I came across Read the Docs. Read the Docs is a helpful 1free hosting service that works with Github’s version control to create expansive documentation for projects.
To get started, you create a copy of their template on GitHub. Then, I used VSCode to clone the repo I just created from the template. Then, on the Read-the-Docs site, you add the repo to start the site building and set it! Read the Docs’ pages, which are written entirely in reStructuredText and similar to Markdown’s formatting. Coming from no experience, I found it relatively easy to learn, referencing the examples and documentation.
A cool feature is using the branching in Github to create versions of documentation and being able to use Githubs strong suit of version control to make sure if I make mistakes or edits I don’t like, I can quickly narrow down where its source is with the notes I added to each version change in Github.
The free tier is only available for community projects and is Ad-supported. Read more↩︎
In the event of researching software for my church to help streamline the streaming process and slideshows. Initially utilizing less ideal software for A/V, I’ve found some fascinating tools that directly target my problems with the software we were using; whether directly targeting churches or not, I’ve come across many solutions.
The “it works” problem:
The existing setup we used before FreeShow was Google Slides, which was not the most glamorous software. It was the best free “software” for our use case and worked about 90% of the time. But it also had downsides, which made it more of a “workaround” than a proper solution.
One such problem was editing slides and keeping track of lyric edits. We generally follow this process for the order of Sunday slides:
Each song is imported from another Google Slides file. For example, if we were to sing “God Rest Ye Merry Gentlemen.” It would be pulled from another Google Slides file containing just that song and copied to Sunday’s Presentation.
The problem with this is whenever we edit a slideshow, i.e., the band plays it with one extra Chorus, a word is misspelled, a verse is missing, etc. That edit wouldn’t make it to the original song’s slide file. Then, the next time it’s used in a Sunday Presentation, it will not have the edits applied. While a minor problem, it still has an impact in the event of editing it last minute before service starts.
Another problem I had was with basic slide control. Arrow keys had to be used with the Google Slides window being selected, which I worked around with a hotkey that, when pressed, would switch windows to Chrome and hit the > arrow button. But that hotkey contained issues in the event of a second Chrome window being open, and the program couldn’t figure out which one to choose.
The Solution:
I first went to ProPresenter, probably the most popular presentation software on the market. With many organizations using Propresenter, like Bethel, Delta Airlines, NASA, and The White House, they have almost every integration one would ever need. With even support for SongSelect, which is what we have used in the past for getting song licenses/lyrics.
One problem, however, is cost. With the surplus of features comes the price of the program itself. Starting at ~290/yr, it isn’t exactly friendly for smaller churches. Also, considering Google Slides is free, it is hard to argue with something that has been working “fine” for the past few years. A couple of inconveniences don’t justify additional bills for the church.
That’s when I came across FreeShow, which, as the name implies, is a free slideshow software developed by the folks at ChurchApps. It is one type of software designed specifically for churches and contains features for everyday presentations. What makes the FreeShow free is partially due to its “crowdfunding” nature. Its code is open-sourced on Github, making it easier for other developers to contribute, make feature requests, and create bug reports.
What are theFeatures?
The features I’ve come to like about FreeShow, to name a few, are:
Each song keeps its edits made previously
Custom templates
Quickly drag and drop the songs for Sunday from your database
Browser connections, including remote control, highlighting tool, and virtually the whole show editor GUI, are accessible over the local network in any browser.
Integration with Companion (another super cool software for Stream Deck)
Cloud backup with syncing across computers
A quickly accessible Media tab with free images/videos
Features that FreeShow advertises
Another big plus for me is how often the app gets updated. While that means frequent updating can be annoying, new features and bug fixes are pushed more often. The developers are active in the Issues tab, responding to my submitted issue within a day or so.
Lurking issues:
But that brings up the topic of issues; being an open-source donation-funded program, it comes with bugs. Most of the things I’ve come across are slight lags, editing not working at times, performance problems, and media 404’ng, which causes blank backgrounds. Some are acceptable, and a software restart will usually amend it, while others are (from what I can tell) compatibility problems with MacOS/Windows, as I don’t usually have the same issues occurring on both computers.
One such issue I recently encountered is that the media is not loading. Looking at the console, it ends up reporting a “cannot reach” error to the image URL. This error appears especially when syncing across computers; it’s only recently and has not been reported.
I’m excited to see where it goes, as the updates are relatively frequent. A benefit of the open-source nature is I can fork it, download it, and mess with any part of the application, and it’s written in 50% TSX, which I’ve been working through with Coursera’s Frontend Course.
One example of a feature I’m trying to implement for myself is chronicling, a modification of the existing “Used” feature that tracks the last date it was used in a slideshow. Chronicling will be a way to track each show by a unique number, which will change by the date it’s used. With that, I want to implement a way to choose the oldest number based on the current date, eventually making a way of automating the song selection process for each Sunday. One button will grab ~6 of the oldest songs used and place them into the current show.
In summary, FreeShow is a promising application that’s been a massive upgrade from what we had used. Being a newer application, it suffers from bugs but is regularly updated with fixes and what seems to be an active developer community.
All rights to ChurchApps and FreeShow belong exclusively to them. I’m not sponsored by them, endorsed by them, or in any way officially linked to their software*
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:
Yesterday, I got to unbox the first drone hardware; since my last post, I picked out a build based on Stan Humphries’s video “How I Build Custom Light Show Drones…” the build consists of mostly HolyBro components, while not being cheap they offered a reliable and well-documented parts compared to the competitors or parts I would have gotten cheaper off AliExpress.
The setup for the first drone is more expensive than what you would want for an entire fleet of 100+ drones. However, it is a good testing platform for getting hands-on with the Skybrush suite.
H-RTK F9P GNSS Series
Pixhawk 6c
S500 V2 Kits
5000mAh 4S 60C Lipo
Wifi Module (3DR)
*Many more components contributed to the build, but I won’t include the full list here. Once I’ve got a better idea of a scalable drone build, I’ll share the BoM.
This was my first time unboxing, so I couldn’t fully assemble every component, but it gave me a good idea of what would be required for the building process. It also shocked me how large the batteries would be and how cheap they were for their capacity. I loosely hand-assembled the drone development kit with the onboard RTK module and double-checked the correct connectors that came for wiring.
A loose hand-tightened assembly of the drone frame.
At first glance, it seems that there will be minimal soldering work: replacing the XT90 with an XT60, soldering the battery power module to the PDB (the drone’s built-in power distribution PCB), and Soldering the LEDs to the BEC (Battery Eliminator Circuit that regulates the voltage to a lower amount for powering LEDs).
That’s my update! I’ll post minor updates on Discord or new information I find helpful for reference.
