I'd suggest you just get the camera hooked up and taking pictures on an hourly basis. The instructable you linked to should help you get that working. For an initial version, the sketch can be very simple, using the delay function to control the time interval. Later you'll want to get rid of delay and use millis instead. See the blink without delay example for inspiration.

Look for projects that use LED and keypad to drive menus and play with that separately. Adapt it to let you enter the time period or other parameters you want to set. Then look on the forums for help about combining sketches to get them working together.

Looking at the datasheet, it does appear that you could hook a TTL GPS to the openlog directly. It's not clear what the filename generated would be but I guess you'd find that out by experiment. You might also have to use some other device to set the baud rate appropriately.

What are you trying to achieve? A bit of cursory googling shows that DCC systems can command points and other accessories. What benefit are you hoping to realize by having the arduino do it? I expect a do it yourself rig will be considerably cheaper.

Certainly not especially difficult once you've done an arduino project or two. Be very cautious about hooking the SMS piece up though. It would be very easy for a bug or simple oversight to have your arduino sending thousands of messages - might get expensive. Test thoroughly!

If you have a lot of String usage in your sketch, the memory allocation that occurs behind the scenes may exhaust or fragment your available RAM. When that happens, unpredictable behaviour results. It's hard to tell from just that fragment, but you're doing a lot of what appear to be unnecessary casts to String, which will be contributing to the problem. Better to use plain old C arrays of char when you have so little RAM available.

That's usually caused by unconditionally reading the serial port when you don't know that there is data to receive. q.v. serial.available.

In order to play with it, because I don't have here something which could generate me this voltage

Really? All you need is a wire to connect pin 2 to 5V or gnd on the arduino's pins.

the motors are getting really hot when i am running them

Have you tried adjusting the little current limiting pot on the driver board? With the power off of course.

You're adding the newline character you receive to the end of the string, so your comparison fails. try checking against "xxx\n" instead, or don't concatenate the newline.

You're currently only executing your switch statement when something is detected from the remote. Run it unconditionally; you may need to save the response from the remote when you do get it in another variable that drives the switch.

Blink without delay will serve you well in this scenario. Keep a variable with your desired servo position and another one with the current position. Check every time around loop whether it's time to move the servo and if so, whether there is any movement needed.

Psuedo threading is going to bring a whole bunch of new problems - I'd suggest that it really isn't necessary or desirable in this case.

You'll need to get rid of the delays and use millis instead. Take a look at the blink without delay example to see millis in use. For your code, whenever the PIR is high, store millis in a variable and turn the LED on. Independently, check that variable against millis to see whether five seconds have passed and if so, turn the LED off.

A cursory look suggests that under the hood, that library sends images line by line. You could probably build something around the EPD_Class::line function that does away with the need to hold all the image data - just send each line as you get it from the xBee.

Get yourself an arduino that can write on SD cards, e.g. the Arduino ethernet. Use the softwareserial library to allow you to communicate with the GPS while leaving the hardware serial port available for debugging.

Read NMEA input into a buffer a sentence at a time, write it to the SD card. Actually, you probably want to just send it to the serial port to start with so you can be see it's working and then add the SD bits.

Nothing sticks out as an obvious issue. Here's a possible hazard though:

Code:

     deg = 360.0 * position / total;

Can total ever be zero? I'm not sure what the arduino does on a divide by zero condition, but you might want to test for it.

Other than that, it's time to pepper your sketch with serial print. Since you're resetting nightly, do you have another arduino with the ability to write to an SD card - might make it easier to gather and save telemetry.