Sorry, I had one incorrect line in my sample code for you.  Change the following line:

active != active;

to

active = !active;

That's what I get when I rush something and just compile it without running it.

The tamiya twin gearbox motors are only rated for 1.5-3.0 volts.  People have run them at 5 volts, but their life can be severely shortened by doing so.  They just aren't built to handle more than 3 volts.

That being said, that gearbox is well suited to small robotic rovers.  Just don't overdrive the motors.  I burned out one of mine with about half an hour of runtime at 5 volts.  (That was half an hour of intermittent usage over a period of a few hours as I was writing and debugging my control code).

I then replaced both motors with a pair of these: http://www.robotshop.com/eu/solarbotics-regular-motor-3.html and they've been running like a champ ever since.

Almost, but not quite.  My last instruction was a bit misleading though, so that's my fault.

I really meant to say fill in the two blocks of the second if statement.  The first if is just toggling the active state, and there shouldn't be any other code in there.  The second if statement has two blocks (a block being a section of code surrounded by { and }).  One will execute while active = true, the other will execute while active = false.

If you don't want anything happeneing while active = false, then leave that section blank.

Delete the code you added in the first if() and see if that does what you want.

It appears that mini push button board has some hardware debounce (there's a resistor and a cap on the board, and I think it's safe to assume that is what they're there for).

If I am understanding correctly, you want to toggle your servo/led activity on and off with separate activations of the button.

Code:

boolean active = false;
boolean lastState = LOW;
boolean currentState = LOW;
byte buttonPin = A0;

void setup(){
 
 
}

void loop(){
 
  currentState = digitalRead(buttonPin);
 
  //When lastState is LOW and currentState is HIGH, we have detected a rising edge transition
  //ie the input has just gone high.  This is when we toggle are active boolean
  if(lastState == LOW && currentState == HIGH){
    //toggle active state
    active != active;
  }
 
  lastState = currentState;
 
  if(active){
    //Perform actions when active = true;
   
  }
  else{
    //Perform actions when active = false;
   
  }
 
 
 
}

I was unclear exactly what you wanted to happen in those two states, but simply fill the two if blocks with the code you wish to have executed for each state.

If we crunch a few numbers, we can easily get an idea of how long the train can be run via the solar panels.

12V solar panels at 25mA = 300 mW of power.

12V motors drawing 2A = 24 watts of power (or 24000 mW).

At 100% efficiency (unrealistic, but just to get some ballpark numbers), for every minute the train runs, the solar panels will need more than 80 minutes to recharge.  If we factor in the inefficiencies of the system, you're looking at increasing that time by upwards of 50%.

but I don't know how to do this 60 times, or otherwise keep track of when to log the numbers, when the minute is up. How does one use interrupts? What's the digital--> blink you referred to?

Each time you add to the average, increment a separate counter variable as well.  When the counter = 60, log and reset.  Something like:

Code:

  temperature += (voltage - 0.5) * 100 / 60;
  tempCounter++; //this can be defined as a byte (but if you want to increment up to values above 255, you'll need to use a larger variable
 
  if(tempCounter == 60){
    //write out your temperature
   
    //reset variables
    tempCounter = 0;
    temperature = 0;
  }

There are several timer libraries available that will help you easily run the above code at some specified interval.  No need to reinvent the wheel, except as a learning experience.  But for that you can just read the code those libraries use.

That's great news, thanks! I need to do several dozen caculations in a second, so I probably have the time, and lots more to spare.

You could easily do several thousand calculations per second more than likely.

You want VCC1 and all your logic inputs running off the Arduino power supply.
You don't want a 10k resistor inline with VCC1.
You need to flip the ground side diodes on your motor outputs.
All grounds should be tied together. (this includes Arduino and motor supply grounds)

The Arduinos are capable of both floating point math and trig functions.  They are relatively slow, but if you have the time, they will work.

You have all your code in setup().  That function only runs once, when the unit powers up to initialize.

You need to move most of your code into loop(), which runs continuously.  The only stuff that should be in setup() is your Ethernet, serial, and client setup.  You also need to move your analogRead() from your variable declaration into loop() as well, as that only runs when the variable is declared (as in just once as well, for a global variable)

1n4004 diodes aren't ideal for motor drivers.  You should really use a schottky diode for that purpose.  Something that should be well suited to the SN754410 as an example would be a 1n5818 schottky diode.  1amp current max, 30volts max, fits fairly well with that h-bridge IC.  If you really need 36v, you could go with the 1n5819 (or if you don't need more than 20v peak, the 1n5817).

Do you have a link to the datasheet for this "Potentiometer strip with an open wiper".

This is not documented anywhere that I've ever seen, and not well known either, but the PROGMEM attribute does not work properly with automatic local variables. Because these variables are automatically cleaned up when they go out of scope, that conflicts with the 'immutable' natural of PROGMEM variables in flash.

It may work by declaring them static, but I've never tried that.  It certainly works by keeping them global.

which has always seemed rather odd to me, but that's the standard

Given the typical use for a hobby servo, such as steering a car, positioning a rudder, operating as a throttle, etc., 60 degrees is generally the full range that the servo needs to sweep. How much throttle travel do you have, and how much servo movement is required to make the throttle travel that far?

Well there you go.  Makes more sense knowing that.  Guess I've never used hobby servos in the manner they were designed for.

I tired 1000 delay after the attach, I should do that after the command to, didn't try that.

I will try thanks.

You should try to make your code a little smarter about how much delay it needs.  All servos have an advertised speeds, typically in seconds per 60º (which has always seemed rather odd to me, but that's the standard).  A bit of quick math can give you a value of say, milliseconds per degree.

So say your servo takes 0.17 second to rotate 60 degrees (that's fairly typical for a hobby servo, not too fast, not too slow).  That is 170ms to rotate 60º or 170/60 = 2.83ms to rotate 1º.   Round that up to 3ms per degree.

As long as you keep track of your current position, and your target position, you can easily calculate how long it will take for your servo to move to the new position.

I'd also recommend handling the pan & tilt together.  That way it pans and tilts at the same time, one synchronous, smooth operation, as opposed to first panning, then tilting serially.