Alvaro Prieto’s Laser-Shooting Robots

December 4, 2015 by Elliot Williams 4 Comments

[Alvaro Prieto]’s talk at the Hackaday Supercon began with a slide that asks the rhetorical question “Why Laser-Shooting Robots?” Does a rhetorical question need an answer? [Alvaro] gives one anyway: “Because lasers are awesome.” We concur.

But it doesn’t hurt that DEFCON holds a laser robot contest to give you an excuse, either. You see, [Alvaro]’s laser-wielding robot was the First Place finisher in the 2014 DEFCONBOTS contest, and a much more ambitious design came in third in 2015. His Supercon talk is all about the lessons he’s learned along the way, because that’s really the point of these contests anyway, right?

“I have no idea what I’m doing.”

[Alvaro] started off with a disclaimer, but when [Alvaro] says he doesn’t know what he’s doing, what he means is that he hasn’t received formal training in building laser-wielding, autonomous turret robots. (How did we miss that class in school?)

He’s a true hacker, though; he didn’t know what he was doing when he started out but he started out anyway. [Alvaro]’s takes us from the first prototypes where he used servo motors with inadequate angular resolution mounted to balsa wood frames that he (obviously) cut with a knife by hand, through laser-cut frames with custom gearing and stepper motors, all the way to his DEFCONBOTS 2015 entry, based on OpenBeam aluminum extrusions and using professional laser-show galvos capable of swinging the beam around to thousands of points per second.

Continue reading “Alvaro Prieto’s Laser-Shooting Robots” →

AirAsia Crash Analysis: Who Or What Failed?

December 4, 2015 by Rud Merriam 108 Comments

Just a few days after Christmas last year AirAsia Flight 8051 traveling to Singapore tragically plummeted into the sea. Indonesia completed its investigation of the crash and just released the final report. Media coverage, especially in Asia is big. The stories are headlined by pilot error but,as technologists, there are lessons to be learned deeper in the report.

The Airbus A320 is a fly-by-wire system meaning there are no mechanical linkages between the pilots and the control surfaces. Everything is electronic and most of a flight is under automatic control. Unfortunately, this also means pilots don’t spend much time actually flying a plane, possibly less than a minute, according to one report.

Here’s the scenario laid out by the Indonesian report: A rudder travel limit computer system alarmed four times. The pilots cleared the alarms following normal procedures. After the fifth alarm, the plane rolled beyond 45 degrees, climbed rapidly, stalled, and fell.

Continue reading “AirAsia Crash Analysis: Who Or What Failed?” →

Toward The Optionally Piloted Aircraft

December 4, 2015 by Mike Szczys 25 Comments

Aviation Week and Space Technology, the industry’s leading magazine, has been publishing “pilot reports,” on new aircraft for decades. Its pilot report on an aircraft called Centaur ⁠was the first in which the pilot doing the test never touched the controls. Centaur is an optionally-piloted aircraft, or OPA.

The reporter conducted the test while sitting in the back seat of the small, twin engine aircraft. Up front sat a person acting as the safety pilot, his arms calmly resting on his lap. Sitting beside him, in what is ordinarily the co-pilot’s seat, was an engineered series of linkages, actuators, and servos. The safety pilot pulled a lever to engage the mechanisms, and they began moving the pilot’s control stick and pressing the rudder pedals. The actuators are double and redundant; if one set fails another will immediately take over. The safety pilot can disengage the mechanism with a single pull of the lever if something goes wrong; unless something goes wrong he does not touch the controls.

In the back seat, the “operator,” commanded the plane through a laptop, using an interface identical to that of the ground control station for an unmanned vehicle. Through the screen, he could change altitude, fly to waypoints, takeoff or land. Pushing the “launch” button began an autonomous takeoff. The computer held the brakes, pushed the throttles forward, checked the engines and instruments, and released the brakes for the takeoff roll. The plane accelerated, took to the air, and began to climb out on a semi-autonomous flight.

Continue reading “Toward The Optionally Piloted Aircraft” →

Increasing Cable Length In Precision Video Applications

December 4, 2015 by Anool Mahidharia 23 Comments

Transmitting video signals over long distances can be tricky. Cheap co-ax cables won’t do the job. You either need amplifiers along the path, or need to use expensive, high quality shielded co-ax cables – both of which can end up costing a lot. [Maurizio] built a low cost solution to transmit video over long distances using twisted pair cables.

The system is cheap and uses readily available parts. The idea is to convert the video signal into a differential output using a pair of op amps and transmit them over a pair of twisted pair wires, then extract the signal at the receiving end using another amplifier.

A differential amplifier usually requires a dual-polarity power supply, which may not be available when adding this upgrade to an existing system. To over come this limitation, [Maurizio] uses a bias voltage equal to half of the power supply value. This bias voltage is added to the non-inverting amplifier signal, and subtracted from the inverting amplifier signal. The resultant differential signal is then fed into the twisted pair cable through impedance matching resistors. At the receiving end, a single amplifier receives the differential signals and outputs a signal that corresponds to the original video signal.

This symmetrical configuration renders the system immune to external noise. The design was tested for transmitting video on inexpensive CAT-3 twisted pair wire. According to him, when transmitting on 300m of wire, good quality color video was displayed on a monitor with an NTSC input. He used LMH6643 op-amps for this experiment, but other devices with similar characteristics can be used. Here’s a useful PDF document that discusses signals, cables and connections.

If you want to check out more of [Maurizio]’s work, see how he figured out how to send serial data from Excel.

Is Via Rail On Time?

December 4, 2015 by Eric Evenchick 25 Comments

Personally, I’m a fan of trains. They’re a nice, albeit slow, way to get around the country. Canada isn’t the best candidate for rail transit, given the rather large space between coasts, but Via Rail does operate regular train service in their corridor between Windsor and Quebec City.

Unfortunately, passenger rail has to yield to commercial rail in Canada which often causes delays. After noticing that some trains have very frequent delays, it seemed like it would be useful to know the average performance of each Via train. Via does not provide this data publicly.

However, they do provide some data about arrival and departure times. Digging into the data available through any browser viewing the Via Rail site, it was possible to query for past scheduled/actual arrival data. The result is TrainStats.ca, a display of Via’s on time performance. Join me after the break as I discuss how this all works, and how to pick a winner when buying your next train ticket.

Continue reading “Is Via Rail On Time?” →

A Teensy Logic Analyzer For A 6502

December 4, 2015 by Brian Benchoff 11 Comments

[John] has an interesting, if old piece of tech sitting on his workbench. It’s an Ohio Scientific C3-8P computer from the late 70s by way of a few garages, basements, and attics. As with most tech of this vintage, there are some problems, and [John] found debugging a little frustrating without the ability to trace and watch the programs. He needed a logic analyzer, and found one in an unlikely piece of hardware. [John] built one using a Teensy microcontroller, and further refinement of this project could turn it into a full in-system emulator.

The old Ohio Scientific computer [John] is trying to bring back from the dead is based on the 6502 CPU. That’s sixteen address lines to monitor, eight data lines, and four control lines. These were wired directly to a Teensy 3.1.

Reading and controlling all the signals from a 6502 is a task that falls to Linux. A command line program controls the Teensy and is capable of reading memory, setting trigger addresses, dumping the entire address space to a file, or just recording the last 5,000 clock cycles. This kind of tech existed back in the late 70s and early 80s. It also cost a fortune. Now, with a $20 Teensy and probably another $30 in ribbon cables and test clips, anyone can build a logic analyser for a very old computer system.

Videos below.

Continue reading “A Teensy Logic Analyzer For A 6502” →

El Cheapo Phased-Array Sonar

December 4, 2015 by Elliot Williams 14 Comments

Sonar is a great sensor to add to any small-scale robot project. And for a couple bucks, the ubiquitous HC-SR04 modules make it easy to do. If you’ve ever used these simple sonar units, though, you’ve doubtless noticed that you get back one piece of information only — the range to the closest object that the speaker is pointing at. It doesn’t have to be that way. [Graham Chow] built a simple phased-array using two SR04 modules, and it looks like he’s getting decent results.

The hack starts out by pulling off the microcontroller and driving the board directly, a hack inspired by [Emil]’s work on reverse engineering the SR04s. Once [Graham] can control the sonar pings and read the results back, the fun begins.

[Graham] uses TI’s Cortex M4F LaunchPad eval kit to generate a ping and receive the reflections. With normal sonar, the time between the ping being sent and its reception is determined by the range to the target. In a phased array, in this case just the two modules, the difference in the times it takes for the ping to return to each module is used to determine the angle to the target.

If you’re DSP-savvy, [Graham] is using a phase-shifted square wave signal so that the correlations of the sent and returned signals have better peaks. This also helps the peaks in correlation across the two SR04s in the array. We think it’s pretty awesome that [Graham] is resolving a couple of degrees in angular separation when he moved his wine bottle. With a couple more SR04 units, [Graham] could start to get height information back as well.

For not much scratch, [Graham] has himself an experimental setup that lets him play with some pretty heavy signal processing. We’re impressed, and can’t wait to see what’s next. Special thanks to [Graham] for posting up the code.

And thanks [João] for the tip!