Multipurpose Robot For The Masses

June 8, 2016 by Bryan Cockfield 13 Comments

As the cost of almost every technology comes falling down, from electronics to batteries to even tools like 3D printers, the cost to build things formerly out of reach of most of us becomes suddenly very affordable. At least, that’s what [John Choi] has found by building a completely DIY general purpose robot for around $2000.

OK, so $2000 isn’t exactly “cheap” but considering that something comparable (like Baxter) costs north of what a new car would cost means that [John] has dropped the price for a general-purpose robot by an order of magnitude. And this robot doesn’t skimp on features, either. It has a platform that allows it to navigate rooms, two manipulating limbs with plenty of servos, a laptop “head” that allows for easy interface, testing, and programming, and an Arduino Mega that allows it to interface with any sensors or other hardware with ease. It’s also modular so it can be repaired and transported easily, and it uses open source software and open hardware so it’s easy to build on.

This robot is an impressive piece of work that should help bring this technology to more than just high-end factories and research labs. They’ve already demonstrated the robot watering plants, playing the piano, picking things up, and many other tasks. We’d say that they’re well on their way to their goal of increasing the number of students and hobbyists who have access to this technology. If the $2k price tag is still too steep, though, there are other ways of getting into robotics without diving headfirst into a Baxter-like robot.

Continue reading “Multipurpose Robot For The Masses” →

The Hacker Is The Future Of The Prosthetic: Hackers Helping Those In Need

June 8, 2016 by Gerrit Coetzee 4 Comments

In the show Full Metal Alchemist, there’s a city called Rush Valley whose main and only business are the high performance prostheses called Automail. Engineers roam the street in Rush Valley; the best have their own shop like that of the high-end clothiers in Saville Row. Of course; it’s all fantasy set in a slightly ridiculous Japanese cartoon, but while walking through this year’s Maker Faire I began to wonder if is a future that may come to be.

The problem with prosthetics is the sheer variety of injuries, body types, and solutions needed. If an injury is an inch higher or an inch lower it can have a big effect on how a prosthetic will interact with the limb. If the skin is damaged or the nerves no longer function a different type of prosthesis will be needed. Some prostheses are to replace a lost limb, others are to assist an ailing body in order to return it to normal function. More than a few are simply temporary aides to help the body along in its healing efforts. Unfortunately, this means that it’s often the case that larger companies only sell the prostheses people are most likely to need; the rarer cases are often left without a solution.

The e-Nable project doesn't mess around. — The e-Nable project doesn’t mess around.

However, we see hackers stepping up and not just working on the problems, but solving them. One of our semifinalists last year, openbionics, inspired one of the projects we’ll be talking about later. There are robotic legs. We met a guy at MRRF who has been 3D printing hands for his son from the E-nable project.

Along these lines, we saw two really cool projects at Maker Faire this year: The first is the Motor-Assistive Glove, or MAG. MAG is designed to help people with Peripheral Neropathy regain some use of their hands while they go through the lengthy road to recovery. Perhipheral Neuropathy is a disease, usually resulting from diabetes, toxin exposure, or infection, where the nerves are damaged in such a way that typically the hands and feet are no longer mobile or feel sensation in a useful way. Once the disease is in full swing, a previously able person will find themselves unable to do simple things like hold a can of soda or grasp a doorknob firmly enough to open it.

We had a chance to interview one of the members of the MAG team, [Victor Ardulov], which you can see in the following video. [Victor] and his group started a research project at the University of Santa Cruz to develop the Motor-Assistive Glove. The concept behind it is simple. People with Peripheral Neuropathy typically have some movement in their hands, but no strength. The MAG has some pressure sensors at the tips of the fingers. When the user puts pressure on the pad; the glove closes that finger. When the pressure is off; the glove opens. The concept is simple, but the path to something usable is a long one.

Continue reading “The Hacker Is The Future Of The Prosthetic: Hackers Helping Those In Need” →

Gcc: Some Assembly Required

June 8, 2016 by Al Williams 51 Comments

There was a time when you pretty much had to be an assembly language programmer to work with embedded systems. Yes, there have always been high-level languages available, but it took improvements in tools and processors for that to make sense for anything but the simplest projects. Today, though, high-quality compilers are readily available for a lot of languages and even an inexpensive CPU is likely to outperform even desktop computers that many of us have used.

So assembly language is dead, right? Not exactly. There are several reasons people still want to use assembly. First, sometimes you need to get every clock cycle of performance out of a chip. It can be the case that a smart compiler will often produce better code than a person will write off the cuff. However, a smart person who is looking at performance can usually find a way to beat a compiler’s generated code. Besides, people can make value trades of speed versus space, for example, or pick entirely different algorithms. All a compiler can do is convert your code over as cleverly as possible.

Besides that, some people just like to program in assembly. Morse code, bows and arrows, and steam engines are all archaic, but there are still people who enjoy mastering them anyway. If you fall into that category, you might just want to write everything in assembly (and that’s fine). Most people, though, would prefer to work with something at a higher level and then slip into assembly just for that critical pieces. For example, a program might spend 5% of its time reading data, 5% of its time writing data, and 90% of the time crunching data. You probably don’t need to recreate the reading and writing parts. They won’t go to zero, after all, and so even if you could cut them in half (and you probably can’t) you get a 2.5% boost for each one. That 90% section is the big target.

The Profiler

Sometimes it is obvious what’s taking time in your programs. When it isn’t, you can actually turn on profiling. If you are running GCC under Linux, for example, you can use the -pg option to have GCC add profiling instrumentation to your code automatically. When you compile the code with -pg, it doesn’t appear to do anything different. You run your program as usual. However, the program will now silently write a file named gmon.out during execution. This file contains execution statistics you can display using gprof (see partial output below). The function b_fact takes up 65.9% of CPU time.

If you don’t have a profiling option for your environment, you might have to resort to toggling I/O pins or writing to a serial port to get an idea of how long your code spends doing different functions. However you do it, though, it is important to figure it out so you don’t waste time optimizing code that doesn’t really affect overall performance (this is good advice, by the way, for any kind of optimization).

Assembly

If you start with a C or C++ program, one thing you can do is ask the compiler to output assembly language for you. With GCC, use a file name like test.s with the -o option and then use -S to force assembly language output. The output isn’t great, but it is readable. You can also use the -ahl option to get assembly code mixed with source code in comments, which is useful.

You can use this trick with most, if not all, versions of GCC. Of course, the output will be a lot different, depending. A 32-bit Linux compiler, a 64-bit Linux compiler, a Raspberry Pi compiler, and an Arduino compiler are all going to have very different output. Also, you can’t always figure out how the compiler mangles your code, so that is another problem.

If you find a function or section of code you want to rewrite, you can still use GCC and just stick the assembly language inline. Exactly how that works depends on what platform you use, but in general, GCC will send a string inside asm() or __asm__() to the system assembler. There are rules about how to interact with the rest of the C program, too. Here’s a simple example from the a GCC HOWTO document (from a PC program):

__asm__ ("movl %eax, %ebx\n\t"
"movl $56, %esi\n\t"
"movl %ecx, $label(%edx,%ebx,$4)\n\t"
"movb %ah, (%ebx)");

You can also use extended assembly that lets you use placeholders for parts of the C code. You can read more about that in the HOWTO document. If you prefer Arduino, there’s a document for that, too. If you are on ARM (like a Raspberry Pi) you might prefer to start with this document.

So?

You may never need to mix assembly language with C code. But if you do, it is good to know it is possible and maybe not even too difficult. You do need to find what parts of your program can benefit from the effort. Even if you aren’t using GCC, there is probably a way to mix assembly and your language, you just have to learn how. You also have to learn the particulars of your platform.

On the other hand, what if you want to write an entire program in assembly? That’s even more platform-specific, but we’ll look at that next time.

Continuous Delivery For Your ESP8266

June 8, 2016 by Elliot Williams 5 Comments

There’s nothing to be ashamed of. It’s a problem we all have. You change your code a lot — you can’t help it, you just need to tweak one last little bit. And then you have to go downstairs, fetch your ESP8266 module, plug it in to your computer, flash the new firmware in, and then run back down and re-install your wine-cellar temperature monitor. If only there were a way to continuously update your ESP8266 over the air, pulling new code down from your GitHub repository, automatically running your test suite on it, and then pushing it off to the ESP.

OK, it’s ridiculous overkill, but [squix] strung together a bunch of open-source continuous integration tools and made them work with the ESP8266. A simple PHP script connects the ESP to the rest of the web infrastructure.

[squix] says the word “security” in the same way that gin aficionados whisper “vermouth” over their Martinis. Which is to say, there is none. But for a home solution, or if you want to play around with continuous development, it’s a good start.

And this is a cool project because it makes use of the ESP8266 OTA (over-the-air) programming library to push the code across. And we do hate having to run around the house to update firmware.

So check it out if you want to push code to your ESP8266s without physically going to fetch them, or if you want to integrate your web development with your home deployment.

High Voltage Please, But Don’t Forget The Current

June 8, 2016 by Steven Dufresne 30 Comments

In high voltage applications involving tens of thousands of volts, too often people think about the high voltage needed but don’t consider the current. This is especially so when part of the circuit that the charge travels through is an air gap, and the charge is in the form of ions. That’s a far cry from electrons flowing in copper wire or moving through resistors.

Consider the lifter. The lifter is a fun, lightweight flying machine. It consists of a thin wire and an aluminum foil skirt separated by an air gap. Apply 25kV volts across that air gap and it lifts into the air.

Lifter flying with high voltage power supply

Lifter parts

So you’d think that the small handheld Van de Graaff generator pictured below, that’s capable of 80kV, could power the lifter. However, like many high voltage applications, the lifter works by ionizing air, in this case ionizing air surrounding the thin wire resulting in a bluish corona. That sets off a chain of events that produces a downward flowing jet of air, commonly called ion wind, lifting the lifter upward.

Continue reading “High Voltage Please, But Don’t Forget The Current” →

Metalized Gift Wrap Saves A Classic Keyboard

June 8, 2016 by Jenny List 16 Comments

What do you do when you decide that running CP/M on a Commodore 128 with a 5.25″ drive “Isn’t CP/M enough”? If you are [FozzTexx], you reach for your trusty TRS-80 Model II, with its much more CP/M-appropriate 8″ drive.

There was one small snag with the TRS-80 though, its keyboard didn’t work. It’s a capacitive device, meaning that instead of each key activating a switch, it contains a capacitive sensor activated by a piece of aluminized Mylar film on a piece of foam. Nearly four decades of decay had left the foam in [FozzTexx]’s example sadly deflated, leaving the keys unable to perform. Not a problem, he cast around for modern alternatives and crafted replacements from a combination of foam weather strip and metalized gift wrap.

Care had to be taken to ensure that the non-metalized side of the gift wrap faced the capacitive sensor pads, and that the weather strip used had the right thickness to adequately fill the gap. But the result was a keyboard that worked, and for a lot less outlay and effort than he’d expected. We would guess that this will be a very useful technique for owners of other period machines with similar keyboards.

What is CP/M, I hear you ask? Before there was Linux, Windows, and MacOS, there was DOS, and before DOS, there was CP/M. In the 1970s this was the go-to desktop operating system, running on machines powered by Intel’s 8080 and its derivatives like the Zilog Z80 in the TRS-80. When IBM needed an OS for their new PC they initially courted CP/M creators Digital Research, but eventually they hired a small software company called Microsoft instead, and the rest is history. Digital Research continued producing CP/M and its derivatives, as well as an MS-DOS clone and the GEM GUI that may be familiar to Atari ST owners, but were eventually absorbed into Novell in the 1990s.

We’ve featured a few capacitive keyboards here at Hackaday before, including this similar repair to a Compaq from the 1980s, and this look at a classic IBM terminal keyboard.

FPGA-and-Pi Colossus Smashes Your Codes!

June 8, 2016 by Elliot Williams 6 Comments

If it were sixty years ago, and you were trying to keep a secret, you’d be justifiably glad that [Ben North] hadn’t traveled back in time with his Raspberry-Pi-and-FPGA code-breaking machine.

We’ve seen a lot of Enigma builds here at Hackaday — the World War II era encryption machine captured our readers’ imaginations. But perhaps the more important machines to come out of cryptanalysis during that era were Turing’s electromechanical Bombe, because it cracked Enigma, and the vacuum-tube-based Colossus, because it is one of the first programmable electronic digital computers.

[Ben]’s build combines his explorations into old-school cryptanalysis with a practical learning project for FPGAs. If you’re interested in either of the above, give it a look. You can start out with his Python implementations of Colossus to get your foot in the door, and then move on to his GitHub repository for the FPGA nitty-gritty.

It’s also a cool example of a use for the XuLA2 FPGA board and its companion StickIt board that plug straight into a Raspberry Pi for programming and support. We haven’t seen many projects using these since we first heard about them in 2012. This VirtualBoy hack jumped out at us, however. It looks like a nice platform. Anyone else out there using one?