I'm looking to build a simple roving robot that is controlled by my Mac. I want to code the AI/logic in Realbasic (a Visual Basic like language), not directly on the Arduino board (as the robot will need to access several services present on the Mac).
As far as I'm aware, there is no interface library for Realbasic so I'll have to write my own (this I don't mind doing). I just have a few questions:
If I'm reading correctly, it looks like Firmata is a sketch that I can load onto the Arduino that will allow communication between the Arduino and the serial port on my Mac via a standardised protocol. Is that correct?
In the examples section of the Arduino IDE, there are several Firmata sketches (i.e. AllInput, Standard, etc). What is the difference between these and which one should I upload to my Uno to start debugging?
Does the Arduino constantly send out the status of all of it's pins once it's running Firmata or does it merely respond to messages sent to it over the serial connection in the correct Firmata protocol and then respond with a pin status in the same messaging format?
Is there any example code of other implementations of the Firmata protocol that I can use as a starting point to write my own?
Does Firmata allow you to, for instance, read the voltage from anaolgue pin 1 (which might have a light dependent resistor attached) and then turn on digital pin 3 (which might, for instance, have a motor attached) all via software running on a computer?
If I'm reading correctly, it looks like Firmata is a sketch that I can load onto the Arduino that will allow communication between the Arduino and the serial port on my Mac via a standardised protocol. Is that correct?
If, by standardized, you mean restricted, then, yes.
I'm looking to build a simple roving robot
This implies motors, possibly even servos. Firmata supports PWM, to vary the speed of motors, or servo type commands, but no Firmata sketch integrates them well.
In the examples section of the Arduino IDE, there are several Firmata sketches (i.e. AllInput, Standard, etc). What is the difference between these
The differences are the types of things you can make the Arduino do while the various sketches are loaded.
and which one should I upload to my Uno to start debugging?
None. Develop your own protocol that lets you do everything, and implement that in an Arduino sketch.
Does the Arduino constantly send out the status of all of it's pins once it's running Firmata or does it merely respond to messages sent to it over the serial connection in the correct Firmata protocol and then respond with a pin status in the same messaging format?
It responds to requests for information, or to requests to alter the state of a pin.
Is there any example code of other implementations of the Firmata protocol that I can use as a starting point to write my own?
Your own what?
Does Firmata allow you to, for instance, read the voltage from anaolgue pin 1 (which might have a light dependent resistor attached) and then turn on digital pin 3 (which might, for instance, have a motor attached) all via software running on a computer?
PaulS:
This implies motors, possibly even servos. Firmata supports PWM, to vary the speed of motors, or servo type commands, but no Firmata sketch integrates them well
I'm completely new to Arduino (but a reasonably proficient hobbyist programmer) - why is Firmata bad at this?
PaulS:
The differences are the types of things you can make the Arduino do while the various sketches are loaded
Could you elaborate on this a little?
PaulS:
Develop your own protocol that lets you do everything, and implement that in an Arduino sketch
Although I probably could do this (I hate C, hence why I'm not keen on writing my own sketch) - is Firmata really that bad as a starting point to get a semi-functional robot written in Realbasic? I already have code in Realbasic for path-finding, simple AI etc...
PaulS:
Your own what?
Sorry, I should have been more clear. I mean writing my own library to interface with Firmata.
Firmata is not actively supported for the Arduino.
Could you elaborate on this a little?
Control of servos while PWM other pins doesn't work well. It is not a restriction of FIrmata or of the Arduino. It is simply that the various Firmata sketches are designed to do one thing well. If that one thing is the thing you need to do, great. If you need to do two things, forget it.
Sorry, I should have been more clear. I mean writing my own library to interface with Firmata.
I presume you mean that you want to develop your own application that interfaces with an Arduino running Firmata. There are libraries that manage the communication with the Arduino. Whether there is a Firmata library for RealBasic, I do not know. Developing one should not be that difficult. The Firmata.org site has all the details you need.
In your opinion though, if one only wanted to control the Arduino from a computer (i.e. the board merely becomes a mounting point for providing sensor input to the computer and driving output like motors) you would write your own custom sketch rather than use Firmata? I've just been a little concerned by a couple of things you've mentioned :~
As a complete newcomer to Arduino and electronics in general, the thought of writing my own low level firmware (in a language I'm not yet proficient in) on top of a software interface in Realbasic is quite a daunting prospect. I'd rather just get a Realbasic interface up and running as quickly as possible so I can get to the fun bit of building a robot but I don't want to put the time and effort into writing a library for Firmata if it's awful...
Perhaps you should search the forum. Look for threads discussing Firmata. Then, look at those to determine which ones are from happy users, and which ones are from anyone that says "Hey, I'm from Firmata, and I'm hear to help". You'll find precious few of those posts.
but I don't want to put the time and effort into writing a library for Firmata if it's awful...
Then don't it is.
The entire concept of Firmata is a bit flawed. It removes any sort of processing ability from the arduino. Basically if you want to do anything other than the basics it don't work.
I can understand the attractions to a beginner but you get nothing for free.
Grumpy_Mike:
The entire concept of Firmata is a bit flawed. It removes any sort of processing ability from the arduino. Basically if you want to do anything other than the basics it don't work.
What I'm not sure about is why would I want to use the processing power of the Arduino when my robot's logic/AI could be controlled by a powerful PC? I just need to get information from the environment via sensors to feed into my Realbasic algorithms and then a way to drive motors, LEDs, etc.
What I'm not sure about is why would I want to use the processing power of the Arduino
It basically boils down to flexibility and expandability. Create a simple protocol to communicate between RealBasic and the Arduino, and you can make it do what you want, when you want it to. If you get stuck, the people here will help you.
What I'm not sure about is why would I want to use the processing power of the Arduino when my robot's logic/AI could be controlled by a powerful PC? I just need to get information from the environment via sensors to feed into my Realbasic algorithms and then a way to drive motors, LEDs, etc.
So, one example is the ping sensor that is so popular. The Arduino has to do a number of things to get a value from that sensor. Using Firmata, you just can't do the same things. For example, there is no way to delay the exact amount of time needed.
The time between setting a pin HIGH and setting it LOW again depends on the speed of the serial port, and what (else) the PC is doing, if you are trying to toggle a pin using Firmata. That screws up the ping sensor, which expects to send out a pulse of known duration.
There is no way, using Firmata, to emulate the pulseIn() function that times how long the sensor takes to get an echo back.
You could, in your protocol, define a command to have the Arduino do the stuff that the ping sensor needs to have done. Then, you could implement that in the Arduino sketch.
PaulS:
There is no way, using Firmata, to emulate the pulseIn() function that times how long the sensor takes to get an echo back.
You could, in your protocol, define a command to have the Arduino do the stuff that the ping sensor needs to have done. Then, you could implement that in the Arduino sketch.
Now that is a good reason to write my own protocol! The robot I'm planning on building will need a sonic range finder and if Firmata couldn't handle that then I may as well roll my own protocol and Arduino sketch.
I cann't say that I'm particularly experienced, but my first contact with an arduino board was through visual basic and my pc. The pc 'sees' a serial port and writes/reads it. As I understand, Firmata is an intermediary that does the same. But interfacing arduino through the serial is not particularly difficult.
I've later used Firmata.
This is feadback from arduino to processing .. I need fast and furious sensor-feedback from one particular pin, so I cut down one of the firmata sketch examples to this:
#include <Firmata.h>
byte analogPin = 0;
void analogWriteCallback(byte pin, int value)
{
if (IS_PIN_PWM(pin)) {
pinMode(PIN_TO_DIGITAL(pin), OUTPUT);
analogWrite(PIN_TO_PWM(pin), value);
}
}
void setup()
{
Firmata.setFirmwareVersion(0, 1);
Firmata.attach(ANALOG_MESSAGE, analogWriteCallback);
Firmata.begin(57600);
}
int val ;
int valOld=1 ;
void loop()
{
while(Firmata.available()) {
Firmata.processInput();
}
val=analogRead(analogPin);
delayMicroseconds(150) ;
if( val != valOld ){
Firmata.sendAnalog(analogPin, val);
}
valOld = val ;
}
Even though nothing else happens I'm convinced that I can sense a small delay from the 'ping' from the sensor til the value arrives at processing. If this delay has potential of cocking up anything you intend to do, then make it happen exclusively in the arduino.
Wouldn't be related to that unconditional delayMicroseconds() on every pass through loop(), would it?
I think that it's too slow to be noticed. To be frank, if I noticed the signal as the turn-on of a led .. it might be the time it takes of lighting it up.
Why is that there?
Interesting question. I read somewhere that it takes 130 microSeconds to make a proper analog reading. So, I respond by making a delay of that size, to make the reading right. .. like it takes time to read the serial ..
Why on earth the serial.read() does not complete what it's supposed to do and need a delay() is beyond me, but I've seen it so often that I just do it.
I read somewhere that it takes 130 microSeconds to make a proper analog reading. So, I respond by making a delay of that size, to make the reading right.
It does. That's how long it takes analogRead() to do its thing and return. Diddling around for another 130 microseconds then is silly.
Why on earth the serial.read() does not complete what it's supposed to do and need a delay() is beyond me, but I've seen it so often that I just do it.
I never use delay, and I never miss serial data. If you only read what is available, you won't, either.
When some people (not mentioning any names, zoomkat) use it is so they can receive a "whole packet" without having to worry about exactly what a "whole packet" is. By using explicit start and end of packet markers (which I do), you never need to delay() while reading serial data.