Posts | Comments

Planet Arduino

Overall computer volume control is important, but what if you want to get more granular, adjusting sound from various applications individually? Rather than going through a series of menus and on-screen sliders, Ruben Henares’ Maxmix lets you do this on the fly.

Based on an Arduino Nano, the simple yet stylish knob takes input from an encoder and button to select a program and rotating it turns the volume up and down.

There’s also a desktop application that needs to be installed, while a small OLED screen on the Maxmix that shows which application is running. There’s even an optional LED ring for extra lighting effects.

All the electronics are housed inside a nicely designed 3D-printed enclosure. You can find files for the case along with build instructions on Henares’ site.

If you’ve ever left an online comment that you later regretted, this anti-troll bot will keep that from happening again by letting you know when you’re being a bit too harsh.

The device — which was created by Andy of element14 Presents — intercepts raw keyboard inputs using a MKR Zero board and analyzes them using a TensorFlow Lite machine learning algorithm.

As an output, the Arduino controls the mouth of a rather hilarious human cutout via a servo motor, which as seen in the video below, also features a wisp of black hair and oversized googly eyes. If you’re typing happy thoughts, its mouth turns up into a smile, while mean words produce a frowny face.

The project is a great example of running ML code on limited hardware, and more info on the sentiment-analyzing keyboard adapter can be found here.

We’ve all been there. You’re manning the battle station, deep in the sim-racing or some other n00b-pwning zone and suddenly some loudmouth blows out your eardrums over Discord. It’s insulting to have to stop what you’re doing to find the right Windows volume slider. So why do that? Build [T3knomanzer]’s simple yet elegant multi-volume knob and stay zen in the zone.

It’s easy, just turn the knob to cycle through your programs until Discord comes up on the little screen, and then push down to change it into a volume knob. If you need to change another volume, just click it again. Since there’s no Alt+Tabbing out to the desktop, no checkered flags should ever slip through your fingers.

Inside the well-designed case you’ll find the usual suspects — Arduino Nano, rotary encoder, an OLED display, and an LED ring, each with their own place carved out.

This completely open-source knob looks great, and we love that it’s been made incredibly easy to replicate by standing up a site with foolproof, well-depicted, step-by-step instructions. Watch them take it for a spin after the break.

Want more than volume at your fingertips? Here’s a DIY USB knob that does shortcuts, too.

DIY camera sliders are a great way to get professional-looking video shots on an amateur budget, but few can compare to the quality of this project by “isaac879.”

His device features a pan/tilt mechanism outlined in a previous video, but in the clip below he’s attaching it to a piece of aluminum extrusion to enable it to slide as well.

The build is controlled by an Arduino Nano, which actuates three stepper motors using A4988 drivers. The carriage is pulled along by a belt drive, via a stepper mounted to the carriage itself. This allows for easy disassembly when needed.

It’s a clever and extremely clean design, and the video shows some great examples of the shots it can take (even when upside down).

The Arduino CLI is an open source command line application written in Golang that can be used from a terminal to compile, verify and upload sketches to Arduino boards, and that’s capable of managing all the software and tools needed in the process. But don’t get fooled by its name: the Arduino CLI can do much more than the average console application, as shown by the Pro IDE and Arduino Create, which rely on it for similar purposes but each one in a completely different way from the other.

In this article, we introduce the three pillars of the Arduino CLI, explaining how we designed the software so that it can be effectively leveraged under different scenarios.

The first pillar: command line interface

Console applications for humans

As you might expect, the first way to use the Arduino CLI is from a terminal and by a human, and user experience plays a key role here. The UX is under a continuous improvement process as we want the tool to be powerful without being too complicated. We heavily rely on sub-commands to provide a rich set of different operations logically grouped together, so that users can easily explore the interface while getting very specific contextual help.

Console applications for robots

Humans are not the only type of customers we want to support and the Arduino CLI was also designed to be used programmatically — think about automation pipelines or a CI/CD system. 

There are some niceties to observe when you write software that’s supposed to be easy to run when unattended and one in particular is the ability to run without a configuration file. This is possible because every configuration option you find in the arduino-cli.yaml configuration file can be provided either through a command line flag or by setting an environment variable. To give an example, the following commands are all equivalent and will proceed fetching the unstable package index that can be used to work with experimental versions of cores: 

See the documentation for details about Arduino CLI’s configuration system.

Consistent with the previous paragraph, when it comes to providing output the Arduino CLI aims to be user friendly but also slightly verbose, something that doesn’t play well with robots. This is why we added an option to provide output that’s easy to parse. For example, the following figure shows what getting the software version in JSON format looks like.

Even if not related to software design, one last feature that’s worth mentioning is the availability of a one-line installation script that can be used to make the latest version of the Arduino CLI available on most systems with an HTTP client like curl or wget and a shell like bash.

The second pillar: gRPC interface

gRPC is a high-performance RPC framework that can efficiently connect client and server applications. The Arduino CLI can act as a gRPC server (we call it daemon mode), exposing a set of procedures that implement the very same set of features of the command line interface and waiting for clients to connect and use them. To give an idea, the following is some Golang code capable of retrieving the version number of a remote running Arduino CLI server instance:

gRPC is language-agnostic: even if the example is written in Golang, the programming language used for the client can be Python, JavaScript or any of the many supported ones, leading to a variety of possible scenarios. The new Arduino Pro IDE is a good example of how to leverage the daemon mode of the Arduino CLI with a clean separation of concerns: the Pro IDE knows nothing about how to download a core, compile a sketch or talk to an Arduino board and it demands all these features of an Arduino CLI instance. Conversely, the Arduino CLI doesn’t even know that the client that’s connected is the Pro IDE, and neither does it care.

The third pillar: embedding

The Arduino CLI is written in Golang and the code is organized in a way that makes it easy to use it as a library by including the modules you need in another Golang application at compile time. Both the first and second pillars rely on a common Golang API, a set of functions that abstract all the functionalities offered by the Arduino CLI, so that when we provide a fix or a new feature, they are automatically available to both the command line and gRPC interfaces. 

The source modules implementing this API can be imported in other Golang programs to embed a full-fledged Arduino CLI. For example, this is how some backend services powering Arduino Create can compile sketches and manage libraries. Just to give you a taste of what it means to embed the Arduino CLI, here is how to search for a core using the API:

Embedding the Arduino CLI is limited to Golang applications and requires a deep knowledge of its internals. For the average use case, the gRPC interface might be a better alternative; nevertheless this remains a valid option that we use and provide support for.

Conclusion

You can start playing with the Arduino CLI right away. The code is open source and we provide extensive documentation. The repo contains example code showing how to implement a gRPC client, and if you’re curious about how we designed the low-level API, have a look at the commands package and don’t hesitate to leave feedback on the issue tracker if you’ve got a use case that doesn’t fit one of the three pillars.

Whether for work or play, and now for various video/voice socials that have been set up, “chebe” spends most of the day at their desk — so much so that, in some instances they lose track of time. To address the issue, this maker dug out a vintage Arduino Duemilanove circa 2010 to create a unique new clock.

The build consists of other parts from chebe’s electronics stash as well, including a SparkFun RTC module and a 7-segment 4-digit display to show the hour and minutes. An LoLshield that was soldered up nine years ago was also implemented, producing an extra glowing effect through the unit’s translucent cover.

Impressively, the only component obtained specifically for the project was a Proto Shield for attaching things together.

Mechanical table hockey games, where players are moved back and forth and swing their sticks with a series of knobs, can be a lot of fun; however, could one be automated? As Andrew Khorkin’s robotic build demonstrates, the answer is a definite yes — using an Arduino Mega and a dozen stepper motors to score goals on a human opponent.

The project utilizes an overhead webcam to track the position of the players and puck on the rink, with a computer used for object detection and gameplay. Each player is moved with two steppers, one of which pushes the control rod in and out, while the other twists the player to take shots.

Training the game took six months of work, which really shows in the impressive gameplay seen below.

Whilst swapping out the stereo in his car for a more modern Android based solution, [Aaron] noticed that it only utilised a single CAN differential pair to communicate with the car as opposed to a whole bundle of wires employing analogue signalling. This is no surprise, as modern cars invariably use the CAN bus to establish communication between various peripherals and sensors.

In a series of videos, [Aaron] details how he used this opportunity to explore some of the nitty-gritty of CAN communication. In Part 1 he designs a cheap, custom CAN bus sniffer using an Arduino, a MCP2515 CAN controller and a CAN bus driver IC, demonstrating how this relatively simple hardware arrangement could be used along with open source software to decode some real CAN bus traffic. Part 2 of his series revolves around duping his Android stereo into various operational modes by sending the correct CAN packets.

These videos are a great way to learn some of the basic considerations associated with the various abstraction layers typically attributed to CAN. Once you’ve covered these, you can do some pretty interesting stuff, such as these dubious devices pulling a man-in-the-middle attack on your odometer! In the meantime, we would love to see a Part 3 on CAN hardware message filtering and masks [Aaron]!

In many locations you can get PCBs made fast, cheap, and of very good quality. In Brazil, where Vítor Barbosa lives, this isn’t the case, so he built a “haxmark460” PCB printer to help manufacture circuits at home.

The build modifies a Lexmark E460dn laserjet printer to mark PCBs directly, using an aluminum carrier plate instead of its normal paper feed operation.

An Arduino is utilized to hijack and output printer signals, enabling it to it to work in a much different way than how it was originally designed. The carrier plate, with blank PCB material taped on, is fed into the front and the PCB is pulled through and properly marked by the printer. After a dip in acetone to allow the toner to stick to the copper, the board is ready to etch!

SSL/TLS stack and HW secure element

At Arduino, we are hard at work to keep improving the security of our hardware and software products, and we would like to run you through how our IoT Cloud service works.

The Arduino IoT Cloud‘s security is based on three key elements:

  • The open-source library ArduinoBearSSL for implementing TLS protocol on Arduino boards;
  • A hardware secure element (Microchip ATECCX08A) to guarantee authenticity and confidentiality during communication;
  • A device certificate provisioning process to allow client authentication during MQTT sessions.

ArduinoBearSSL

In the past, it has been challenging to create a complete SSL/TLS library implementation on embedded (constrained) devices with very limited resources. 

An Arduino MKR WiFi 1010, for instance, only has 32KB of RAM while the standard SSL/TLS protocol implementations were designed for more powerful devices with ~256MB of RAM.

As of today, a lot of embedded devices still do not properly implement the full SSL/TLS stack and fail to implement good security because they misuse or strip functionalities from the library, e.g. we found out that a lot of off-brand boards use code that does not actually validate the server’s certificate, making them an easy target for server impersonation and man-in-the-middle attacks.

Security is paramount to us, and we do not want to make compromises in this regard when it comes to our offering in both hardware and software. We are therefore always looking at “safe by default” settings and implementations. 

Particularly in the IoT era, operating without specific security measures in place puts customers and their data at risk.

This is why we wanted to make sure the security standards adopted nowadays in high-performance settings are ported to microcontrollers (MCUs) and embedded devices.

Back in 2017, while looking at different SSL/TLS libraries supporting TLS 1.2 and modern cryptography (something that could work with very little RAM/ROM footprint, have no OS dependency, and be compatible with the embedded C world), we decided to give BearSSL a try.

BearSSL: What is it?

BearSSL provides an implementation of the SSL/TLS protocol (RFC 5246) written in C and developed by Thomas Pornin.

Optimized for constrained devices, BearSSL aims at small code footprint and low RAM usage. As per its guiding rules, it tries to find a reasonable trade-off between several partly conflicting goals:

  • Security: defaults should be robust and using patently insecure algorithms or protocols should be made difficult in the API, or simply not possible;
  • Interoperability with existing SSL/TLS servers; 
  • Allowing lightweight algorithms for CPU-challenged platforms; 
  • Be extensible with strong and efficient implementations on big systems where code footprint is less important.

BearSSL and Arduino

Our development team picked it as an excellent starting point for us to make BearSSL fit in our Arduino boards focusing on both security and performance.

The firmware developers team worked hard on porting BearSSL to Arduino bundling it together as a very nice and open-source library: ArduinoBearSSL.

Because the computational effort of performing a crypto algorithm is high, we decided to offload part of this task to hardware, using a secure element (we often call it a “cypto chip”). Its advantages are:

  • Making the computation of cryptography operations faster;
  • You are not forced to use all the available RAM of your device for these demanding tasks;
  • Allows storing private keys securely (more on this later);
  • It provides a true random number generator (TRNG).

How does the TLS protocol work?

TLS uses both asymmetric and symmetric encryption. Asymmetric encryption is used during the TLS handshake between the client and the server to exchange the shared session key for communication encryption. The algorithms commonly used in this phase are based on Rivest-Shamir-Adleman (RSA) or Diffie-Hellman algorithms. 

TLS 1.2 Handshake flow

After the TLS handshake, the client and the server both have a session key for symmetric encryption (e.g. algorithms AES 128 or AES 256).

The TLS protocol is an important part of our IoT Cloud security model because it guarantees an encrypted communication between the IoT devices and our servers.

The secure element

In order to save memory and improve security, our development team has chosen to introduce a hardware secure element to offload part of the cryptography algorithms computational load, as well as to generate, store, and manage certificates. For this reason, on the Arduino MKR family, Arduino Nano 33 IoT and Arduino Uno WiFi Rev2, you will find the secure element ATECC508A or ATECC608A manufactured by Microchip.

How do we use the secure element?

A secure element is an advanced hardware component able to perform cryptographic functions, we have decided to implement it on our boards to guarantee two fundamental security properties in the IoT communication: 

  • Authenticity: You can trust who you are communicating with;
  • Confidentiality: You can be sure the communication is private.

Moreover, the secure element is used during the provisioning process to configure the Arduino board for Arduino IoT Cloud. In order to connect to the Arduino IoT Cloud MQTT broker, our boards don’t use a standard credentials authentication (username/password pair). We rather opted for implementing a higher-level authentication, known as client certificate authentication.

How does the Arduino provisioning work?

The whole process is possible thanks to an API, which exposes an endpoint a client can interact with.

As you can see in the diagram below, first the Client requests to register a new device on Arduino IoT Cloud via the API, to which the server (API) returns a UUID (Universally Unique IDentifier). At this point, the user can upload the sketch Provisioning.ino to the target board. This code is responsible for multiple tasks:

  • Generating a private key using the ATECCX08A, and store it in a secure slot that can be only read by the secure element;
  • Generating a CSR (Certificate Signing Request) using the device UUID as Common Name (CN) and the generated private key to sign it;
  • Storing the certificate signed by Arduino acting as the authority.

After the CSR generation, the user sends it via the API to the server and the server returns a certificate signed by Arduino. This certificate is stored, in a compressed format, in a slot of the secure element (usually in slot 10) and it is used to authenticate the device to the Arduino IoT Cloud.



  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook