code

50 Articles

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.

The Hackaday 2015 Omnibus: A Puzzle So Dense, Even We Don’t Know The Answer

December 23, 2015 by 23 Comments

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.

EOT ACK BS
The first clue on the front cover of the 2015 Omnibus

Continue reading “The Hackaday 2015 Omnibus: A Puzzle So Dense, Even We Don’t Know The Answer” →

Decypering The Hackaday.io Illuminati

December 16, 2015 by 34 Comments

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 first person to make sense out of the patterns in static is [Moritz Walter]. What’s in the code? More codes. While that’s not really helpful, it is to be expected.

SecretCodes2The 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.

Use Your Mouse Pointer To Send Data

August 30, 2015 by 11 Comments

[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.

Continue reading “Use Your Mouse Pointer To Send Data” →