For their Mechanical Engineering senior design project at San Jose State University, [Tyler Kroymann] and [Robert Dee] designed and built a racing motion simulator. Which is slightly out of the budget of most hackers, so before they went full-scale, a more affordable Arduino powered Stewart platform proof of concept was built. Stewart platforms typically use six electric or hydraulic linear actuators to provide motion in six degrees of freedom (6 DOF), surge (X), sway (Y), heave (Z), pitch, roll, and yaw. With a simple software translation matrix, to account for the angular displacement of the servo arm, you can transform the needed linear motions into PWM signals for standard hobby servos.

The 6 DOF platform, with the addition of a resistive touch screen, also doubled as a side project for their mechatronic control systems class. However, in this configuration the platform was constrained to just pitch and roll. The Arduino reads the resistive touch screen and registers the ball bearing’s location. Then a PID compares this to the target location generating an error vector. The error vector is used to find an inverse kinematic solution which causes the actuators to move the ball towards the target location. This whole process is repeated 50 times a second. The target location can be a pre-programmed or controlled using the analog stick on a Wii nunchuck.

Watch the ball bearing seek the target location after the break.

Thanks to [Toby] for sending in this tip.

We at Hackaday look forward to the real life implementation of Marble Madness!

Need help Demystifying PID Control? Or perhaps you would like to build your own Stewart Platform?

Read more on MAKE

Read more on MAKE

Everyone has a bad day right? Monday was a particularly bad day for the folks at Sparkfun. Customer support tickets started piling up, leading to the discovery that they had shipped out as many as 1,934 MicroViews without bootloaders.

MicroView is the tiny OLED enabled, Arduino based, microcontroller system which had a wildly successful Kickstarter campaign earlier this year. [Marcus Schappi], the project creator, partnered up with SparkFun to get the MicroViews manufactured and shipped out to backers. This wasn’t a decision made on a whim, Sparkfun had proven themselves by fulfilling over 11,000 Makey Makey boards to backers of that campaign.

Rather than downplay the issue, Sparkfun CEO [Nathan Seidle] has taken to the company blog to explain what happened, how it happened, and what they’re going to do to make it right for their customers. This positions them as the subject of our Fail of the Week column where we commiserate instead of criticize.

First things first, anyone who receives an effected MicroView is getting a second working unit shipped out by the beginning of November. Furthermore, the bootloaderless units can be brought to life relatively easily. [Nate] provided a hex file with the correct bootloader. Anyone with an Atmel AVR In-System Programming (ISP) programmer and a steady hand can bring their MicroView to life. Several users have already done just that. The bootloader only has to be flashed via ISP once. After that, the MicroView will communicate via USB to a host PC. Sparkfun will publish a full tutorial in a few weeks.

Click past the break to read the rest of the story.

So what went wrong? The crux of the problem is a common one to manufacturing: An incomplete production test. For many of their products, Sparkfun loads a single hex file containing the production test and the optiboot bootloader. The test code proves out the functionality of the device, and the bootloader allows the customer to flash the device with their own sketches. The problem is the bootloader normally connects to a PC host via USB. Enumerating a USB connection can take up to 30 seconds. That’s way too slow for volume production.

Sparkfun opted to skip the bootloader test, since all the pins used to load firmware were electrically tested by their production test code. This has all worked fine for years – until now. The production team made a change to the test code on July 18th. The new hex file was released without the bootloader. The production test ran fine, and since no one was testing the bootloader, the problem wasn’t caught until it was out in the wild.

The Sparkfun crew are taking several steps to make sure this never happens again.They’re using a second ATmega chip on their test fixture to verify the bootloader without the slow PC enumeration step. Sparkfun will also avoid changing firmware during a production run. If firmware has to change, they’re planning to beta test before going live on the production line. Finally, Sparkfun is changing the way they approach large scale production. In [Nathan's] own words:

Moving from low volume to mid-volume production requires a very different approach. SparkFun has made this type of mistake before (faulty firmware on a device) but it was on a smaller scale and we were agile enough to fix the problem before it became too large. As we started producing very large production runs we did not realize quality control and testing would need very different thinking. This was a painful lesson to learn but these checks and balances are needed. If it didn’t happen on Microview it would have happened on a larger production run someday in the future.

Everyone has bad days, this isn’t the first time Sparkfun has lost money due to a mistake. However, they’re doing the right thing by attacking it head on and fixing not only the immediate issue but the underlying thought process which allowed the problem to arise.

Read more on MAKE

[Peter Bjornx] brings classic microprocessors and modern microcontrollers together with his Arduino bootstrapped 68008 computer. The Motorola 68008 is the 8-bit external bus version of the well-known 68000 (or 68k) microprocessor. A friend gave [Peter] one of these chips, so he built a simple computer around it.

This isn’t one of those clean retrocomputers with every connection carefully planned out and wire wrapped. [Peter's] created a true hack – a working 68k system on a breadboard created with whatever he had on hand at the time. The real gem of this system is the ROM. [Peter] replaced an EPROM chip with an Arduino.

In the not-so-good-old-days, microprocessors (and many microcontrollers) ran from an external ROM chip. This often was a UV-erasable EPROM. Carefully compiled code was burned into the EPROM with a device programmer. If the code wasn’t perfect, the EPROM had to be pulled and placed under a UV lamp for 20 minutes or so to erase it before it was time to try again. EPROM emulators were available, but they were way too expensive for the hobbyist.

Thankfully those days are far behind us now with the advent of EEPROM and then Flash. [Peter] didn’t want to revisit the past either, so he wrote a simple Arduino sketch which allowed it to act as an EPROM emulator, including address logging via the serial port.

The design still caused [Peter] some headaches, though. His major problem was a classic 68k issue, /DTACK timing. /DTACK or Data Transfer Acknowledge is one of several bus control signals used by the 68k. When the 68k performs a read from the data bus, it waits for /DTACK before it transfers data. The Arduino was too slow to release /DTACK in this case, which caused the 68k to think every read was immediately completed. There is a much clearer explanation of the 68k bus cycles on this Big Mess O Wires page. [Peter's] solution was simple – a D flip-flop connected to the address strobe took care of the timing issues.

It took quite a bit of tinkering, but the system eventually worked. Peter was able to run the 68008 from its reset vector into a simple loop using the Arduino. It’s only fitting that the 68k program loaded by the Arduino was an LED blinker, everyone’s favorite hardware Hello World.

Thanks [Robert!]

Read more on MAKE

Read more on MAKE

After five weekends of work, [Alex] completed his automatic drink maker, the RumBot. What makes this automated bartender different from others is the fact that it is fast. VERY fast. It can serve drinks to five different locations in as little as 3 seconds per drink. By [Alex]‘s estimation, this could keep a party of 100 people going without anyone waiting on a drink.

The RumBot can make either of five pre-programmed drinks at varying levels of alcoholic intensity, ranging from 1 (“Virgin”) to 10. And for that extra push over the cliff, you can turn the knob to 11 (“Problem”).

Drink selection itself is handled by a simple digital I/O on an Arduino with a 1950s-styled user interface. The frame is built out of wood and uses 3D Printed plastic parts. It houses a very robust servo on a belt stage to move the drink nozzle, and special sensors placed at either of the five drink locations detect a cup ready to be filled. Any cup placed at any of the positions will automatically be filled based on the RumBot’s settings at any particular time.

Based on the quality of the build and the increased speed of this automatic drink maker, this should be a huge hit at any party. With all the knobs turned to 11 though, it might be a good idea to have a breathalyzer on hand! All of the code and schematics for the project are available at the project site as well.

We are excited to announce that OpenTracker v2 by Tigal is our new partner in the Arduino At Heart Program and ready to be backed in an Indiegogo campaign.

OpenTracker is a  fully open source commercial grade GPS/GLONASS vehicle tracker that comes with a free web interface for tracking it on Googlemaps or OpenStreetMaps.

The interface allows the tracking of a single vehicle or larger fleets simultaneously: currently it is possible to track the location, speed, altitude, heading, and address of the vehicle as well as save logs of location data for later use. With additional sensors it is also possible to track humidity, temperature and other parameters when desired.

The OpenTracker v2 is the second version of the original OpenTracker with many improved features, and a significant reduction in price.

Let’s have a look at some tech specs. The OpenTracker v2 is ready to run out-of-the-box and includes the same powerful 32-bit ATMEL SAM3A8C ARM controller as the Arduino Due, a Quectel M95 GSM/GPRS modem for wireless connectivity, a Quectel L76 GPS/GLONASS module with Assisted GPS, CAN-BUS, plenty of I/O options and a wide operating temperature range of -35°C to +80°C. The included CAN-BUS, plentiful I/O and on-board GSM/GPRS modem can be used to create many interesting applications such as CAN-BUS logger, SMS Gateway, SMS Remote Controller, and Weather Station with SMS notifications to name a few.

The OpenTracker v2 is available as a complete bundle including the Board, High-Quality Aluminum Enclosure, Power and Programming Cable as well as a GSM/GPS Antenna, or as a stand-alone board for those interested in using the board as an enhanced Arduino Due. The free online tracking interface is available at opentracker.tigal.com.

Support them on Indiegogo! (only a couple of days left but it’s flexible funding and going ahead with the manufacturing in any case!)