3D printers are great for creating static objects, but if you’re clever, it’s possible to print functional devices. If you’re absolutely brilliant you can go far beyond that, which is the case here. This door handle with a key-code lock does it all with 3D printing using mechanism designs that look like alien technology. This is just one application of a much more interesting mechanical digital logic they’re developing (PDF).
Working from the [Hasso-Plattner-Institut], the research team is focusing on metamaterials as mechanisms in and of themselves. The crux of this lock is a series of bistable springs that — if the correct code is entered — will trigger in series to unlock the door. The project builds on the grid of shearing cells seen in the door handle we featured last year. It happens quickly in the video, but the intricate cascade of the handle unlocking is a treat to witness.
It’s a fascinating show of mechanical design. The common elements of digital electronics are all present: set or unset bits, logic gates, propagation issues, the whole works. But there are added challenges in this system, like the need for special cells that can turn the logic chain by 90 degrees and split the signal into more than one part.
This signal splitting is seen in the upper right (bifurcation) and leads into what is in effect an amplifier. The locking bolt must be moved twice the distance of a normal cell, so a dual-cell input is necessary to offset the loss of force from the incoming smaller cells. Cognitively we understand this, but we’re still trying to gain an intuitive sense of the amplifer mechanism.
One thing’s for sure, the overall concept is far cooler than this admittedly awesome door lock mechanism. The paper is worth your time for a deep dive. It mentions their design editor software. You can play with it online but we don’t think it’s been updated to include the new logic cells yet.
Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips. Amongst other hardware, Java Grinder supports the Commodore 64, which uses a variant of the 6502 CPU. [Michael Kohn] realized the Atari 2600 shares this processor, and figured he’d get started on making Java Grinder work with the Atari by expanding on the C64 work done by [Joe Davisson]. Together, they brought Java to the Atari 2600 and made a game along the way.
According to [Michael], parts of the project were easy, as some Java routines compile down into as little as 1 or 2 instructions on the 6502. Other parts were harder, like dealing with the graphics subsystem, and modifying Java Grinder to output 8-bit bytecode to fit into the Atari’s tiny 4K ROM limit. Even with this tweak, they still couldn’t fit in a game and title screen. In the end they relied on bank switching to get the job done. [Joe]’s game is pretty solid fare for the Atari 2600 — blocky graphics and bleepy sounds — and they’ve uploaded it to the page so you can try it yourself in an emulator.
At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430. Video after the break.
We were initially skeptical of this article by [Aleksey Statsenko] as it read a bit conspiratorially. However, he proved the rule by citing his sources and we could easily check for ourselves and reach our own conclusions. There were fatal crashes in Toyota cars due to a sudden unexpected acceleration. The court thought that the code might be to blame, two engineers spent a long time looking at the code, and it did not meet common industry standards. Past that there’s not a definite public conclusion.
[Aleksey] has a tendency to imply that normal legal proceedings and recalls for design defects are a sign of a sinister and collaborative darker undercurrent in the world. However, this article does shine a light on an actual dark undercurrent. More and more things rely on software than ever before. Now, especially for safety critical code, there are some standards. NASA has one and in the pertinent case of cars, there is the Motor Industry Software Reliability Association C Standard (MISRA C). Are these standards any good? Are they realistic? If they are, can they even be met?
When two engineers sat down, rather dramatically in a secret hotel room, they looked through Toyota’s code and found that it didn’t even come close to meeting these standards. Toyota insisted that it met their internal standards, and further that the incidents were to be blamed on user error, not the car.
So the questions remain. If they didn’t meet the standard why didn’t Toyota get VW’d out of the market? Adherence to the MIRSA C standard entirely voluntary, but should common rules to ensure code quality be made mandatory? Is it a sign that people still don’t take software seriously? What does the future look like? Either way, browsing through [Aleksey]’s article and sources puts a fresh and very real perspective on the problem. When it’s NASA’s bajillion dollar firework exploding a satellite it’s one thing, when it’s a car any of us can own it becomes very real.
Print is dead, so we put a skull on it. That’s the philosophy behind the 2015 Hackaday Omnibus, the printed collection of the best Hackaday has to offer.
We have a few ideas of where we would like to take the print edition of Hackaday. Mad magazine-style fold-ins are on the list, specifically a fold-in style schematic that does two completely different things. Remember when records were included as a magazine insert? Those are called flexi-discs, and there’s exactly one company that still does it. All of these and more are plans for the future, and for the 2015 Hackaday Omnibus, we chose to include something we’re all very familiar with: a puzzle. This is no ordinary puzzle – even we don’t know what the solution is.
A few months ago, a strange account popped up on hackaday.io. Whoever is behind this count is based in Bielefeld, Germany – a place that doesn’t exist. They are somehow related to the Berenstain / Berenstein Bears dimensional rift, and they may be responsible for giving Cap’n Crunch only three rank insignia on his uniform. There is something very, very strange about this account. Since August, a black and white image of static, 98 pixels wide and 518 pixels tall has sat on this account profile. The Illuminati has given us enough clues, but until now, no one has managed to crack the code.
The hackaday illuminati included one additional piece of information with their encoded static image: a 12×12 pixel bitmap. When this bitmap was XORed with the main image, symbols appeared. In total, there are only seven unique symbols in the image. These symbols seem to be stolen from the Fez alphabet, but there are some significant differences. These symbols are rotated multiples of 90 degrees, and are surrounded by a one pixel border that is either black or white (we’re calling the border a ‘sign’ bit). In total, these seven symbols arranged in four different rotations with two different signs yields forty unique variations of a symbol in the decoded image. At this point, it should be noted 7*2*4 = 56.
As of now, cracking the illuminati’s cyphered machinations has hit a roadblock. There’s a dead image file on the illuminati’s profile. Until that image is rehosted, there is no way to progress any further. That’s not going to stop people from trying, though: the chat channels on hackaday.io have been buzzing about the newly decrypted images. Hopefully, with time, someone will figure out what it all means.
[Ido Gendel] was thinking about new and interesting ways to send data between devices, when he realized that the answer was right in his hand. Literally: he decided to try sending data using the mouse pointer. What he came up with was an interesting hack that uses small movements of the mouse pointer to send data at up to 1200bps, or about 150 bytes per second.
The way he did this was very, very clever. He used an Arduino Leonardo that is set to emulate a mouse, working alongside his existing mouse. This setup means that he can use his existing mouse: the system just sees the Arduino as a second mouse, and the pointer just looks a little jerky when you zoom in. That is because the Arduino is just sending tiny movements, each of which is a code that represents a nybble (4 binary bits) of data. By using both a combination of three left-right or up-down movements, he was able to create 16 movements, each of which can encode 4 bits of data. Each of these encoding movements also returns the mouse to its origin point, so the mouse doesn’t mysteriously scroll off the screen when data is being sent.
The Hackaday Prize isn’t exclusively about building things that will help the planet; you can also build things that will enable others to build things to save the planet. [Eric] isn’t saving the world with his commonCode library, but it will make it vastly easier for other people to build the next great Thing.
The idea behind commonCode is the same as shared libraries you’ll find in any desktop application of reasonable size; it provides a common library for AVR microcontrollers to build just about anything. Bit manipulation, an interface for timers, math functions, graphics, I/O, and peripheral drivers are all available in the commonCode library. This makes it easy for the developmentally challenged among us to create whatever project they want.
The commonCode library wasn’t created just for The Hackaday Prize. [Eric] has been tinkering around with AVRs since well before the Arduino existed, and he has dozens of projects in permanent installations. It’s a great way to give back to the community, and the perfect way to allow people to develop their own things to solve whatever problem they have in mind.