Tag Archives: hardware

Watch a fin-propelled underwater robot prototype

via Arduino Blog


The robotic prototype swimming under water propelled by fins, it was developed at the Control Systems and Robotics Laboratory of the Technological Educational Institute of Crete, in Heraklion (Greece) and it’s controlled by an Arduino Mega:

Each fin is comprised of three individually actuated fin rays, which are interconnected by an elastic membrane. An on-board microcontroller generates the rays’ motion pattern that result in the fins’ undulations, through which propulsion is obtained. The prototype, which is fully untethered and energetically autonomous, also integrates an IMU/AHRS unit for navigation purposes, a wireless communication module, and an on-board video camera. The video contains footage from experiments conducted in a laboratory test tank to investigate closed loop motion control strategies, as well as footage from sea trials.

the Arduino runs a custom-developed real time firmware that implements two Central Pattern Generator (CPG) networks to generate the undulatory motion profile for the robot’s fins. The robot  contains a  7.4V lipo battery powering also a Bluetooth module for wireless communication and a video camera to record footage of the missions.



Explore tangible interfaces with a wooden sequencer

via Arduino Blog


During the Physical Computing and Creative Coding course at School of Form a team composed by Ernest Warzocha, Jakub Wilczewski, Maciej Zelaznowski worked on a project starting from the keyword “the aesthetics of interaction”. With the help of their lecturers – Wies?aw Bartkowski and Krzysztof Golinski – they decided to rethink about typical button-like interface of audio sequencer and design a unique tangible interface for it.


The Wooden Sequencer runs on Arduino Uno and works by using familiarity of real objects and manipulating them similarly to the idea of Durell Bishop’s Marble Answering Machine:

Instead of regular buttons we created wooden discs (4×8 circles) that placed in holes generate audio sequence. Each line corresponds to different instrument and columns are responsible for time when sample is played. To know in which point at timeline our sequence plays there is hidden LED on top of each column that blink through wood and informs user which one is currently played.

To create good-looking round shapes of table we used CNC router at our university. After the milling process we connected all electronics with table and sensors for each hole. The core of our project is Arduino UNO with multiplexers and MP3 module. With rendered samples and build-in speakers our project doesn’t require computer plugged in.

Important and somehow unique in our sequencer is usage of IR reflective sensors to change played instrument sample. To decide which sample we want to play sensor recognizes different grayscale color and intensity of the reflected light at bottom of our discs – actually everything placed on table can generate sound. Creating grayscale-based controller is experimental way to interact with device. Furthermore, using grayscale palette might be great idea for MIDI instrument. For this project we used two colors to show the concept. It’s possible to add more but it’s more sensitive to non-constant background light.

Take a look at the video below and explore more pictures on Behance:

A development board for the STM32F042 TSSOP package

via Dangerous Prototypes


Andy Brown designed a development board for the STM32F042 in the TSSOP20 package:

Development board features

  • USB. The 042 series supports USB and although 32Kb is not a lot of space to include a USB driver and your application logic it does make sense to hook up those USB data lines and thereby enable USB device development.
  • Switching regulator. All the development boards that I’ve seen seem to use a low dropout regulator (LDO) to supply power to the MCU which means that they’re unable to supply much current to any peripherals that you’re prototyping. The discovery boards warn you not to draw more than 100mA and many of the 3rd party boards use one of the 1117 regulators which, with up to a 1A limit, look great on paper but the universally chosen SOT-223 package will burn up in smoke long before you get anywhere near that figure.
  • VDDA control.The discovery boards allow you to supply VDDA externally if required. I’d like to keep this ability.
  • Onboard 8MHz crystal. All the F0 series can be clocked from the internal high speed internal (HSI) 8MHz oscillator with an option to use an external 8Mhz crystal. I’ll include such a crystal on my board.
  • Onboard NPN transistor. I often need to use an NPN transistor as a low-side switch to control a load either requires too much current to power from a GPIO or is running from a different voltage level (e.g. 5V). I’ll include a simple transistor on this board configured ready to function as a switch.
  • A LED. Because, well, you know, blinky.

Project info at Andy Brown’s blog.

Check out the video after the break.

Make your DIY smart glasses running on Arduino

via Arduino Blog


Jordan Fung is a 13-year-old maker and programmer based in Hong Kong. He recently developed Arduino-based smart glasses called Pedosa Glass, which are able to activate, in this first release, a flashlight and a timer:

The Pedosa Glass is powered by a single Arduino Nano running an “operating system” developed by me.
There is a tiny FLCOS display in the front. The AV signal from the Arduino will be displayed on it. It is equipped with 3 push buttons, in which 2 of them are control buttons and one of them be the home button, also equipped with a super-bright white LED for use as a flashlight.


In the picture below you can explore the electronic scheme:

pedosa glass


Jordan is working hard to add new applications and features to the project but in the meanwhile he shared his work on a great tutorial on Instructables.

Winning the Console Wars – An In-Depth Architectural Study

via Hackaday » hardware

From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.

The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.

In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.

An Architectural Study of the Sega Genesis and Super Nintendo

The traditional comparison between two consoles is usually presented as a series of specs, a bunch of numbers, and tick marks indicating which system wins in each category. While this does illustrate the strengths and weaknesses of each console, it is a rhetorical technique that is grossly imprecise, given the different architectures. The usual benchmark comparison is as follows:


Conventional wisdom – and people arguing on the Internet – tells you that faster is better, and with the Sega console having a higher clock speed it’s capable of doing more calculations per second. Sure, it may not be able to draw as many sprites on the screen as the SNES, but the faster processor is what allowed the Genesis / Mega Drive to have ‘faster’ games – the Sonic series, for example, and the incredible library of sports games. It’s an argument wrapped up in specs so neatly this conventional wisdom has been largely unquestioned for nearly thirty years. Even the Internet’s best console experts fall victim to the trap of comparing specs between different architectures, and it’s complete and utter baloney.

Let’s take a look at one of these numbers – the CPU speed of the SNES and the Genesis/Mega Drive. The SNES CPU, a Ricoh 5A22 is based on the 65C816 core, an oft-forgotten 16-bit offshoot of the 6502 and related chips found in everything from the Apple II, Commodore 64, and even the original Nintendo NES. The 5A22 inside the SNES is clocked at around 2.68 MHz for most games. The Sega used a 68000 CPU clocked at 7.67 MHz. By comparing just these two numbers, the SNES wins, but this isn’t necessarily the truth.

In comparing the clock speed of two different CPUs, we’re merely looking at how frequently the bus is accessed, and not the number of instructions per second.

In the 68000, each instruction requires at least eight clock cycles to complete, whereas the 65C816 – like it’s younger 6502 brother – could execute an instruction every two or three clock cycles. This means the Sega could handle around 900,000 instructions per second, maximum. The SNES could compute around 1.7 Million instructions per second, despite it’s lower clock speed.

Even though the Sega console has a faster clock, it performs fewer instructions per second.

And so we come to the crux of the argument; the statistics of the great console wars, while not wrong, are frequently misinterpreted. How then do we decide an outcome?

The Architecture of the Sega Genesis / Mega Drive

While the Sega Genesis/Mega Drive is usually cited as having a 68000 CPU, this isn’t a complete picture of what’s going on inside the Sega console. In effect, the Genesis is a dual-processor computer with two CPUs dedicated to different tasks. The 68000 handles game logic and graphics, but surprisingly not much else. A Z80 — a CPU introduced a decade before the Genesis/Mega Drive — is used for reading the state of the game pads, and playing audio.

Interestingly, the Sega Genesis / Mega Drive contains most of the components of Sega’s earlier console, the Sega Master System. With the addition of a Power Base Converter, Master System games can be played while the 68000 CPU is in idle.

The  Architecture of the Super Nintendo


The SNES is a different beast entirely. Everything is controlled through the 5A22 / 65816 CPU. The controllers are fed right into the data lines of the 5A22, and DMA instructions are able to shuttle data between the two slightly different Picture Processing Units.

An interesting difference between the two consoles are the connections between the cartridge slot and various peripheral chips. Nearly the entire cartridge connector of the Sega machine is dedicated to the address and data lines for the 68000 CPU. While there are a few control signals thrown in, it’s not enough to allow the cartridge direct access to the video display unit or the FM synthesis chip.

The cartridge connector for the SNES, on the other hand, has direct access to one picture processing unit and the audio processor. The exploitation of this capability was seen in games ranging from Star Fox with it’s SuperFX chip, to Mega Man X games with its math coprocessor, to Super Mario RPG: Legend of the Seven Stars and its Super Accelerator 1 chip that is basically an upgraded version of the main SNES CPU, the 5A22.

Comparative designs, and who won the console wars

Time to make a holistic analysis of each competing platform. By far, the SNES is a more capable console; its cartridges are able to send data directly to the PPUs and audio processors, it’s faster, and there’s more work RAM, vRAM, and audio RAM.

The Sega 'Tower of Power'. Image credit /u/bluenfee
The Sega ‘Tower of Power’. Image credit /u/bluenfee

The Genesis / Mega Drive may be seen as more expandable thanks to the Sega CD (the first CD-ROM based game console, the Sega 32X), an upgraded coprocessor for the Genesis, backwards compatibility with a Master System Power Base converter, and a number of strange cartridges like Sonic and Knuckles with ‘lock-on’ technology. However, it’s actually the SNES that is more expandable. This is most certainly not the conventional wisdom, and the difference is due to how expandability was implemented in each console.

To add additional capabilities to the SNES, game designers would add new chips to the game cartridge. Star Fox famously exploited this with the SuperFX chip, and the list of SNES enhancement chips is deserving of its own entry in Wikipedia.

In comparison, the Genesis / Mega Drive could only be expanded through kludges – either through abusing the ASIC chip between the 68000 and Z80 CPUs, or in the case of the 32X add-on, bypassing the video display unit entirely.

In any event, this is purely an academic exercise. Games sell consoles, and Nintendo’s IP portfolio – even in the early 90s – included characters that had their own cartoons, live action movies, and cereals.

While this academic exercise is completely unimportant today – there probably won’t be a game console that ships with cartridges any more – it is an interesting case study on extendable computer design.

Filed under: computer hacks, Featured, hardware

Fail of the Week: OpenMV Kickstarter Project Hits Manufacturing Snag

via Hackaday » hardware

Making stuff is hard, especially when you are making lots of stuff. The OpenMV Cam project knows this, because it has hit a problem while putting together their cheap machine vision module. The problem is with the BGA solder balls that connect the image sensor to the main board.

openmv-thumbWe’ve covered this intriguing project before: the aim is to build a small, cheap module that can run image processing algorithms to easily give robots sight. The sensor is a Ball Grid Array (BGA) package, which means there are a grid of small solder balls on the back that form the electrical connections. It seems that some of these solder balls are oxidized, preventing them from melting and fusing properly with the board. This is called a head-in-pillow defect, because the ball behaves like your head when you lie down in bed. Your head squishes the pillow, but doesn’t merge into it. There are 38 balls on the OV26040 image sensor and even a single bad link means a failure.

The makers of the project have tried a number of solutions, but it seems that they may have to remake the ball links on the back of each sensor. That’s an expensive process: they say it will cost $7 for each, more than the actual sensor cost initially.

A few people have been posting suggestions in the comments for the project, including using solvents and changing the way the sensors are processed before mounting. We’d like to see them overcome this hurdle. Anybody have any suggestions to quickly and cost effectively move the manufacturing process forward?

Thanks to [eDgE] for the tip.

Filed under: Fail of the Week, Hackaday Columns, hardware