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”
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”
Unlike microcontroller projects, projects involving FPGAs cannot yet claim to rely on a mature open-source toolchain. Each FPGA will, at some point, need to be configured with a proprietary bitstream produced from a closed source synthesis tool. This lack of a full FPGA toolchain to take your project from Verilog-or-VHDL to an uploadable bitstream is due to many reasons. First, writing such a “compiler” is complicated. It involves intimate knowledge of the resources available on the FPGA that can assimilate the functionality of the intended design. Second, the entire synthesis procedure is closed-source, a “secret sauce” of sorts for each FPGA vendor.
In response, [Alex] and [Clifford] have taken the first step towards an open-source toolchain for one FPGA; they’ve reverse-engineered the bitstream of Latttice Semiconductor’s iCE40 FPGA. The duo didn’t just pick the iCE40 on a whim. This choice was deliberately because that FPGA is available on a development board for a mere $22 so that others could follow in their footsteps without breaking the bank.
In the video below, [Clifford] demos the functionality of this new tool by synthesizing a design from Verilog to a bitstream and then back from a bitstream to Verilog. Given this feature, a staggering amount of work has been done towards developing a polished open-source toolchain for this particular FGPA.
To snag a copy of the latest code, have a look at its documentation page.
Continue reading “Reverse Engineering Lattice’s iCE40 FPGA Bitstream”
Field Programmable Gate Arrays (FPGAs) let you program any logic you’d like onto a chip. You write your logic using a hardware description language, then flash it to the FPGA. You can even design your own processor and flash it to the chip.
That’s exactly what [jamieiles] has done with the Oldland CPU. It’s an open source 32 bit CPU core that you can synthesize for use on an FPGA. Not only can you browse through all the Verilog code in the Github repo, but there’s also a bunch of tools for working with this CPU core.
Included with the package is oldland-rtlsim, which lets you simulate the processor on a PC. The oldland-debug tool lets you connect to the processor for programming and debugging over JTAG. Finally, there’s a GNU toolchain port that lets you build C code for the device.
Going one step futher, [jamieiles] built a full SoC around the Oldland core. This has SPI, UART, timers, and more features you’d expect to find in a microcontroller. It can be flashed to the relatively cheap Terasic DE0-Nano board.
[jamieiles] has also ported u-boot to the processor, and the next thing on the list is the Linux kernel. If you’ve ever been interested in how CPUs actually work, this is a neat project to look through. If you want more open source CPU cores, check out OpenCores.
Fans of [Ben Heck] know that he has a soft spot for pinball machines and his projects that revolve around that topic tend to be pretty epic. This is a good example. At a trade show he saw an extra-wide format LCD screen which he thought would be perfect on a pinball build. He found out it’s a special module made for attaching to your car’s sun visor. The problem is that it only takes composite-in and he wanted higher quality video than that offers. The solution: reverse engineer the LCD protocol and implement it in an FPGA.
This project is a soup to nuts demonstration of replacing electronics drivers; the skill is certainly not limited to LCD modules. He starts by disassembling the hardware to find what look like differential signaling lines. With that in mind he hit the Internet looking for common video protocols which will help him figure out what he’s looking for. A four-channel oscilloscope sniffs the signal as the unit shows a blue screen with red words “NO SIGNAL”. That pattern is easy to spot since the pixels are mostly repeated except when red letters need to be displayed. Turns out the protocol is much like VGA with front porch, blanking, etc.
With copious notes about the timings [Ben] switches over to working with a Cyclone III FPGA to replace the screen’s stock controller. The product claims 800×234 resolution but when driving it using those parameters it doesn’t fill the entire screen. A bit more tweaking and he discovers the display actually has 1024×310 pixels. Bonus!
It’s going to take us a bit more study to figure out exactly how he boiled down the sniffed data to his single color-coded protocol sheet. But that’s half the fun! If you need a few more resources to understand how those signals work, check out one of our other favorite FPGA-LCD hacks.
Continue reading “Reverse Engineer then Drive LCD with FPGA”
[Stephen] designed a standalone Ambilight clone built around an FPGA and recently added many new features to make his design even better. His original design was based around a Spartan 3-E FPGA, but his new design uses the Papilio One board with a Spartan-6 LX9 FPGA. This gives him dedicated DSP hardware and more RAM, allowing him to add more processing-intensive features.
[Steven]’s new board can drive up to 4096 LEDs total, and each LED is colored from one of 256 segmented screen areas. The output of the LEDs is smoothed over a configurable time period which makes the result a bit more pleasant. [Steven] also added color correction matrices and gamma correction tables to make up for differences in LED coloration and so the output can be fine-tuned to the color of the wall behind the TV.
Finally, [Steven] added multiple configurations which can be stored in Flash memory. The FPGA can detect letterboxes and pillarboxes in the video stream and change to a corresponding configuration automatically, so settings rarely need to be manually adjusted. He also added an extensive serial interface to configure all of the parameters and configurations in Flash. Be sure to check out the video after the break to see his setup in action.
Continue reading “FPGA Ambilight Clone Packs a Ton of Features”
Somewhere down the road, you’ll find that your almighty autonomous robot chassis is going to need some sensor feedback. Otherwise, that next small step down the road may end with a blind leap off the coffee table. The first low-cost sensors we might throw at this problem would be sonars or IR rangefinders, but there’s a problem: those sensors only really provide distance data back from the pinpoint view directly ahead of them.
Rest assured, [Jonathan] wrote in to let us know that he’s got you covered. Combining a line laser, camera, and an FPGA, he’s able to detect obstacles that fall within the field of view of the camera and laser.
If you thought writing algorithms in software is tricky, wait till to you try hardware! (We know: division sucks!) [Jonathan] knows no fear though; he’s performing gradient computation on the FPGA directly to detect the laser in the camera image at a wicked 30 frames-per-second. Why roll up your sleeves and take the hardware route, you might ask? If we took a CPU-based approach at the tiny embedded-robot scale, Jonathan estimates a mere 10 frames-per-second. With an FPGA, we’re able to process images about as fast as they’re received.
Jonathan is using the Logi Board, a Kickstarter success we’ve visited in the past, and all of his code is up on the Githubs. If you crack it open, you’ll also find that many of his modules are Wishbone compliant, so developing your own projects with just some of these parts has been made much easier than trying to rip out useful features from a sea of hairy logic.
With computer-vision hardware keeping such a low profile in the hobbyist community, we’re excited to hear more about [Jonathan’s] FPGA-based robotics endeavors.
Continue reading “Robot Vision: Detecting Obstacles with FPGAs and line lasers”