The recent Hak5 episode 1903 inspired me to build a King of the Hill version for quadcopters. Shannon and Darren talked about their acrylic drone-fighting cage, the last-man-standing matches they had, and their future plans including a version of king of the hill.
Since then, I’ve been working on my own implementation of the king of the hill idea based on an old ADJD-S311 Color Light Sensor Evaluation Board from Sparkfun which I still had lying around. Combined with an Pololu A-Star 32U4 Micro for the brains, a single button for input, and an LPD8806 based RGB-LED-strip from Adafruit for output, this made a pretty nice tinkering project.
The micro quadcopters are split into 2 to 4 teams and are marked with differently coloured stickers at the bottom (red, green, blue, yellow).
The light sensor in the centre of the platform is initially passive and set to maximum sensitivity. In combination with ambient light, the A-Star Micro can detect whether the sensor is covered or not. As soon as it detects that the sensor is covered, it is set to active mode. It then evaluates reflected light using a white LED and a lower sensitivity setting. Based on the measured rgb-colour, ‘the brains’ decide which team the drone on the platform belongs to.
After a team covered the sensor for 3 seconds to win a point, the platform needs to be cleared for 5 seconds before another winning point can be gained.
The game play is set-up using the single button. First the number of teams is shown using the LEDs in the vertical stand. Clicking the button iterates between 2, 3, or 4 teams with different colours. After a long-click, the number of winning points are selected. Again by clicking the button 1, 3, 5, or 7 winning points can be selected. The game starts after another long-click with the progress being displayed on the vertical bar. As only a single LED strip is used, additive colour mixing occurs between the teams. The game continues until one of the teams achieves the necessary number of points, upon which the winning team’s colour flashes along the bar in ‘knight rider’ fashion.
Some friends from FIX, the local maker space, and I ordered a whole bunch of Eachine H8 Mini drones. Now we’re looking forward to some awesome team matches the space 🙂
The CAD models can be found at Onshape, a really interesting web-based CAD solution done by veterans of Solidworks. (log-in and search for ‘Drone King of the Hill’, couldn’t find a public link … still beta 😉 )
The source code can be found on GitHub and relies on the awesome cross-platform code builder and library manager PlatformIO.
Being curious about the underlying structure of relations between Hackaday authors, articles, and the referenced makers, I wrote a little Java program extracting this information from publicly available data. Using jsoup and gexf4j this was a rather quick task. A simple regular expression
extracts the usual “[Tim] did this and that …” references from the Hackaday blog.
After parsing the relationships
Author [wrote] Article
Author [mentions] Maker
Article [references] Maker
Maker [mentionedWith] Maker
and saving them as an GEXF graph, the data is passed to Gephi. Gephi is a really intuitive and versatile graph visualisation tool with various options to map properties to visual appearances. It also includes a range of automated layout algorithms.
The result of playing around with the data from the last 99 blog-history pages (~from November 2014) and the many visual options of Gephi are two rather beautiful and also insightful graphs:
(green – authors, red – articles, blue – makers)
The first graph scales the nodes according to their number of outgoing relations which emphasizes the authors. The second graph scales by the incoming relations and emphasizes the makers. On the outer fringes it becomes obvious that each author has his distinct cloud of referenced blogs while the centre of the graph highlights a cluster of makers referenced by multiple authors. Another prominent feature are many smaller clusters of makers mentioned together in one or more articles. With a bit of googling, it turns out that some of these graph-relations map very nicely to personal relationships. For example two maker-nodes mentioned together very often are actually brothers in the real-world. Others turn out to be close friends.
Although all of this is public information, I left out the labels identifying authors, articles, or makers for their privacy. Especially in the context of the current debate about safety, security, and privacy, this highlights how much insight can be gained even from simple meta-data relationships.
I recently bumped into NodeMCU firmware for the ESP8266. It’s an Lua interpreter, making tinkering with IoT ideas really simple. Just flash the firmware onto the ESP8266 and connect via serial console. You can start prototyping right away using the interactive Lua interpreter. You can easily persist your ideas on a simple flash file system.
For convenient development, there is ESPlorer, a basic IDE for Lua on the NodeMCU. It allows you to develop the Lua scripts locally and then save them to the MCU via serial protocol.
To make developing with the ESP-01 module easier, I created a basic development board. It provides easier access to the individual pins, has jumpers for flashing mode (GPIO00) and enable (CH_PD), offers a button for reset, and also integrates a socket for a step-down power supply.
Although NodeMCU provides access to the deep-sleep mode of the ESP8266
this is not available straight away on the ESP-01 module, as the ‘post-sleep-reset-pin’ XPD_DCDC (8) of the MCU is not connected to the reset pin. I solved this by manually soldering a single wire of a stranded cable between the reset pin of the module and the XPD_DCDC (8) pin of the MCU (bottom right corner of the mcu in the first photo). On top of this, I also removed the red power LED by simply prying it off with a tiny screw driver.
With these two modifications, the module is able to make use of the deep-sleep mode and successfully resets and restarts after waking.
During deep sleep the module now uses just 78 microAmps! On two normal AA batteries with 2600mAh, that’s good for well over 3 years!
Due to frequent questions about the Fritzing file or schematics, I uploaded the Fritzing file:
(if the file extension gets mixed up, apply .fzz manually)
Marv Marvelous over at http://blog.grafovision.sk/ translated this article into Slovak. Thanks Marv!
The above line was actually directly written from an old-fashioned punch card! How? Via my DIY punch-card-to-keyboard interface 😉
It all started with a conversation with a colleague about the good-old-times of computers, when de-bugging was still removing live animals. A few days later he dropped by my office and handed me a bunch of cards of ‘Druckwerke Reichenbach’.
Initially I tried reading the cards with a mechanical contact, but this quickly turned out to be highly unreliable. Around the same time I had disassembled some old HP office print stations, which resulted in a large number of useful parts. Some stepper motors, some solenoids, and heaps of slotted optical interrupter switches. Following a tip of another colleague, I started disassembling the switches into IR-LEDs and corresponding photo-transistors.
Using these components I build a new prototype, this time using contactless optical sensors. I drilled opposing holes into two plastic cards. On one side I glued the LEDs and on the other side the photo-transistors. The LEDs are powered by 3.3V chaining 3 LEDs serial and 4 groups parallel. The transistors use a common ground and are connected to the Teensy 3.1 inputs. The inputs have activated pull-up resistors, pulling them to 3.3V as well. With a free passage between the LED and the transistor, the light activates the transistor, which in turn pulls the input to ground. With the card in between, the transistor receives no light and let’s the input be pulled up to 3.3V. Thus the input pins follow an inverted logic.
The two plastic plates are separated by two plastic guides to each side of the card. They provide guidance to the card when inserted, which is important for the correct hole alignment. As the optical card reader turned out to work rather reliable, I implemented a simple interpreter on the Teensy 3.1 which reads the card according to the IBM model 029 keypunch from the 60’s / 70’s. The micro-controller is recognised as a USB HID keyboard and sends the decoded characters as key presses. Each card is finalised with an ‘enter’ key press. The only adjustments I made are to only use every second column of the card in order to make sure all contacts close after each character. Also I added a space character encoding (Y&X row). You can download the binary and source code for the Teensy 3.1 based decoder from github.
Now all that’s left is to do is to use this device and send a ‘HELLO WORLD!’ tweet directly from punch card 🙂
After the Maker Faire, I went back to the Graupner mc-17 remote control.
The arduino library from tronixstuff for the KTM-S1201 LCD which is also using a mPD7225 controller was a good starting point. But to get the LCD up and running, it took quite a bit of fiddling and logic sniffing.
Once the controller allowed me to switch on individual segments of the LCD, I needed to adapt my implementation to this specific display, as it offers remote control specific elements unusual for normal LCDs. With a proper mapping of bits and bytes to their respective LCD elements, it was easy to implement the usual alpha-numerical characters. Each of the digits is controlled by a word / two bytes. For each byte, one bit is used to control one of the additional symbols like colons, dots, or remote controls specific texts.
Last preparations for the upcoming Trondheim Maker Faire 2014. In order to display the Raspberry Pi / Teensy 3.1 based submersible ROV, I bought a used 3m diameter inflatable pool. This should give us enough space to demonstrate the little buddy.
The ROV got a slight face-lift by adding proper motor-pods and casings for the cables. The ballast stones tied to the bottom got replaced by a rusty old chain in casings. Better solution pending …
See you at the Trondheim Maker Faire booth 10a: Map of the Faire
For the Maker Faire coming to Trondheim later this month, I’m currently building a simple submersible remotely operated vehicle. The concept is based on a plumbing tube used for the housing and submersible electric pumps as motors. A Raspberry Pi with Camera Module will deliver the live video feed via ethernet cable. The remote control is managed via a serial link to a Teensy 3.1 with sensors and motor controllers. The communication will be implemented using MAVLink, which enables the use of the QGroundControl station.
After initially testing whether the tube could sustain the pressure at up to 12m water depth, pieces are now falling into place. The serial communication via MAVLink works and just needs a little performance tweaking. It can transmit the manual controls from a game-pad down to the ROV controller and the telemetry back up to the ground station. Telemetry data consists of air-pressure and temperature in the body (MPL115A2) as well as orientation data gathered from the IMU/AHRS (MPU-9150). The ground station visualises the temperature and pressure as line-graphs and uses the orientation information for an artificial horizon.
The plumbing tube of the housing is sealed with two acrylic-glass windows. One 6mm one in front of the camera and three 4mm layers in the rear end. The three layers form tunnels for the cables going out to the motors and up to the ground control station. I hope with plenty of silicone this will be water tight.
If anyone has a good idea how to set up a basin/pool to demonstrate the ROV in, let me know.
Four weeks to go! 🙂