We’ve been keeping tabs on the progress SpaceX has made toward landing a rocket so that it can be reused for future orbital launches. As you would imagine, this is incredibly difficult despite having some of the world’s greatest minds working on the task. To become one of those minds you have to start somewhere. It turns out, high school students can also build guided rockets, as [ArsenioDev] demonstrates in his project on hackaday.io.
[Arsenio]’s design targets amateur rockets with a fuselage diameter of four inches or so. The main control module is just a cylinder with four servos mounted along the perimeter and some fancy 3D printed fins bolted onto the servo. These are controlled by an Arduino and a 6DOF IMU that’s able to keep the rocket pointing straight up. Staaaay on target.
We saw this project back at the Hackaday DC meetup a month ago, and [Arsenio] was kind enough to give a short lightning talk to the hundred or so people who turned up. You can catch a video of that below, along with one of the videos of his build.
The project took around 450 meters of RGB strips controlled by two Rainbowduinos and driven by sixty-four power Mosfets, sixty-four bipolar transistors, and a few other components. Producing white light from the LEDs draws 8 amps from the power supply.
The Rainbowduino is an ATmega328 Arduino compatible board with two MY9221 controllers. Each controller handles 12 channels of Adaptive Pulse Density Modulation. In other words, it makes the LEDs flash nicely. [Loren] used the Rainbowduino instead of some alternatives because multiple R’duinos can coordinate their activities over I2C.
The software part of the project did not work as well as the hardware. The light patterns were supposed to follow the music being played. A PC software package intended to drive the R’duinos produced just a muddy mess. Some kludges, including screen captures (!), driven by a batch file tamed the unruliness.
The Leap Motion controller is a rather impressive little sensor bar that is capable of generating a massive 3D point cloud and recognizing hands and fingers to allow for gesture control based computing. It’s been out for a few years now but we haven’t seen many hackers playing with it. [Anwaarullah] has messed around with it before, but when it came time to submit something for India’s first Maker Faire, he decided to try doing an actual project with it.
Checking out the latest Leap Motion SDK, [Anwaarullah] realized many improvements had been made and he’d have to rewrite some of his original code to reflect the changes. This time around he’s opted to use the ESP8266 WiFi module instead of a Bluetooth one. He printed off a Raptor hand (from the wonderful folks at e-NABLE) and hooked it up with some RC servos to give him a nice robotic hand to control.
Maker Faire Rome is over, and that means it’s time for the Arduino media blitz. Arduino has already had a big announcement this week with the introduction of the Arduino / Genuino 101 board powered by the Intel Curie module. Team .cc hasn’t forgotten all their Atmel-powered boards though. The latest news is that Arduinos will be manufactured in Germany by Watterott Electronics (.de, Google Translate).
Right now, Arduino.cc boards are manufactured in China by Seeed, and in the US by Adafruit and Sparkfun. Watterott Electronics is one of the premier hobby electronics distributors in Germany.
Boards made by Watterott will carry the Genuino mark; Arduino.cc seems to anticipate a loss in the Arduino vs. Arduino trademark dispute outside the US. All boards produced under license from Arduino.cc sold outside the US will carry the Genuino trademark, whereas boards produced for the US market will carry the Arduino trademark. Interestingly, this Arduino vs. Arduino split began with a former manufacturer, with a maelstrom of pettiness stemming from that trademark dispute. In any case, the licensing for boards manufactured by Watterott is most assuredly worked out by now. The new manufacturing partner guarantees a greater supply of Arduinos for all.
Range finders are amazing tools for doing pretty much anything involving distance calculations. Want to blink some lights when people are nearby? There’s a rangefinder for that. Need to tell how far away the next peak of a mountain range is? There’s a rangefinder for that. But if you’re new to range finders and want one that’s hackable and configurable, look no further than the SF02/F rangefinder with the Arduino shield, and [Laser Developer]’s dive into what this pair can do.
Once the rangefinder and shield have been paired is when the magic really starts to happen. Using USB, the Arduino can instantly report a huge amount of raw data coming from the rangefinder. From there, [Laser Developer] shows us how to put the device into a “settings” mode which expands the capabilities of the rangefinder even more. The data can be dumped into a graph, for example, which can show trends between distance, laser strength, and many other data sets. [Laser Developer] goes one step further and demonstrates how to use this to calculate the speed of light, but from there pretty much anything else is possible as well.
And while you can just buy a rangefinder off the shelf, they are fairly limiting in their features and can cost exponentially more. This is a great start into using a tool like this, especially if you need specific data or have a unique application. But, if laser range finding isn’t for you or if this project is too expensive, maybe this $5 ultrasonic rangefinder will work better for your application.
For over ten years, Arduino has held onto its popularity as “that small dev-board aimed to get both artists and electronics enthusiasts excited about physical computing.” Along the way, it’s found a corner in college courses, one-off burning man rigs, and countless projects that have landed here. Without a doubt, the Arduino has a cushy home among hobbyists, but it also lives elsewhere. Arduino lives in engineering design labs as consumer products move from feature iterations into user testing. It’s in the chem labs when scientists need to get some sensor data into their pc in a pinch. Despite the frowns we’ll see when someone blinks an LED with an Arduino and puts it into a project box, Arduino is here to stay. I thought I’d dig a little bit deeper into why both artists and engineers keep revisiting this board so much.
Arduino, do we actually love to hate it?
It’s not unusual for the seasoned engineers to cast some glares towards the latest Arduino-based cat-feeding Kickstarter, shamelessly hiding the actual Arduino board inside that 3D-printed enclosure. Hasty? Sure. Crude, or unpolished? Certainly. Worth selling? Well, that depends on the standards of the consumer. Nevertheless, those exact same critical engineers might also be kicking around ideas for their next Burning Man Persistence-of-Vision LED display–and guess what? It’s got an Arduino for brains! What may seem like hypocrisy is actually perfectly reasonable. In both cases, each designer is using Arduino for what it does best: abstracting away the gritty details so that designs can happen quickly. How? The magic (or not) of hardware abstraction.
Meet HAL, the Hardware-Abstraction Layer
In a world where “we just want to get things blinking,” Arduino has a few nifty out-of-the-box features that get us up-and-running quickly. Sure, development tools are cross-platform. Sure, programming happens over a convenient usb interface. None of these features, however, can rival Arduino’s greatest strength, the Hardware Abstraction Layer (HAL).
A HAL is nothing new in the embedded world, but simply having one can make a world of difference, one that can enable both the artist and the embedded engineer to achieve the same end goal of both quickly and programmatically interacting with the physical world through a microcontroller. In Arduino, the HAL is nothing more than the collection of classes and function calls that overlay on top of the C++ programming language and, in a sense, “turn it into the Arduino programming language” (I know, there is no Arduino Language). If you’re curious as to how these functions are implemented, take a peek at the AVR directory in Arduino’s source code.
With a hardware abstraction layer, we don’t need to know the details about how our program’s function calls translate to various peripherals available on the Uno’s ATMEGA328p chip. We don’t need to know how data was received when Serial.available() is true. We don’t “need to know” if Wire.begin() is using 7-bit addressing or 10-bit addressing for slave devices. The copious amounts of setup needed to make these high-level calls possible is already taken care of for us through the HAL. The result? We save time reading the chip’s datasheet, writing helper functions to enable chip features, and learning about unique characteristics and quirks of our microcontroller if we’re just trying to perform some simple interaction with the physical world.
There are some cases where the HAL starts to break down. Maybe the microcontroller doesn’t have the necessary hardware to simultaneously drive 16 servos while polling a serial port and decoding serial data. In some cases, we can solve this issue by switching Arduino platforms. Maybe we actually do need three serial ports instead of one (Teensy 3.2). Maybe we do need pulse-width-modulation (PWM) capability on every pin (Due). Because of the hardware abstraction layer, the rest of the source code can remain mostly unchanged although we may be switching chip architectures and even compilers in the process! Of course, in an environment where developing code for the target platform does matter, it doesn’t make sense to go to such efforts to write the general-purpose code that we see in Arduino, or even use Arduino in the first place if it doesn’t have the necessary features needed for the target end-goal. Nevertheless, for producing an end-to-end solution where “the outcome matters but the road to getting there does not,” writing Arduino code saves time if the target hardware needs to change before getting to that end goal.
Of course, there’s also a price to pay for such nice things like speedy development-time using the HAL, and sometimes switching platforms won’t fix the problem. First off, reading the Arduino programming language documentation doesn’t tell us anything about the limitations of the hardware it’s running on. What happens, let’s say, if the Serial data keeps arriving but we don’t read it with Serial.read() until hundreds of bytes have been sent across? What happens if we do need to talk to an I2C device that mandates 10-bit addressing? Without reading the original source code, we don’t know the answers to these questions. Second, if we choose to use the functions given to us through the HAL, we’re limited by their implementation, that is, of course, unless we want to change the source code of the core libraries. It turns out that the Serial class implements a 64-byte ring buffer to hold onto the most recently received serial data. Is 64 bytes big enough for our application? Unless we change the core library source code, we’ll have to use their implementation.
Both of the limitations above involve understanding how the original HAL works and than changing it by changing the Arduino core library source code. Despite that freedom, most people don’t customize it! This odd fact is a testament to how well the core libraries were written to suit the needs of their target audience (artists) and, hence, Arduino garnered a large audience of users.
Pros of Bare-Metalspeak
Are there benefits to invoking the hardware directly? Absolutely. A few curious inquirers before us have measured the max pin-toggling frequency with digitalWrite to be on the order of ~100 KHz while manipulating the hardware directly results in a pin-toggling frequency of about 2 MHz, about 20 times faster. That said, is invoking the hardware directly worth it? Depends, but in many cases where tight timing isn’t a big deal and where the goal of a functional end-to-end system matters more than “how we got there,” then probably not! Of course, there are cases when tight timing does matter and an Arduino won’t make the cut, but in that case, it’s a job for the embedded engineer.
Use the HAL, Luke!
To achieve an end-to-end solution where the process of “how we got there” matters not, Arduino shines for many simple scenarios. Keep in mind that while the HAL keeps us from knowing too many details about our microcontroller that we’d otherwise find in the datasheet, I don’t proclaim that everyone throw out their datasheets from here on out. I am, however, a proponent of “knowing no more than you need to know to get the job done well.” If I’m trying to log some sensor data to a PC, and I discover I’ll be saving a few days reading a datasheet and configuring an SPI port because someone already wrote SPI.begin(), I’ll take an Arduino, please.
If you’ve rolled up your sleeves and pulled out an Arduino as your first option at work, we’d love to hear what uses you’ve come up with beyond the occasional side-project. Let us know in the comments below.
A lot of hacker projects start with education in mind. The Raspberry Pi, for example, started with the goal of making an affordable classroom computer. The Shrimp is a UK-based bare-bones Arduino targeted at schools. We recently saw an effort to make a 3D printed robotic platform aimed at African STEM education: The Azibot.
Azibot has 3D printed treads, a simple gripper arm, and uses an Arduino combined with Scratch. Their web site has the instructions on how to put together the parts and promises to have the custom part of the software available for download soon.