I tried but i couldn't

Try harder. If there are uses that you can't see how to remove then you can always ask here.

I suppose you could do all of that, but bear in mind that the Arduino-based solution for running the dashboard, lights etc will be considerably more complex and less reliable that the existing plain old hard-wired version. The fact that you could doesn't mean that you should.

It's conceivable that the camera is sending 0xFF for some reason (do you have a spec for the serial protocol being used?), but this is also the value that you get if you call serial.read() when there is no data available in the buffer. So, make sure that you have called serial.available() and got back a positive answer before you do that read().

What do I need to do to power up the modem

You need to have the necessary hardware and connect it up appropriately. You've already posted a link to an article which shows you what is involved. Have you got the Arduino and modem hardware connected up properly yet? The article shows you how to write a sketch to send AT commands to the modem and get back AT responses. Have you tried doing that?

I don't feel for polling the RTC time. This will hold up the microcontroller, which can be a problem in case I want to add more functionality than just a datalogger.

For what it's worth, polling to see whether it is time to carry out some action is the way I'd recommend, both for this 1Hz output and for the other scheduled actions you're likely to want to add later.

A 1Hz event is not fast enough to justify using an interrupt, and using an interrupt takes you down a route which will not scale up at all when you want to add additional scheduled functions.

Just use the polling technique demonstrated in the 'blink without delay' example sketch. It is up to you whether you want to carry out these timed actions based on the Arduino's internal clock or the RTC, you can poll whichever of them you want.

This approach leads you to a sketch where your main loop is simply polling for each of the possible events it may need to handle (time to do a scheduled activity, serial port input available, button pressed etc) and responding to each event as it happens.

I haven't reviewed the whole sequence of interactions with the camera, but three things leap out at me:

After sending a command to the camera, you then throw away the contents of the serial buffer. Two questions: Why would there be anything in the serial buffer at this point? How do you know that you aren't throwing away part of the response to the command that you just sent? It would seem more sensible to empty the buffer (if necessary) immediately *before* sending the command. But I question why there would be any unexpected input in the buffer anyway. If there is, I'd say you're doing something wrong elsewhere.

When reading the response from the camera you check there is at least one input character available and then read lots of characters. It's just a matter of luck and timing how much data is actually in the buffer. You need a better scheme for reading bytes from the buffer as they arrive and forming them into a message. I suggest pulling them out of the serial port into a byte array and see what's in the array to decide whether you have got a complete message there. I don't know enough about that serial protocol to say how you should recognise the start/end of a message, but you absolutely need to have some way.

You have some delay() calls in the code to read from the serial port. If these are necessary for correct behaviour then you're doing it wrong. (For example, putting a fixed delay after sending the command will increase the chance that a whole response will be waiting for you to read by the time you start reading from the serial port - but if you process the serial port correctly, you will not be relying on having the whole message waiting for you.

I know the page show AT commands but I still don´t know the exacle code for receive sms and save the message into a variable.

Yeah, I know. I'm just tackling the problem one step at a time. First problem is to get the modem powered up and working, and understand how to send it AT commands and get responses back from it.

Have you got that working? Never mind what AT commands you need in order to receive SMS messages - can you send it any old AT command and read back the corresponding response?

If that's working then the next step will be to send the specific AT commands to access received SMS messages, but I don't know whether you're up to that point yet.

When I wrote that it wasn't an Arduino problem I was only referring to the video processing part of the problem. That part is best done on a PC, and there are plenty of video processing frameworks that can make that quite easy to implement. If the video processing is going to be triggered/controlled based on input from piezo sensors then it would be sensible to use an Arduino to present the piezo sensor input via USB and have the video processing application use that as an input.

You linked to a page that showed how to connect the GPRS modem and send it AT commands and see the responses.

Haver you got the modem connected and powered up and responding to AT commands?

What examples have you found using that modem?

Well this is a code in transition I guess I forgot to put it back the way I had it and just copied in my hacked code. And please, I ask you for help without a condescending attitude.

The condescending attitude is telling you that you're expected to put in some effort to solve the problem yourself, and by the time you're desperate enough to ask for help you should be in a position to provide a clear minimal sketch that compiles, runs and demonstrates the problem you want solving. Asking people to debug code that has been shredded and hacked about just wastes everyone's time. You're asking strangers to give their time and skills to help you. The least you could do is make life as easy as possible for those people trying to help you.

Therefore it would be a daunting task to start duplicating variables in order to separate the legs...

You need to abstract out the complexity.

If you have a number of legs that all behave similarly, create a class to manage one leg and then create as many of those as you need. If the control logic for one servo needs to send commands or share state with the control logic for another servo, configure the master servo with details of the slave servo it is to control. If your control logic needs to have a servo move to a specified position in slow time, create a class that controls a single servo that encapsulates the logic to decide when to adjust the position and by how much so that you can just keep running that code for all servos and they will all move themselves as required. Then your code looks like: an overall manager class that knows how to move the device by moving the legs. A manager for each leg that knows how to do an action with that leg ("put your foot here") by flexing the joints in that leg. A controller for each joint / servo that knows how to move the joint at a given speed and direction.

I would be grateful for your view on hardware requirements for the 'Arduino OptiMouse library' route and hardware requirements for your preferred route too.  Would they both need an Arduino board or...and which board might that be?

I haven't used the Arduino Optimouse library, but it's described here and doesn't seem to have any requirements for any particular Ardunio - if this is your first Arduino project I'd suggest starting with a Uno just because it's the most widely known and used variant. The Uno also gives you maximum flexibility for using add-on shields later if you find you need to go down that route. And of course you will need an optical mouse per cylinder that you want to monitor, and you'll need to look inside the mouse and find what chip it uses and track down the data sheet for that chip to find which pins do what.

I assumed I was reading out the data faster than the camera could send it to the serial port but even when I put a delay statement into the read loop the image data stops after 80 bytes or so.

This immediately makes me guess that you are not reading the SoftwareSerial correctly, because if you are there should be no possibility of reading bytes faster than they were being written and no possible need for delays. If the delays are big enough to prevent underflow then naturally they will also be getting big enough to provoke overflow on the serial link.

I suggest you need to post your code before you get any further. If I were you, I'd remove the SD card from the equation and produce a minimal sketch that just read frames from the camera and reported the size. That will enable everyone to focus on the problem without having to understand your whole sketch.

Is there a fixed reference somewhere near the surface of the cylinder that you can use to position a fixed pointer just above the surface of the cylinder? Position the pointer as close to the surface as you can manage, so that the cylinder just barely avoids scraping it. If the cylinder is flexing towards the pointer it will make contact. Perhaps you will be able to see/hear that directly, but if not then apply some sort of colour to one part so that it leaves witness marks on the other. (Sorry, I can't visualize the physical setup well enough to give a less vague suggestion.)