Hackaday Prize Entry: A Better KVM Switch

Now it’s not uncommon to have a desktop and a laptop at a battlestation with tablets waiting in the wings. Add in a few Raspis, consoles, and various cheap computers, and it’s pretty easy to have an enormous number of machines and monitors on a desk. Traditionally, a KVM switch would be the solution to this, sharing a keyboard, mouse, and monitor with many different boxes, but this is an ugly solution. [frankstripod] has a device that fixes that with some interesting software and a few USB hacks.

[frankstripod] is in love with a program called Synergy this program combines the keyboard, mouse, and display of several computers over a network so you’ll only ever have to use one keyboard and mouse; it’s as simple as dragging your mouse from one computer to the other. There are a few limitations, though: keyboards don’t work until the OS has loaded (no BIOS access, then), it doesn’t work if the network is down, and setup can be complicated. This project aims to replace the ‘server’ part of a Synergy setup with a small, networkable KVM.

Right now the plan is to use a small embedded board running Linux to read a USB keyboard and switch the output between several computers. A few scripts detect the mouse moving from one screen to another, and a microcontroller switches USB output between each computer. If it sounds weird, you’re right, but it does work: [frank]’s 2014 Hackaday Prize project was a mouse that worked with two computers at once.


The 2015 Hackaday Prize is sponsored by:

Old Fluorescent Fixtures Turned Into Fill Lights

The Tymkrs are hard at work setting up their home studio, and since they’ll be shooting a few videos, they need some lights. The lights themselves aren’t very special; for YouTube videos, anything bright enough will work. The real challenge is making a mount and putting them in the right place, With a shop full of tools, making some video lights isn’t that hard and easily translates into a neat video project.

The lights began their lives as large fluorescent fixtures, the kind that would normally house long fluorescent tubes. The Tymkrs cut the metal reflector of this fixture in half, capped the ends with wood, and installed normal incandescent sockets in one end.

The inside of this reflector was coated with a reflective material, and a beautiful rice paper diffuser was glued on. The Tymkrs attached a metal bracket to these lights and screwed the bracket to the ceiling. There’s enough friction to keep the lights in one spot, but there’s also enough play in the joints to position them at just the right angle.

Continue reading “Old Fluorescent Fixtures Turned Into Fill Lights”

Transmitting HD Video From A Raspberry Pi

It’s been a few years since the RTL-SDR TV Tuner dongle blew up the world of amateur radio; it’s a simple device that listens in on digital television frequencies, but it’s one of those tools that’s just capable enough to have a lot of fun. Now, we have a transmitting dongle. It’s only being used to transmit live HDTV from a Pi, but that in itself is very interesting and opens up a lot of possible builds.

The key piece of hardware for this build is a UT-100C DVB-T modulator. It’s a $169 USB dongle capable of transmitting between 1200-1350 MHz, and with a special edition of OpenCaster it’s possible to transmit over-the-air TV. There’s no amplifier, so you won’t be sending TV very far, but it does work.

On the Raspberry Pi side of the build, the standard camera captures H.264 video with raspivid, which is converted to a DVB compliant stream using ffmpeg. These are well-worn bits of software in the Raspberry Pi world, and OpenCaster takes care of the rest.

While this seems like the perfect solution to completely overbuilt quadcopters, keep in mind transmitting on the 23cm band does require a license. Transmitting in the UHF TV bands is a bad idea.

New Part Day: SPI RAM and a Video Controller

Generating video signals with a microcontroller or old CPU is hard if you haven’t noticed. If you’re driving even a simple NTSC or PAL display at one bit per pixel, you’re looking at a minimum of around 64kB of RAM being used as a frame buffer. Most microcontrollers don’t have this much RAM on the chip, and the AVR video builds we’ve seen either have terrible color or relatively low resolution.

Here’s something interesting that solves the memory problem and also generates analog video signals. Yes, such a chip exists, and apparently this has been in the works for a very long time. It’s the VLSI VS23s010C-L, and it has 131,072 bytes of SRAM and a video display controller that supports NTSC and PAL output.

There are two chips in the family, one being an LQFP48 package, the other a tiny SMD 8-pin package. From what I can tell from the datasheets, the 8-pin version is only an SPI-based SRAM chip. The larger LQFP package is where the action is, with parallel and SPI interfaces to the memory, an input for the colorburst crystal, and composite video and sync out.

After looking at the datasheet (PDF), it looks like generating video with this chip is simply a matter of connecting an RCA jack, throwing a few commands to the chip over SPI, and pushing bits into the SRAM. That’s it. You’re not getting hardware acceleration, you’re going to have to draw everything pixel by pixel, but this looks like the easiest way to generate relatively high-resolution video with a single part.

Thanks [antibyte] for the tip on this one.

Retrotechtacular: The Early Days of CGI

We all know what Computer-Generated Imagery (CGI) is nowadays. It’s almost impossible to get away from it in any television show or movie. It’s gotten so good, that sometimes it can be difficult to tell the difference between the real world and the computer generated world when they are mixed together on-screen. Of course, it wasn’t always like this. This 1982 clip from BBC’s Tomorrow’s World shows what the wonders of CGI were capable of in a simpler time.

In the earliest days of CGI, digital computers weren’t even really a thing. [John Whitney] was an American animator and is widely considered to be the father of computer animation. In the 1940’s, he and his brother [James] started to experiment with what they called “abstract animation”. They pieced together old analog computers and servos to make their own devices that were capable of controlling the motion of lights and lit objects. While this process may be a far cry from the CGI of today, it is still animation performed by a computer. One of [Whitney’s] best known works is the opening title sequence to [Alfred Hitchcock’s] 1958 film, Vertigo.

Later, in 1973, Westworld become the very first feature film to feature CGI. The film was a science fiction western-thriller about amusement park robots that become evil. The studio wanted footage of the robot’s “computer vision” but they would need an expert to get the job done right. They ultimately hired [John Whitney’s] son, [John Whitney Jr] to lead the project. The process first required color separating each frame of the 70mm film because [John Jr] did not have a color scanner. He then used a computer to digitally modify each image to create what we would now recognize as a “pixelated” effect. The computer processing took approximately eight hours for every ten seconds of footage. Continue reading “Retrotechtacular: The Early Days of CGI”

The Making Of The Hackaday Prize Video

As you’re probably aware, there’s a video announcing the launch of The Hackaday Prize blocking the front page of Hackaday right now. This is by design, and surprisingly we haven’t gotten any complaints saying, ‘not a hack’ yet. I’m proud of you. Yes, all of you.

Making this video wasn’t easy. The initial plans for it were something along the lines of the new Star Wars trailer. Then we realized we could do something cooler. The idea still had Star Wars in it, but we were going for the classics, and not the prequels. As much as we love spending two hours watching a movie about trade disputes, we needed to go to Tatooine.

QV4A4035I just wanted to go to Toshi station

This meant building a prop. We decided on the moisture vaporators from Uncle Owen’s farm. It’s a simple enough structure to build at the Hackaspace in a weekend, and could be broken down relatively easily for transport to the shooting site. I’ve created a hackaday.io project for the actual build, but the basic idea is a few pieces of plywood, an iron pipe for the structural support, and some Coroplast and spray paint to make everything look like it’s been sitting underneath two suns for several decades.

Oh, I was the only person at the hackaspace that knew what greebles were. That’s not pertinent in any way, I’d just like to point that out.

The Suit

The vaporator is the star of the show, but we also rented a space suit. No one expected teflon-covered beta cloth when we were calling up costume rental places, but the suit can really only be described as a space-suit shaped piece of clothing. The inlet and outlet ports are resin, and the backpack is a block of foam. If anyone knows where we can get an Orlan spacesuit, or even a NASA IVA or Air Force high altitude suit, let us know.

Credits

[Matt Berggren] led the prop build and starred in the assembly footage. [Aleksandar Braic] and [Rich Hogben] rented a ridiculous amount of camera equipment. On set for the hijinks was [Aleksandar “Bilke” Bilanovic], [Brian Benchoff] (me), [Jasmine Bracket], [Sophi Kravitz], and [Mike Szczys].

Beating Super Hexagon with OpenCV and DLL Injection

Every few months a game comes along which is so addictive, players can’t seem to put it down – no matter how frustrating it may get. Last year one of those games was Super Hexagon. After fighting his way through several levels, [Val] decided that designing a bot to beat the game would be more efficient than doing it himself. Having played a few rounds of Super Hexagon ourselves, we can’t fault him on that front!

At its core, Super Hexagon is a simple game. Walls move from the screen edges toward a ship located near the center of the screen. The player uses the arrow keys to “orbit” the ship around a central shape. Avoid getting crushed by the walls, and you’re golden. However, the entire game board is constantly spinning, expanding, contracting, flashing, and generally doing things to disorient the player while ever more complex wall patterns move in to kill you. In short, Super Hexagaon makes Touhou bullet hell games look like a cakewalk.

The first step in beating the game is to capture the screen. [Val] tried Fraps and VLC, but lags of 2 seconds or more were not going to work. Then [Val] turned to DLL Injection. Super Hexagon calls the OpenGL function glutSwapBuffers() to implement double buffering. Every frame of the game is rendered in the background. Once rendering is complete glutSwapBuffers() is called to swap the buffers, and the process starts over again. [Val] changed the game code such that his own frame capture function would be called instead of glutSwapBuffers(). Once he was done capturing the game’s video buffer, [Val] then called the real glutSwapBuffers() function. It worked perfectly.

Now that he had an image, [Val] used OpenCV to process it. Although game is graphically very noisy, there are only a few colors used at any one time. It didn’t take much work to come up with an algorithm which would create a binary image of the walls and the ship itself.

step5[Val] cast rays from the center of each wall through the center of the screen. The ray which was longest before intersecting another wall would be the best escape route. This simple solution worked, but only for about 40 seconds. At that point, Super Hexagon would start throwing more complex patterns, and the AI would fail. The final solution was to create an accessibility condition which also took into account how much space was available between the various approaching walls. This new version of the AI was able to beat the game.

So was this a more efficient method than grinding through Super Hexagon manually? Since [Val] now knows all about DLL injection and OpenCV, we sure think it was!

Click past the break to see the [Val’s] bot in action!

Continue reading “Beating Super Hexagon with OpenCV and DLL Injection”