[Myrijam Stoetzer] and her friend [Paul Foltin], 14 and 15 years old kids from Duisburg, Germany are working on a eye movement controller wheel chair. They were inspired by the Eyewriter Project which we’ve been following for a long time. Eyewriter was built for Tony Quan a.k.a Tempt1 by his friends. In 2003, Tempt1 was diagnosed with the degenerative nerve disorder ALS and is now fully paralyzed except for his eyes, but has been able to use the EyeWriter to continue his art.
This is their first big leap moving up from Lego Mindstorms. The eye tracker part consists of a safety glass frame, a regular webcam, and IR SMD LEDs. They removed the IR blocking filter from the webcam to make it work in all lighting conditions. The image processing is handled by an Odroid U3 – a compact, low cost ARM Quad Core SBC capable of running Ubuntu, Android, and other Linux OS systems. They initially tried the Raspberry Pi which managed to do just about 3fps, compared to 13~15fps from the Odroid. The code is written in Python and uses OpenCV libraries. They are learning Python on the go. An Arduino is used to control the motor via an H-bridge controller, and also to calibrate the eye tracker. Potentiometers connected to the Arduino’s analog ports allow adjusting the tracker to individual requirements.
The web cam video stream is filtered to obtain the pupil position, and this is compared to four presets for forward, reverse, left and right. The presets can be adjusted using the potentiometers. An enable switch, manually activated at present is used to ensure the wheel chair moves only when commanded. Their plan is to later replace this switch with tongue activation or maybe cheek muscle twitch detection.
First tests were on a small mockup robotic platform. After winning a local competition, they bought a second-hand wheel chair and started all over again. This time, they tried the Raspberry Pi 2 model B, and it was able to work at about 8~9fps. Not as well as the Odroid, but at half the cost, it seemed like a workable solution since their aim is to make it as cheap as possible. They would appreciate receiving any help to improve the performance – maybe improving their code or utilising all the four cores more efficiently. For the bigger wheelchair, they used recycled car windshield wiper motors and some relays to switch them. They also used a 3D printer to print an enclosure for the camera and wheels to help turn the wheelchair. Further details are also available on [Myrijam]’s blog. They documented their build (German, pdf) and have their sights set on the German National Science Fair. The team is working on English translation of the documentation and will release all design files and source code under a CC by NC license soon.
[danjovic] is a vintage computer enthusiast and has several old computers in his collection. Among them are a couple of TK-85 units – a ZX81 clone manufactured by Microdigital Eletronica in Brazil. The TK-85 outputs a monochrome video output. And when [danjovic] acquired a SyncMaster 510 computer monitor, he went about building a circuit to “colorise” the output from the ZX81 clone (Portuguese translation).
The SyncMaster 510 supports 15kHz RGB video refresh rate, so he thought it ought to be easy to hook it up to the TK-85, which internally has the video and composite sync signals available. So, if he could lower the amplitude of the video signal to 0.7Vpp, using resistors, and connect this signal to one of the primary colors on the monitor, for example green, then the screen should have black characters with a green background.
Before he could do any of this, he first had to debug and fix the TK-85 which seemed to be having several age related issues. After swapping out several deteriorating IC sockets, he was able to get it running. He soldered wires directly to one of the logic chips that had the video and sync signals present on them, along with the +5V and GND connections and hooked them up to a breadboard. He then tested his circuit consisting of the TTL multiplexer, DIP switches and resistors. This worked, but not as expected, and after some digging around, he deduced that it was due to the lack of the back porch in the video signal. From Wikipedia, “The back porch is the portion of each scan line between the end (rising edge) of the horizontal sync pulse and the start of active video. It is used to restore the black level (300 mV.) reference in analog video. In signal processing terms, it compensates for the fall time and settling time following the sync pulse.”
To implement the back porch, he referred to an older hack he had come across that involved solving a similar problem in the ZX81. Eventually, it was easily implemented by an RC filter and a diode. With this done, he was now able to select any RGB value for foreground and background colors. Finally, he built a little PCB to house the multiplexer, DIP switches and level shifting resistors. For those interested, he’s also documented his restoration of the TK-85 over a four-part blog post.
A filmmaker friend of [Thomas] mentioned that she would like to display a triptych at the 2015 Venice Art Walk. This is no ordinary triptych with a frame for three pictures – this is a video triptych, with three displays each showing a different video, and everything running in sync. Sounds like a cool engineering challenge, huh?
The electronics used in the build were three Raspberry Pi 2s and a trio of HDMI displays. Power is provided by a 12V, 10A switching supply with 5V stepdown converters for the Pis. The chassis is a bunch of aluminum bars and U channel encased in an extremely well made arts and crafts style frame. So far, nothing out of the ordinary.
Putting three monitors and three Pis in a frame isn’t the hard part of this build; getting three different displays all showing different videos is. For this, [Thomas] networked the Pis through an Ethernet hub, got the videos to play independently on a RAM disk with omxplayer. One of the Raspberry Pis serves as the master, commanding the slaves to start, stop, and rewind the video on cue. According to [Thomas], it’s a somewhat hacky solution with a bunch of sleep statements at the beginning of the script to allow the boot processes to finish. It’s a beautiful build, though, and if you ever need to command multiple monitors to display the same thing, this is how you do it.
It’s graduation time, and you know what that means! Another great round of senior design projects doing things that are usually pretty unique. [Bruce Land] sent in a great one from Cornell where the students have been working on a project that uses FPGAs and a few video cameras to keep score of a ping-pong game.
The system works by processing a live NTSC feed of a ping pong game. The ball is painted a particular color to aid in detection, and the FPGAs that process the video can keep track of where the net is, how many times the ball bounces, and if the ball has been hit by a player. With all of this information, the system can keep track of the score of the game, which is displayed on a monitor near the table. Now, the players are free to concentrate on their game and don’t have to worry about keeping score!
This is a pretty impressive demonstration of FPGAs and video processing that has applications beyond just ping pong. What would you use it for? It’s always interesting to see what students are working on; core concepts from these experiments tend to make their way into their professional lives later on. Maybe they’ll even take this project to the next level and build an actual real, working ping pong robot to work with their scoring system!
Continue reading “FPGAs Keep Track of your Ping Pong Game”
When the apocalypse hits and your power goes out, how are you going to keep yourself entertained? If you are lucky enough to be friends with [stopsendingmejunk], you can just hop on his pedal powered cinema and watch whatever movies you have stored on digital media.
This unit is built around an ordinary bicycle. A friction drive is used to generate the electricity via pedal power. In order to accomplish this, a custom steel stand was fabricated together in order to lift the rear wheel off the ground. A 24V 200W motor is used as the generator. [stopsendingmejunk] manufactured a custom spindle for the motor shaft. The spindle is made from a skateboard wheel. The motor is mounted in such a way that it can be lowered to rub the skateboard wheel against the bicycle wheel. This way when the rear bicycle wheel spins, it also rotates the motor. The motor can be lifted out of the way when cruising around if desired.
The power generated from the motor first runs through a regulator. This takes the variable voltage from the generator and smooths it out to a nice even power signal. This regulated power then charges two Goal Zero Sherpa 100 lithium batteries. The batteries allow for a buffer to allow the movie to continue playing while changing riders. The batteries then power the Optomo 750 projector as well as a set of speakers.
The Philips Ambilight – a bunch of rear-facing RGB LEDs taped to the back of a TV – is becoming the standard project for anyone beginning to tinker with FPGAs. [DrX]’s is the best one we’ve seen yet, with a single board that reads and HDMI stream, makes blinkey lights go, and outputs the HDMI stream to the TV or monitor.
[DrX] is using an FPGA development board with two HDMI connectors – the Scarab miniSpartan6+ – and a strand of WS2801 individually addressable RGB LEDs for this project. With a bit of level shifting, driving the LEDs was easily taken care of. But what about decoding HDMI?
Most of the project is borrowed from a project that displays a logo in the corner of a 720p video stream. The hardware is the same, but for an Ambilight clone, you need to read the video stream and process it, not just write to it. By carefully keeping track of the R, G, and B values for each pixel along with the pixel clock, the colors along the edge of a display can be averaged. It’s not as difficult or as memory-intensive as building a frame buffer; nearly all of the picture data is thrown out when assembling the averages around the perimeter of the display. It does work, though.
After figuring out the average color around the perimeter of the display, it’s just a simple matter of driving the LEDs. Tape those LEDs to the back of a TV, and there’s an Ambilight clone, made with an FPGA.
[DrX] has a few videos of his project in action. You can check those out below.
Continue reading “FPGA Based Ambilight Clone”
It’s pretty common to grab a USB webcam when you need something monitored. They’re quick and easy now, most are plug-and-play on almost every modern OS, and they’re cheap. But what happens when you need to monitor more than a few things? Often this means lots of cameras and additional expensive hardware to support the powerful software needed, but [moritz simon geist] and his group’s Madcam software can now do the same thing inexpensively and simply.
Many approaches were considered before the group settled on using PCI to handle the video feeds. Obviously using just USB would cause a bottleneck, but they also found that Ethernet had a very high latency as well. They also tried mixing the video feeds from Raspberry Pis, without much success either. Their computer is a pretty standard AMD with 4 GB of RAM running Xubuntu as well, so as long as you have the PCI slots needed there’s pretty much no limit to what you could do with this software.
At first we scoffed at the price tag of around $500 (including the computer that runs the software) but apparently the sky’s the limit for how much you could spend on a commercial system, so this is actually quite the reduction in cost. Odds are you have a desktop computer anyway, and once you get the software from their Github repository you’re pretty much on your way. So far the creators have tested the software with 10 cameras, but it could be expanded to handle more. It would be even cooler if you could somehow incorporate video feeds from radio sources!
Continue reading “A Non-Infinite But Arbitrariliy Large Number of Video Feeds”