you are sending the update pulses at most every 20 ms (+ 20 ms per LED switch on) but only turning them on for 10 ms if you receive the "on" signal.

You might want to look at the flashing with out delay example so you can do 2 things at once.

It looks like your serial interface can transmit around 960 characters per second & 3 LEDs.

I would do this -> send your on pulses at 10 ms intervals, but display the light for 15 ms after receiving the pulse.

that would give you 5 ms over lap allowing a constant on signal.

let me know if you want more specific code.

it will either overhead/melt/break or if it has over current/heat protection, that will kick in.

thank you.

I have seen code examples using millis 2 different ways and was wondering if one of these is better then the other.

Method 1:

Code:

unsigned long previousMillis = 0;     
unsigned long interval = 1000;     

void setup() {
  // setup code here     
}

void loop()
{
  unsigned long currentMillis = millis();
 
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;   
    // do something
   
  }
}

Method 2:

Code:

unsigned long previousMillis = 0;     
unsigned long interval = 1000;     

void setup() {
  // setup code here     
}

void loop()
{
  unsigned long currentMillis = millis();
 
  if(currentMillis > nextMillis) {
    nextMillis = currentMillis + interval;   
    // do something
   
  }
}

Method 2 only does the addition/subtraction one time so it would save some cycles every time through the loop, however it looks like it will have issues when the unsigned long rolls over (approximately 50 days).

does Method 1 get around the bound condition when the millis rolls over or is there any other reason to do the code that way instead of method 2?

If you want the car to stop if it doesn't receive any input, you should add some code on the Arduino to detect the lack of input -> something like this:

// global variable declarations
unsigned long previousMillis = 0;
unsigned long interval = 100;  // 1/10 second

at the begining of your loop add
unsigned long currentMillis = Millis();

after
if (Serial.available() > 0)
{
  buffer=Serial.read()
add this
  previousMillis = currentMillis;


then after the if statement closes

if(currentMillis - previousMillis > interval) {
   //code to stop the car
}

this will cause the car to stop if it doesn't receive input for interval ms

after copying your code and clicking verify I was informed of the following errors:

a missing ), an extra {, and a missing }

After correcting the errors found by clicking verify, the code compiled, however as I don't have a circuit diagram, etc for your robot, I do not know if this will do as you are expecting.

for example what happens if all the senors are low or high?

the adafriut only handles 600 mA per channel doubling that only gives 1200 mA which is still well below 2800 mA.

You need a driver that can do 4 channels of 2800 mA or higher draw or 2 channels of 5600 mA or higher draw.

Code:

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);
    digitalWrite(13, LOW);
    if (foo != TEST_VALUE) digitalWrite(13, HIGH);
}

void loop(void)
{
}

has the light end up on, I was making sure it wasn't a left over on state some how from something before.

Code:

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);

}

void loop(void)
{
   digitalWrite(13, LOW);
   if (foo != TEST_VALUE) digitalWrite(13, HIGH);
 
   while( true) {};
 
}

light is on again (seeing if it has to do with being in loop vs. start up)

Code:

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);
    Serial.begin(9600);
}

void loop(void)
{
   digitalWrite(13, LOW);
   if (foo != TEST_VALUE) digitalWrite(13, HIGH);
 
   while( true) {
     Serial.print(TEST_VALUE);
     Serial.print('\t');
     Serial.print(foo);
     Serial.print('\n');
     delay(100);
   };
 
}

light is off, serial monitor shows "-1    -1"

commenting out the code inside the while loop still has light off
commenting out the serial.begin line also causes light to be on.

ok, I just ran that code n my Uno (IDE 1.0) and the LED turned on and stayed on.

let me see what I can find.

x != x is always going to return false because x == x is true

And how do you know it's between 1 and 6 (i do believe you), i can't find it on the datasheet.
I think i should be able to get it to work now.

IC pins are numbered anti-clockwise around the IC starting near the notch or dot.

looks like Airplay using AES encryption, but requires you to license the key from Apple.
http://en.wikipedia.org/wiki/AirPlay

not sure if the Arduino has the crunching capabilities to real time encrypt/decrepit the stream.

I went here because your embedded image didn't work:

looking at the suggested wiring diagram high (1) is not tilt, and low (0) is tilt.

it has a pull up resistor and the tilt switch pulls to ground when the tilt is sensed.

try changing the following line:

if (digitalRead(tilt)==HIGH) {

to

if (digitalRead(tilt)==LOW) {

Few questions:

What voltage difference are you getting across the load cell at different weights?
What voltage are you reading on your IC output pin at the different weights?

Are you using the DIP packaging or the SOL packaging (different pin outs)?
based on the PIN outs it looks like you are using the 8 pin DIP package, please verify

If you can supply the above questions, we might be able to give you some more specific solutions.

50 ~ 0.24 volts (using a 5 volt reference on the ADC)
150 ~ 0.75 volts
your IC can't pull all the way to ground or Vcc, you want to try swapping the outputs on your load cell to the IC to make the voltage go more positive instead of negative with added weight and check your gain amounts. 
Also it looks like the example blog changed the Vref for the ADC to internal setting Vref to 1.1 volts instead of the default 5V.

http://www.robotshop.com/dfrobot-4wd-arduino-mobile-platform-4.html
click on the Specifications tab

it has 2 different motor types listed: "green" and "yellow"

the green has the following stats listed for 6 volt supply:
No-load current(6V): 71 mA
Stall current(6V): 470 mA

This means with no load (IE holding your robot in the air with the wheels not touching anything), the motor draws 71 mA.
Stall current means that if you were then to grab the wheel and prevents it from moving it would draw 470 mA.

Your motor driver needs to be able to handle the strongest current draw of your motor without overloading.  My understanding is that to do this it needs to be able to handle the stall current of the motor that is connected to it. So for this motor you would need to handle 470 mA per motor.  The chassis has 4 motors.

If you were to use the following controller: http://www.adafruit.com/products/81
It has 4 channels that each can handle a maximum of 600 mA per channel (1200 mA peak -per spec sheet -> non-repetitive, t ≤ 100 µs).
Since 1 "green" motor needs 470 mA, you could connect 1 motor per channel with out going over the maximum current per channel.
There is 4 channels and 4 motors, so this would work.

if you were to use the following controller: http://www.amazon.com/DFRobot-Motor-Shield-for-Arduino/dp/B006D85PAS/ref=sr_1_4?s=electronics&ie=UTF8&qid=1323643740&sr=1-4
It has 2 channels that each can handle a maximum of 2000 mA per channel DC (see spec sheet for peak info).
Since 2 "green motors need 940 mA, you could connect 2 motors per channel with out going over the maximum current per channel.
There is 2 channels and 4 motors, so this would work.

Now for the "yellow" motor:
No load current (6V): 160 mA
Locked-rotor current (6V): 2800 mA
The first controller can't handle 2800 mA per channel. therefore will not work for "yellow" motors.
The second controller can't handle 5600 mA (2800 mA x 2) per channel. Therefore will not work for "yellow" motors.

So the conclusion I have is this: are you getting the "green" motors or the "yellow" motors?
"Green" = you can make either work
"Yellow" = neither can handle the peak current usage, so your controller might burn out if your robot got stuck.

Does that help?