[Sam Miller], [Sahil Gupta], and [Mashrur Mohiuddin] worked together on a very fast LED matrix display for their final project in ECE 5760 at Cornell University.
They started, as any good engineering students, by finding a way to make their lives easier. [Sam] had built a 32×32 LED matrix for another class. So, they made three more and ended up with a larger and more impressive 64×64 LED display.
They claim their motivation was the love of music, but we have a suspicion that the true reason was the love all EEs share for unnaturally bright LEDs; just look at any appliance at night and try not be blinded.
The brains of the display is an Altera DE2-115 FPGA board. The code is all pure Verilog. The FFT and LED control are implemented in hardware on the FPGA; none of that Altera core stuff. To generate images and patterns they wrote a series of python scripts. But for us it’s the particle test shown in the video below that really turns our head. This system is capable of tracking and reacting to a lot of different elements on the fly why scanning the display at about 310 FPS. They have tested display scanning at twice that speed but some screen-wrap artifacts need to be worked out before that’s ready for prime time.
The team has promised to upload all the code to GitHub, but it will likely be a while before the success hangover blows over and they can approach the project again. You can view a video interview and samples of the visualizations in the videos after the break.
Thanks to their Professor, [Bruce Land], for submitting the tip! His students are always doing cool things. You can even watch some of his excellent courses online if you like: Here’s one on the AVR micro-controller.
The student projects that come out of [Bruce Land]’s microcontroller- and FPGA-programming classes feature here a lot, simple because some of them are amazing, but also because each project is a building-block for another. And we hope they will be for you.
This time around, [Junyin Chen] and [Ziqi Yang] created a five-in-a-row video game that is controlled by a pointing finger. A camera, pointed at the screen, films the player’s hand and passes the VGA data to an FPGA. And that’s where things get interesting.
An algorithm in the FPGA detects skin color and, after a few opening and closing operations, comes up with a pretty good outline of the hand. The fingertip localization is pretty clever. They sum up the number of detected pixels in the X- and Y-axis, and since a point finger is long and thin, locate the tip because it’s going to have a maximum value in one axis and a minimum along the other. Sweet (although the player has to wear long sleeves to make it work perfectly).
How does the camera not pick up the game going on in the background? They use a black-and-white game field that the skin-color detection simply ignores. And the game itself runs in a Nios embedded processor in the FPGA. There’s a lot more detail on the project page, and of course there’s a demo video below.
We love to follow along with Prof. Land‘s classes. His video series is invaluable, and the course projects have been an inspiration.
There are reports of a Tetris movie with a sizable budget, and with it come a plentiful amount of questions about how that would work. Who would the characters be? What kind of lines would there be to clear? Whatever the answers, we can all still play the classic game in the meantime. And, thanks to some of the engineering students at Cornell, we could play it without using a controller.
This hack comes from [Bruce Land]’s FPGA design course. The group’s game uses a video camera which outputs a standard NTSC signal and also does some filtering to detect the user. From there, the user can move their hands to different regions of the screen, which controls the movement of the Tetris pieces. This information is sent across GPIO to another FPGA which uses that to then play the game.
This game is done entirely in hardware, making it rather unique. All game dynamics including block generation, movement, and boundary conditions are set in hardware and all of the skin recognition is done in hardware as well. Be sure to check out the video of the students playing the game, and if you’re really into hand gesture-driven fun, you aren’t just limited to Tetris, you can also drive a car.
For their final project for ECE 5760 at Cornell, [Alex], [Sungjoon], and [Rameez] are solving Rubik’s Cubes. They’re doing it with an FPGA, with homebrew robot arms to twist and turn a rainbow cube into the correct position.
First, the mechanical portion of the build. The team are using a system of three robot arms positioned on the left, right, and back faces of the cube relative to a camera. When a cube is placed in the jaws of this robot, the NTSC camera data is fed into an FPGA, where a Nios II soft core handles the actual detection of the cube faces, the solver algorithm, and the controller to send servo commands to the robot arms.
The algorithm used for solving the cube is CFOP – solve the white cross, the white corners, the middle layer, the top face, and finally the entire cube. In practice, the robot ended up taking between 60-70 moves. This is not the most efficient algorithm; the Thistethwaite algorithm only requires 52 moves. There’s a reason for this apparent inefficiency – the Thistlethwaite algorithm requires large look-up tables.
Once the cube is scanned and the correct moves are computed, the soft core in sends commands out through the FPGA’s GPIO pins. Each cube can be solved in under three minutes after it has been scanned, but the team ran into problems with scanning accuracy. It’s a problem that can be fixed with the right lighting setup and better aberrant cubie detection, and a great final project using FPGAs.
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!
Whether you are trying to drop some fat or build some muscle, it’s important to track progress. It’s easy enough to track your weight, but weight doesn’t tell the whole story. You might be burning fat but also building muscle, which can make it appear as though you aren’t losing weight at all. A more useful number is body fat percentage. Students from Cornell have developed their own version of an electrical body fat analyzer to help track body fat percentage.
Fat free body mass contains mostly water, whereas fat contains very little water. This means that if you were to pass an electrical current through a body, the overall bioelectrical impedance will vary depending on how much fat or water there is. This isn’t a perfect system, but it can give a rough approximation in a relatively easy way.
The students’ system places an electrode on one hand and another on the opposite foot. This provides the longest electrical path possible in the human body to allow for the most accurate measurement possible. An ATMega1284P is used to generate a 50kHz square wave signal. This signal is opto-isolated for user safety. Another stage of the circuit then uses this source signal to generate a 10ua current source at 50kHz. This is passed through a human body and fed back to the microcontroller for analysis.
The voltage reading is sent to a MATLAB script via serial. The user must also enter in their weight and age. The MATLAB script uses these numbers combined with the voltage reading to estimate the body fat percentage. In order to calibrate the system, the students measured the body fat of 12 of their peers using body fat calipers. They admit that their sample size is too small. All of the sample subjects are about 21 years old and have a similar body fat percentage. This means that their system is currently very accurate for people in this range, but likely less accurate for anyone else. Continue reading “DIY Electrical Body Fat Analyzer”→
A team of Cornell students have designed and built their own electronic boxing trainer system. The product of their work is a game similar to Whack-A-Mole. There are five square pads organized roughly into the shape of a human torso and head. Each pad will light up based on a pre-programmed pattern. When the pad lights up, it’s the player’s job to punch it! The game keeps track of the player’s accuracy as well as their reaction time.
The team was trying to keep their budget under $100, which meant that off the shelf components would be too costly. To remedy this, they designed their own force sensors. The sensors are basically a sandwich of a few different materials. In the center is a 10″ by 10″ square of ESD foam. Pressed against it is a 1/2″ thick sheet of insulating foam rubber. This foam rubber sheet has 1/4″ slits cut into it, resulting in something that looks like jail bars. Sandwiching these two pieces of foam is fine aluminum window screen. Copper wire is fixed the screen using conductive glue. Finally, the whole thing is sandwiched between flattened pieces of corrugated cardboard to protect the screen.
The sensors are mounted flat against a wall. When a user punches a sensor, it compresses. This compression causes the resistance between the two pieces of aluminum screen to change. The resistance can be measured to detect a hit. The students found that if the sensor is hit harder, more surface area becomes compressed. This results in a greater change in resistance and can then be measured as a more powerful hit. Unfortunately it would need to be calibrated depending on what is hitting the sensor, since the size of the hitter can throw off calibration.