code

53 Articles

Tables Are Turned As Robots Assemble IKEA Furniture

June 19, 2018 by 15 Comments

Hackaday pages are rife with examples of robots being built with furniture parts. In this example, the tables are turned and robots are the masters of IKEA pieces. We are not silly enough to assume that these robots unfolded the instructions, looked at one another, scratched their CPUs, and began assembling. Of course, the procedure was preordained by the programmers, but the way they mate the pegs into the ends of the cross-members is a very human thing to do. It reminds us of finding a phone charging socket in the dark. This kind of behavior is due to force feedback which tell the robots when a piece is properly seated which means that they can use vision to fit the components together without sub-millimeter precision.

All the hardware used to make the IKEA assembler is publicly available, and while it may be out of the typical hacker price range, this is a sign of the times as robots become part of the household. Currently, the household robots are washing machines, smart speakers, and 3D printers. Ten years ago those weren’t Internet connected machines so it should be no surprise if robotic arms join the club of household robots soon. Your next robotics project could be the tipping point that brings a new class of robots to the home.

Back to our usual hijinks, here is a robot arm from IKEA parts and a projector built into a similar lamp. or a 3D printer enclosed in an IKEA cabinet for a classy home robot.

Continue reading “Tables Are Turned As Robots Assemble IKEA Furniture” →

Someone Set Us Up The Compiler Bomb

June 3, 2018 by 43 Comments

Despite the general public’s hijacking of the word “hacker,” we don’t advocate doing disruptive things. However, studying code exploits can often be useful both as an academic exercise and to understand what kind of things your systems might experience in the wild. [Code Explainer] takes apart a compiler bomb in a recent blog post.

If you haven’t heard of a compiler bomb, perhaps you’ve heard of a zip bomb. This is a small zip file that “explodes” into a very large file. A compiler bomb is a small piece of C code that will blow up a compiler — in this case, specifically, gcc. [Code Explainer] didn’t create the bomb though, that credit goes to [Digital Trauma].

Continue reading “Someone Set Us Up The Compiler Bomb” →

Running Programs On Paper

January 22, 2018 by 4 Comments

It’s a simple fact that most programs created for the personal computer involve the same methods of interaction, almost regardless of purpose. Word processors, graphics utilities, even games – the vast majority of interaction is performed through a keyboard and mouse. However, sometimes it can be fun to experiment with alternative technologies for users to interact with code – Paper Programs is an exciting way to do just that.

Paper Programs is a combination of a variety of existing technologies to create a way of interacting with code which is highly tangible. The setup consists of a projector, and a webcam which can see the projected area, combined with Javascript programs running in a browser. Programs can be edited in the browser, then printed out with special coloured dots around the page. When the page is placed in the projection area, these dots identify the unique program and are picked up by the webcam, and the server executes the relevant code, projecting back onto the page.

It’s a system that creates a very tactile way of interacting with a program – by moving the page around or placing different pages next to each other, programs can interact in various ways. The system is setup for collaboration as well, allowing users to edit code directly in the browser.

The project reminds us of earlier works on DIY multitouch screens, but with a greater focus on direct engagement with the underlying code. What other unique ways exist to interact with code? Let us know in the comments.

Continue reading “Running Programs On Paper” →

Educational Robot For Under $100

September 6, 2017 by 20 Comments

While schools have been using robots to educate students in the art of science and engineering for decades now, not every school or teacher can afford to put one of these robots in the hands of their students. For that reason, it’s important to not only improve the robots themselves, but to help drive the costs down to make them more accessible. The CodiBot does this well, and comes in with a price tag well under $100.

The robot itself comes pre-assembled, and while it might seem like students would miss out on actually building the robot, the goal of the robot is to teach coding skills primarily. Some things do need to be connected though, such as the Arduino and other wires, but from there its easy to program the robot to do any number of tasks such as obstacle avoidance and maze navigation. The robot can be programmed using drag-and-drop block programming (similar to Scratch) but can also be programmed the same way any other Arduino can be.

With such a high feature count and low price tag, this might be the key to getting more students exposed to programming in a more exciting and accessible way than is currently available. Of course, if you have a little bit more cash lying around your school, there are some other options available to you as well.

3D Printed Key-Code Is Plastic Digital Logic

April 6, 2017 by 31 Comments

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.

Continue reading “3D Printed Key-Code Is Plastic Digital Logic” →

Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates

January 2, 2017 by 24 Comments

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.

Continue reading “Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates” →

Toyota’s Code Didn’t Meet Standards And Might Have Led To Death

October 24, 2016 by 190 Comments

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.