Posts Tagged ‘Arduino’

Arduino Gateway [public gateway for arduino running rest server]

Tuesday, January 31st, 2012

Over the past couple of months I have been working on a project called ArduinoGateway. The goal of this project is to create a public gateway that enables me to access data from several Arduinos on my home network, while keeping my home network safe and sound. I have designed this server to connect to Arduinos that are running the RestServer library and that are connected via either ethernet or serial.

At this point, this application is still a work in progress. It is working pretty well when handling request related to a single Arduino that is connected via Ethernet. This means I have a long way to go before I can get this server working with multiple Arduinos connected via both serial and ethernet. However, I thought it was time that I started to document the work that I have done thus far.

Let’s me start off by sharing the git repository where the code is located. For the first time I have been using the git milestone and issue tracking functionality to help me plan my development efforts. On a personal level, I’ve found this to be very helpful. On a communal level, anyone who is interested can find out what I are the features that I am planning to work on soon.

This is the most complex Ruby application that I have built to date. Therefore, I have been trying to think through how I want to application to be structured at an architecture level to help guide my coding efforts. This has been very helpful. Of course, this process is much very bi-directional – I first took a stab at the architecture then I wrote some code and went back and revised the architecture based on what I learned from working on the code.

Here are the most recent architecture schematics that I’ve developed. The first one provides an overview of the communication architecture between the application controller, and the public server and Arduino client interfaces. The second one maps out the data model for this application. The last features an overview of all the classes and modules that make up this application (though I’ll admit that this last one is already a bit out of date).

Application Communication ArchitectureData Model Architecture

Tags: , , ,
Posted in arduino gateway | No Comments »

Arduino RestServer Library [restful architecture]

Tuesday, November 22nd, 2011

This simple library was designed to enable your Arduino to respond to RESTful resource requests via Ethernet or Serial connections. Unlike most existing RESTful libraries for the Arduino, RestServer enables you to describe your own resources and to define how the Arduino should respond to each resource request rather than automatically map resources to pin numbers on the Arduino.

The intent of this design approach is to embed knowledge about the resources available on a given Arduino locally on the device itself. This local knowledge enables the Arduino to inform client devices about the resources are available, along with relevant information about the resources such as resource range and types of requests supported.

Here is a flowchart that describes how the RestServer library works:

Here is an overview of the main features provided by this library:

  • Create your own custom resource lists
  • Define how your device should respond to resource requests
  • Works with clients via Serial and Ethernet connections
  • Responds to queries regarding available resources
  • Provides response in html or json formats
  • Renders html form for resources that support POST requests
  • Supports GET and POST requests
  • Features options to enable state updates via GET requests

To download the library, and to view more detailed instructions on how to setup and interface with RestServer, check out the github repository here. Please note that this is the first version of this library and that it has been tested by only one person (me). Therefore, please let me know if you encounter issues when using it.

Tags: ,
Posted in RestServer, arduino libraries | No Comments »

ITP Cafe [come see us @ maker faire]

Monday, August 29th, 2011

I am happy to be involved in the coordination of the ITP Cafe for the Maker Faire in NYC this September. At this year’s event we are planning to host a series of hands-on sessions and demos. Please spread the word. We hope that you, your family, and friends will join us for a weekend of fun and learning with technology.

We plan to cover a wide range of topics including basic programming with processing, intro to physical computing, making sounds with an arduino, building soft and organic circuits, diy portable air conditioner, making your own wind power generator, learning to hack the kinect, and basic screen printing.

The final session list is still in the works, as soon as it is completed I will share it here. To buy your tickets, just click on the banner below and you will be taken to the official maker faire NYC 2011 page.

Maker Faire 2011

Tags: , , , , ,
Posted in ITP cafe @ maker faire 2011 | No Comments »

HSB to RGB [arduino library]

Sunday, August 28th, 2011

The first version of the firmware that I created for Bright Words only supported changing the color of the lights by controlling the RGB values – red, green, and blue. From a coding perspective this is an easy approach since it is consistent with the physical set-up of the device (the red, green and blue lights are each controlled individually).

Unfortunately, this is not a very intuitive way to cycle through colors. The HSB color model (hue, saturation, and brightness) provides a much more natural approach.

Intuitive Control
By supporting direct control of the hue, users are able to cycle through all colors that are of the same saturation and brightness. Users can use the saturation setting to select the appropriate tint of a color. Tints are essentially mixtures of a color with white. The brightness setting enables users to select the appropriate shade of a color. Shades are mixtures of a color with black.

Higher saturation and brightness levels resolve to stronger colors. A color with no saturation will be achromatic, or in other words, it will have no color. Such a color will range between white, grey and black. A color with no brightness will always resolve to black.

The Code
After deciding to take this route I searched online to find existing code samples that I could use to guide my own work. I found a few examples that were written for the Arduino, though in the end I decided to create my own code from scratch so that it would be structured in my own way. I’ve formatted my code into a simple library that you can download from the github repository.

Here is a brief overview of how to use this simple library. It features two methods that do the exact same thing, they just take different input parameters. Both of them accept 4 different parameters: hue, saturation, and brightness values, and a pointer to an integer array that can hold at least 3 elements (the r, g, and b values).

HSBtoRGB(int hue, int sat, int bright, int* rgb_array);
HSBtoRGBfloat(float hue, float sat, float bright, int* rgb_array);
view raw gistfile1.c This Gist brought to you by GitHub.

The difference is that method HSBtoRGB accepts hue integer values ranging from 0 to 360, and saturation and brightness integer values ranging from 0 to 100. The method HSBtoRGBfloat accepts hue, saturation and brightness float values ranging from 0 to 1.

Resource Links

Tags: , ,
Posted in bright lights | 1 Comment »

AMUP air [interaction design]

Tuesday, June 28th, 2011

AMUP air is a DJ MIDI controller for Ableton Live. The way in which the switches and sensors from this controller are mapped to functionality within Live is a core element of the user experience. This mapping must feel intuitive for this device to deliver on my vision.

Therefore, before finalizing the Arduino sketches for each AMUP component, and in preparation for developing the Live MIDI script, I needed to think through the functionality that should be assigned to each and every switch and button (all 108 of them, including the monome).

Design Considerations
There were several learnings from my experiences using the original version of AMUP that I wanted to address in this prototype. First off, I wanted to add direct feedback on the air panel to support the control of volume using the proximity sensor. Secondly, I realized that it was best to use a single scene selection controller for all tracks since this is not a track-specific function. Lastly, it became clear that I needed to have access to transport controls such as coarse and fine tempo, tempo nudge, and clip launch quantization.

I also wanted to expand the functionality provided by AMUP in several ways. First off, I added three potentiometers to support direct control of Live parameters such as the effects send for each track/channel. Next, I integrated support for multi-modal functionality using button pads with RGB leds. This enables using the potentiometers to control multiple different sets of parameters within Live, such as mixer and device settings associated to specific channel. Lastly, I integrated a monome into my AMUP set-up to enable me to control clip launch, track monitor and stop controls, and more.

Here is an overview of the functionality controlled by each component within the AMUP set-up. In the next couple of days I will create a post with the full MIDI map for this device.

Console Panel
The main console was designed to control several transport functions from Live, including clip launch quantization and tempo controls. It also features controls for the assignment of control pads one and two to one of the four tracks in Live.

Button Panel
The button pad was designed to control various parameters associated to the mixer, tracks, devices and clip loops. This component supports multi-modal functionality that enables the potentiometers to toggle between controlling mixer-related parameters such as eq and effects send, and device-related parameters that vary by device.

Air Panel
The air panel uses a proximity sensor to control Mixer functions such as the volume of an assigned track. In the future this sensor may also feature multi-modal functionality similar to the potentiometer on the button pad, so that it can control device functions.

Monome
The monome is the latest addition to the AMUP set-up. It is used to handle several transport functions, such as scene and track scrolling; and mixer functions, such as track monitoring. It also enables direct control of clips within a moveable 4 x 7 clip slot matrix.

Tags: , , ,
Posted in AMUP | No Comments »

AMUP air [overview]

Monday, June 20th, 2011

Over the past several weeks I have gone completely silent. Though ITP has finished, this is not a sign of me taking time off. Rather this is a result of a sprint to finish prototype 2.0 of my AMUP project (dubbed AMUP air) before a party at Lauren’s school, at which I was scheduled to dj. This party came and went last week. Unfortunately, I was not able to finish the prototype on time – I am actually still working on it.

In this post I will provide a brief overview of the main updates, along with a sneak peek at how it is all coming together. To refresh your memory about AMUP, here is a link to previous journal entries that describe the original vision for this project and the development process for the first prototype.

The first version of this project had not come close to delivering on my vision, though it did provide me with inspiration to continue my pursuit. It’s main flaws included buggy circuitry, which made it unreliable for live performances, and a lack of feedback on the device itself, which made it difficult to control certain parameters without looking at the screen. The physical design of the device itself had an interesting feel clunky as well.

For version 2.0 I wanted to fix all the issues mentioned above as well as making numerous other improvements such as adding new buttons and switches; making the hardware more extensible and robust; developing a more modular software architecture for the Arduino; and integrating deeper into Live’s functionality using the python API.

Here is a brief description of how I have attacked all of these updates over the past month:

  • Fixed bugs in circuitry by rebuilding the schematic from the bottom up. To improve reliability I designed a printed circuit boards for the button pad and air sensor components, and integrated new components such as LED drivers, multiplexers and capacitors.
  • Added support for direct feedback on the physical device itself using RGB led lights. On the air sensor, these leds provide direct feedback regarding channel volume, while on the button pad they enable the buttons to support multiple states.
  • Reconfigured the switches, buttons and potentiometers in response to learnings from first prototype. Added inputs to control quantization, tempo, effects send, along with support for multi state functionality.
  • Designed a more modular and extensible architecture for the hardware. Each button and air sensor panel combination functions as a standalone unit that can connect to the main console. Theoretically I can connect over one hundred button pad/air sensor components to the main console; though due to latency considerations the limit is much lower (I assume around 4 or 5).
  • Working on enabling deeper integration between AMUP and Live by using Live’s Remote MIDI scripts. These python scripts enable you to access a wide range of Live’s functionality that is otherwise unavailable.

Over the coming weeks I will provide more in-depth overviews about how I’ve addressed all of the areas above. I will also share several tutorials related to skills I had to acquire while working on this project:

  • Bootloading AVR chips with Arduino
  • Writing an Ableton MIDI Remote Scripts in python

To support this project I’ve developed a set of related libraries that handle digital and analog switches by providing services such as: smoothing data from analog switches; debouncing input from digital switch; making it easy to set-up and read rotary encoders; and supporting multi-state RGB buttons. All of the components in this library adhere to the same design pattern, which will hopefully make then easier to use. I will write-up some additional documentation in a future post, but for now you can find the library on my github page here.

Tags: , , ,
Posted in AMUP | No Comments »