I have just started to learn the Arduino Uno for a possible robot lawnmower project (yes another one!) and I was wondering how reliable the Arduino is. I don't want the mower to take off unexpectedly due to a program 'lockup'. Is it just as reliable as Windows (ha ha)? Are there error handling examples anywhere such as the old Basic "On Error Resume Next"? Can I programatically push the reset button if the program gets stuck with a detectable error? I have only been playing with it for a few days and already it has locked up a few times and I don't know why. Sometimes the serial port doesn't work and the Tools/Serial Port menu item gets grayed out. I close and reload Arduino.exe and then COM port seems to work again. Don't know why. I'm using Win XP. Thanks.
Arduinos are very reliable. I'm sure that at least 99.44% of program "lock ups" and other issues are caused by code. Haven't tried it myself, but it sounds like the best way to programmatically push the reset button is to configure the watchdog timer to cause a reset and then set it for some fairly short time interval, and wait for it to expire. After the reset, the first thing the code must do is to reconfigure the watchdog so a reset loop doesn't occur.
As for the IDE issues, the only time I've had what may be similar problems is when I had bad code flooding the serial monitor with more than it could enjoy.
If it were me, I'd get very familiar with the watchdog (see the ATmega328P datasheet) or even consider a separate external watchdog, which has its advantages. Sounds like you may have already searched the forum, but you'll find lots of cautionary discussion on such projects for the reasons you mention. Bottom line for any such project, the code has to be exceedingly solid. If it's relying on the watchdog, then more work is needed. Of course it's a great idea to have the watchdog active even if the code hasn't needed it yet...
(Reminds me of a joke: There are two kinds of boaters, those that have launched their boat without the drain plugs in, and those who haven't done it yet...)
warren631:
Is it just as reliable as Windows (ha ha)?
More reliable. 
However nothing saves a processor from programming errors. Maybe post your code.
Interesting question!
I tried googling "Arduino MTBF", didn't find very much, except reference to the lives of the LED's. Maybe it means that very few Arduino's are failing yet? I hope so.
Arduinos first came to life around 2005, so if the oldest of them have been running 24/7/365, they'll now have clocked up about 50,000 hours.
If we set the programming problems aside, what comes next? I don't know, but would be guessing at the following being the major causes for failure:
Environmental conditions - too hot, too cold, moisture, vibration, mechanical damage, contact corosion, strong magnetic fields etc.
Unregulated power supply - spikes, variations outside what's recommended.
Problems caused by peripherals - spikes from any input devices, shorts or spikes on output devices.
To ensure a long lifetime, address these, and you're probably well down the road.
Ian (human - MTBF of 500,000 hrs XD )
IB999010:
Ian (human - MTBF of 500,000 hrs XD )
LOL! XD
"On Error Resume Next"
There is no built-in error trapping like that with Arduino, you can of course implement your own system.
That said I never use C++, maybe try/catch is implemented although I've never seen it mentioned here.
Rob
maybe try/catch is implemented although I've never seen it mentioned here.
Because try/catch is not implement. Exception handling requires a fair amount of memory for a fairly large stack. The Arduino doesn't have enough memory.
The Arduino is as reliable as the program you write for it.
Unlike a computer there is no operating system between your program and the hardware. In an environment like a PC you are not programming the PC, you are programming the operating system. The operating system then translates your code's function calls into actual hardware access via the use of device drivers and such. These extra layers of complexity all add extra layers of unreliability to the system. If any one layer has a fault, it will affect all the layers above it, and the more layers you have the more chance there is of something breaking.
As I say, with an Arduino (and any other "bare metal" microcontroller) you don't have any of these layers. There is just your code, a few pre-written libraries, and the chip. If anything goes wrong, then it is either a hardware fault (rare), something wrong with one of the pre-written libraries (not common), or something you have written wrong in your program (very very common).
Most hardware faults are actually caused by incorrect interfacing to external devices, such as connecting devices that draw too much current, or forgetting to add snubbing circuits to inductive loads, etc., so at the end of the day they are as much user error as a fault in the program.
For the reliability have a look at :
http://www.smartprj.com/catalog/index.php?main_page=warranties&zenid=ou9ictuiuos5a0kuahjm96lth1
Smart project is the Italian manufacturer arduino boards.
Notice especialy :
1.5 UNAUTHORIZED USE.
smartprojects products are not authorized for use in safety-critical applications where a failure of the smartprojects product would reasonably be expected to cause severe personal injury or death"
Thanks for your input guys. I don't want to fool around with the internal watchdog timer since I might screw up the firmware and damage my Uno. I think I will use an external watchdog time delay relay controlled by an Arduino output which is pulsed every loop of the program. If it doesn't get pulsed then it times out and removes power to the mower.
Reading other posts it seems best to stay away from using serial in the Arduino if you want reliability. Here is my very simple sketch that locks up randomly if I un-rem the serial statements (its just a minor rev to the knob example to make the servo cycle by itself). It has run 24 hours now without a lockup since I removed the serial statements (maybe I don't need a watchdog after all):
// Controlling a servo position using a potentiometer (variable resistor)
// by Michal Rinott <http://people.interaction-ivrea.it/m.rinott>
#include <Servo.h>
Servo myservo; // create servo object to control a servo
int potpin = 0; // analog pin used to connect the potentiometer
int val; // variable to read the value from the analog pin
int x = 0;
void setup()
{
myservo.attach(9); // attaches the servo on pin 9 to the servo object
// Serial.begin(9600);
delay(5000); // waits for the servo to get there
}
void loop()
{
val = x * 511;
// val = analogRead(potpin); // reads the value of the potentiometer (value between 0 and 1023)
val = map(val, 0, 1023, 20, 160); // scale it to use it with the servo (value between 0 and 180)
myservo.write(val); // sets the servo position according to the scaled value
x = x + 1;
if (x >2)
{
x = 0;
}
// Serial.println(val);
delay(1000); // waits for the servo to get there
}
I've used the AVR watchdog with no problems whatsoever. It's a good idea if a program lock-up could cause some sort of problem (in my case, disabling my security system). I've never had any problems with Serial.print(), but if it uses Strings (idk if it does) that could cause some problems, as Strings may leak memory. It's generally a good idea to use char arrays instead. I've had my Arduino running all night with no problems, but it might have reset itself via watchdog when I was asleep at the other end of the house.
That watchdog is supposed to save you, not cause problems. There is no reason the watchdog would screw up the firmware or damage the Uno.
I don't see why, on the face of it, the serial prints in your sketch would lock up the processor. Maybe it's a hardware thing. You haven't posted many details.
I un-rem'ed the serial statements again because I want to know what is going on in the program and it locked up again like before. I then set the transmit and receive buffers for the COM port on my PC to minimum. That seemed to do it - it works without locking up now. The port is set to 9600,8,N,1 with no row control. Is that correct? Shouldn't I use parity? Wouldn't parity be more reliable?
Anyway, so it seems to work now with the serial statements in the program enabled. So I powered down and plugged in a sensor shield from WWW.GE-TH.COM (had to bend the pins a little to make it fit), plugged in my servo, and powered up. It now runs for about 60 seconds then freezes. I reset and it runs again for 60 seconds. I didn't change the program. Only one servo is plugged in - nothing else. I'm using the 9V power supply because I thought maybe I was loading down my Acer USB port. I then removed the sensor board and tried the program again and it works just fine. But I want to use the sensor shield in my project. Bad sensor shield? I removed the two jumpers in the shield but it still froze after 60 seconds with the shield.
This is frustrating. Any suggestions?
When I download I sometimes get this message:
Binary sketch size: 4,562 bytes (of a 32,256 byte maximum)
avrdude: stk500_getsync(): not in sync: resp=0x00
Sometimes I get this message:
avrdude: ser_send(): write error: sorry no info avail
Sometimes it takes a long time to download.
Is it anything to do with trying to download while the program is running and talking on the serial port at the same time? How do I stop the program until I have fully downloaded and then re-start it? Sometimes when I try to download it says "COM port already in use" - of course it is, the program that is running in the UNO is using it! Is there any way to stop the program and clear memory before downloading a new program?
Also: the on-board LED at pin 13 is always on. My program does not do anything with this LED. Maybe a previous program left it on.
Thanks, Warren.
You are saying your code doesn't work without saying what the code is.
"COM port already in use" means a program on your PC is using the COM port, not that that arduino is.
So I powered down and plugged in a sensor shield from WWW.GE-TH.COM
I refuse to guess which sensor shield that might be.
had to bend the pins a little to make it fit
Should have sent it back, instead.
I think I have my problems sorted out and this experience might help other newbies. Main problem was I was trying to drive a large servo that took too much power from the UNO and I guess it dragged down the 5V and probably put a lot of noise onto the 5V. If you notice the green power LED light flickering that is a good sign of too much load. I guess when I added the shield it needed even more power from the UNO. Secondly, the USB port on my little Acer PC was a little flaky. Don't know what the problem was exactly, but I tried my Dell PC and that worked fine. 
I still think I will use the AVR watchdog just in case the UNO goes crazy and the robot mower goes after the neighbors' flower garden. 
I still think I will use the AVR watchdog just in case the UNO goes crazy and the robot mower goes after the neighbors' flower garden.
I'm curious how the watchdog timer is going to know that your robot mower is going after the neighbor's flower garden.
It'll be watching, of course.
It will bark, alerting the user.