Go Down

Topic: processing, firmata, UDP, and libraries (Read 2159 times) previous topic - next topic


I would like to make an arduino that uses a standard firmware, and is controlled through a UDP protocol by a computer running a processing sketch. The idea is to make the arduino with a standard set of programming and have a base program in processing that could then add classes to to make whatever i please.

I was taking a look at firmata and that is great for serial which could work for what I want to do but the biggest issue there is i can not use any arduino sensor libraries or any other hardware that requires a #include <libraryName.h>  without explicitly programming it in.

My plan is to make a sketch that can talk to the pins just like firmata but over the UDP protocol and add a lot of libraries. I will program in a read or write command for each sensor, and call the reads via the UDP.
To minimize the network traffic i will place all of the commands in an array list and simply take in the command number.

Unless someone knows of a way to call up the functionality of the arduino lib's in processing.......
also can you see any issues with the plan of action i have or know a better way?


I'm not sure where you're going with this. What and where are these libraries you refer to? Presumably not in the Arduino since you say you don't want to write any code there, but if not on the Arduino then where?


I want to write processing sketches. But in the processing sketches i dont have access to arduino environment libraries. for example i want to read a DHT11 temp/humidity sensor from processing without modifying the arduino firmware "firmata". It cant be done as far as i know and was hoping someone could tell me different


It would be possible in theory to use Firmata or similar as a way to interact with pins remotely and put the driver logic on the client on a PC, but it would give extremely limited performance and be more complicated to implement and would give you no advantages at all that I can think of. Perhaps that explains why it is not common for people to write device drivers using that approach. There's nothing stopping you from writing your own like that if you want, and perhaps you could use the Arduino libraries for inspiration, but frankly it strikes me as a daft approach.

What would be slightly less daft, but only slightly, is to write your libraries on Bitlash so that you can download then to the Arduino without uploading a new sketch. It would be a much more complicated solution (bit not as bad as the Firmata approach) and I still can't imagine what benefits this would give you to justify such a contrived approach. But it's technically feasible.


It cant be done as far as i know and was hoping someone could tell me different

Firmata turns the Arduino into an idiot. It takes intelligence to read a DHT11 sensor. "It can't be done" is correct.
The art of getting good answers lies in asking good questions.


Nov 03, 2013, 01:39 am Last Edit: Nov 03, 2013, 01:46 am by soundanalogous Reason: 1
This could be done using the Firmata protocol, but not using StandardFirmata. There is a huge misconception that StandardFirmata is "Firmata". However that said the only thing Firmata would give you is the ability to "frame" your data within a midi Sysex message.

You would write an Arduino sketch to read the sensors, using any sensor libraries you may have.  Then create a simple protocol to send the sensor data to processing (via UDP). You need a messaging protocol so Processing can understand what sensor data it is receiving (imagine a JSON String for example: "{\"accel\": {\"vector\": {\"x\": 233, \"y\": 110, \"z\": 2}}}"). Likewise if you need to send messages from Processing to the Arduino you could use a protocol to inform an accelerometer to start reading at a specified interval for example: ("{\"accel\": {\"cmd\": {\"start\": 10000}}}"). You could use JSON or xml but that is a lot of text processing for most Arduinos to handle (more of an issue receiving than sending). What Firmata could give you is a binary protocol to insert in your UDP packets. Here is an (incomplete) example. I'll warn you it is not as straightforward as sending a JSON or xml stream though, but can be lighter and faster to parse depending on how much data you need to send. If you don't understand the following pseudocode then this is probably not a good direction for you.

Code: [Select]

// This is an example of using the Firmata protocol simply to send data in a
// (somewhat) structured form. It accomplishes the same thing as something like
// "{\"accel\": {\"vector\": {\"x\": 233, \"y\": 110, \"z\": 2}}}" but is 17 bytes
//  instead of 44 bytes but at the expense of being a bit more cryptic.

#include <Firmata.h>
#include <Ethernet.h>
// include any other libraries you need

// define some constants to help identify data in the firmata sysex message
#define ACCEL        0x00  // use a different value < 0x15 to identify each sensor
#define VECTOR     0x00

EthernetClient client;
// and other ethernet setup (mac address etc)

// array for for accelerometer values
byte accelVector[6];

void setup () {
 client.connect(ip, port);
 // Firmata can use an Ethernet (or WiFi) stream instead of Serial stream

 // your other setup code

void loop () {
 // your loop code

 // imagine you are using an accelerometer library that reports x, y and z values
 onAccelRead(accel.x, accel.y, accel.z)

void onAccelRead(int xVal, int yVal, int zVal) {
  // Populate an array to send using Firmata.sendSysex
  // This must be an array of bytes. Cannot be array of ints or other type.
   accelVector[0] = VECTOR;  // subcommand: this is an arbitrary value that to identify the type of data
   accelVector[1] = (byte)(xVal & 0x00FF); // LSB
   accelVector[2] = (byte)(xVal >> 8 & 0x00FF); // MSB
   accelVector[3] = (byte)(yVal & 0x00FF);
   accelVector[4] = (byte)(yVal >> 8 & 0x00FF);
   accelVector[5] = (byte)(zVal & 0x00FF);
   accelVector[6] = (byte)(zVal >> 8 & 0x00FF);
   // note that sendSysex will split each byte in the accelVector array into 2 bytes
   // params: command, numBytes, byte array
   Firmata.sendSysex(ACCEL, 7, accelVector);
   // sendSysex will split each byte in the array into 2 bytes so it will actually send
   // 14 bytes + start, command and end bytes so 17 bytes total

If you have a firmata client library that can parse a Firmata sysex message then you'll be able to receive the data. You'll still have to interpret the data between START_SYSEX (0xF0) and END_SYSEX (0xF7) and reassemble all of the split bytes which can be some tricky shifting and masking if you are not used to such techniques.


Thank you for your post soundanalogous. That is a bit over my head though. I have not really gotten into bitshifting and such just yet.
I am more interested in reading than writing with the arduino.

I may be over complicating the issue.
I would like to be able to get sensor and or pin reads from the arduino when i ever i send a specific value to it over UDP

for example:
I want an analog reading but i only want a read when a command is recieved over UDP.
When the serial read is complete send the results over UDP.
The Processing sketch on the other end sorts out the input from the sensor making the arduios work much lighter.
The Processing sketch can also control what to do with the input after it comes in

The advantage to all of this is simple. If the code on the arduino remains constant I can update the software in processing
to re purpose the arduino without having to constantly write sketches for it. (allowing for a stable code base) I could also have a pile of libraries and sensor reading functions that just sit in the code until they are called. With the mega2560's 256k of code memory I could set up a ton of available sensors from my processing sketch. Then I could just write simple processing sketches, take in what i need from the arduino and have the processing sketch run more complex software and real time graphs and such.

does that clarify what I am attempting here ?
I a sentence, I am attempting to expand my options for data processing with arduino.

Go Up