While we’ve come a long way in terms of opening up the world of radio control to open source software, a good deal of the hardware itself is still closed up. You can flash a cheap RC transmitter with a community developed firmware, in fact there’s a decent chance that’s what it ships with, but the hardware itself is still an immutable black box. That might be fine if you’re just flying an RC plane or quadcopter, but what if you’ve got something a bit more advanced in mind?
From his personal experience, [Alireza] found that traditional RC transmitters have their limits when you start using them for robotics. You’ll often want input schemes or devices which would never occur to the remote’s designers, and you’ll almost certainly want to have more channels and functions than the original hardware will allow. One of the big advantages with the Alpha V1 is that the front and back of the controller are simple acrylic panels, meaning you can easily cut openings or drill holes in them to add more hardware without having to deal with the (relatively) ergonomic shapes of a traditional transmitter.
Of course, that’s only one half of the equation. When you add new hardware, you’ll need to make the software aware of it. To that end, [Alireza] says he and his team have developed a library of adaptable firmware modules which should make it very easy to add in new components without having to get bogged down with software configuration. In fact, he says the goal is to allow the user to add new hardware to the Alpha V1 without requiring them to write a single line of code.
If adding a cell modem is dealing with a drama queen of a hardware component, then choosing from among the many types of modules available turns the designer into an electronics Goldilocks. There are endless options for packaging and features all designed to make your life easier (or not!) so you-the-designer needs to have a clear understanding of the forces at work to come to a reasonable decision. How else will Widget D’lux® finally ship? You are still working on Widget D’lux®, aren’t you?
OK, quick recap from last time. Cell modems can be used to add that great feature known as The Internet to your product, which is a necessary part of the Internet of Things, and thus Good. So you’re adding a cell modem! But “adding a cell modem” can mean almost anything. Are you aiming to be Qualcomm and sue Apple build modems from scratch? Probably not. What about sticking a Particle Electron inside to bolt something together quickly? Or talk to Telit and put a bare modem on a board? Unless you’re expecting to need extremely high volume and have a healthy appetite for certification glee, I bet you’ve chosen to get a modem with as many existing certifications as possible, which takes us to where we are today. Go read the previous post if you want a much more elaborate discussion of your modem-packaging options and some of the trade offs involved. Continue reading “Finding the Goldilocks Cell Module”→
So you went to a tradeshow and heard about this cool new idea called the Internet Of Things; now it’s time to build an IoT product of your own. You know that to be IoT, your Widget D’lux® has to have a network connection but which to choose?
You could use WiFi or Bluetooth but that would be gauche. Maybe LoRaWAN? All the cool kids are using LoRa for medium or long range wireless these days, but that still requires a base station and Widget D’lux® will be a worldwide phenomenon. Or at least a phenomenon past your bedroom walls. And you know how much user’s hate setting things up. So a cell modem it is! But what do you have to do to legally include one in your product? Well that’s a little complicated.
The GePS is a musical project that shows how important integration work is when it comes to gesture controls. Creators [Cedric Spindler] and [Frederic Robinson] demonstrate how the output of a hand-mounted IMU (Inertial Measurement Unit) and magnetometer can be used to turn motion, gestures, and quick snap movements into musical output. The GePS is designed to have enough repeatability and low enough latency that feedback is practically immediate. As a result, it can be used and played like any other musical instrument that creates sound from physical movements in a predictable way. It’s not unlike a Theremin in that way, but much more configurable.
To do this, [Cedric] and [Frederic] made GePS from a CurieNano board (based on Intel’s Curie, which also has the IMU on-board) and an XBee radio for a wireless connection to software running on a computer, from which the sounds are played. The device’s sensitivity and low lag means that even small movements can be reliably captured, meaning that the kind of fluid and complex movements that hands do every day can be used as the basis for playing sounds with immediate feedback. In a very real sense, the glove-based GePS is an experimental kind of new instrument, which makes it a fascinating contender for the Musical Instrument Challenge portion of the 2018 Hackaday Prize.
Sensor network projects often focus primarily on electronic design elements, such as architecture and wireless transmission methods for sensors and gateways. Equally important, however, are physical and practical design elements such as installation, usability, and maintainability. The SENSEation project by [Mario Frei] is a sensor network intended for use indoors in a variety of buildings, and it showcases the deep importance of physical design elements in order to create hardware that is easy to install, easy to maintain, and effective. The project logs have an excellent overview of past versions and an analysis of what worked well, and where they fell short.
One example is the power supply for the sensor nodes. Past designs used wall adapters to provide constant and reliable power, but there are practical considerations around doing so. Not only do power adapters mean each sensor requires some amount of cable management, but one never really knows what one will find when installing a node somewhere in a building; a power outlet may not be nearby, or it may not have any unoccupied sockets. [Mario] found that installations could take up to 45 minutes per node as a result of these issues. The solution was to move to battery power for the sensor nodes. With careful power management, a node can operate for almost a year before needing a recharge, and removing any cable management or power adapter meant that installation time dropped to an average of only seven minutes.
That’s just one example of the practical issues discovered in the deployment of a sensor network in a real-world situation, and the positive impact of some thoughtful design changes in response. The GitHub repository for SENSEation has all the details needed to reproduce the modular design, so check it out.
There are a multitude of radio shields for the Arduino and similar platforms, but they so often only support one protocol, manufacturer, or frequency band. [Jan Gromeš] was vexed by this in a project he saw, so decided to create a shield capable of supporting multiple different types. And because more is so often better, he also gave it space for not one, but two different radio modules. He calls the resulting Swiss Army Knife of Arduino radio shields the Kite, and he’s shared everything needed for one on a hackaday.io page and a GitHub repository.
Supported so far are ESP8266 modules, HC-05 Bluetooth modules, RFM69 FSK/OOK modules, SX127x series LoRa modules including SX1272, SX1276 and SX1278, XBee modules (S2B), and he claims that more are in development. Since some of those operate in very similar frequency bands it would be interesting to note whether any adverse effects come from their use in close proximity. We suspect there won’t be because the protocols involved are designed to be resilient, but there is nothing like a real-world example to prove it.
Sometimes great projects keep evolving. [Bithead942] built himself an R2-D2 to accompany him when he goes a-trooping — but something didn’t feel quite right. Turns out, R2 was missing its signature beeping banter, so he made it more contextually responsive by implementing a few voice commands.
[Bithead942]’s main costume is that of an X-Wing pilot, and the replica helmet works perfectly; it already has a fake microphone — easily replaced with a working model — and the perfect niche to stash the electronics in the ‘mohawk.’
Even though the helmet has the perfect hiding spot for a circuit, space is still at a premium. Services like Alexa tend to be pretty accurate, but require WiFi access — not a guarantee on the convention floor. Instead, [bithead942] found that the EasyVR Shield 3.0 voice recognition board provided a suitable stand-in. It needs a bit of training to work properly(cue the montage!), but in the end it compares fresh audio commands to the ‘training’ files it has stored, and if there’s a match, triggers a corresponding serial port. It’s not perfect, but it most certainly works!