Put a voltmeter on the Arduino's 5V supply and see what voltage you're actually getting there in the scenario where the problem happens.

I was hoping that I could affix the PB to the side of the battery towards the bottom and induce a resonnance into the battery.

The pseudo-science on that site did not look very convincing to me, but what they were talking about was applying a high frequency electrical AC signal, not a mechanical vibration. Trying to get an electrical oscillation in the megahertz range with any significant voltage or current strikes me as rather difficult and I'm not convinced it's feasible without some rather specialised equipment.

The process of desulphating lead-acid batteries is not novel and usually just involves adding a few pills into the electrolyte and then discharging and recharging the battery a few times. Using an AC component on top of a DC charging current was proposed several decades ago as a way to recharge zinc-carbon cells that were not normally considered rechargeable, it was not very effective under ideal conditions and not really of any practical use. I suspect that's where the inspiration for this new multi-megahertz process came from, though.

The error is induced by the slight difference in the resistors used in the voltage divider, hence the need for the correction factor.

If that is so then the effect would be linear and could be corrected by applying a simple scaling adjustment to the calculation.

Sounds like you want to create an oscillator. You could set that up using an NE555 timer and a couple of external components.

If you want to make your Arduino output that frequency directly, it would probably require configuring one of the hardware timers (and I don't know enough about those to say whether that frequency is achievable).

You haven't said what you want to do with that frequency signal i.e. how it gets applied to the battery. I suppose you'd be switching current or something, and doing that at megahertz probably introduces challenges of its own. I can't imagine how a piezo buzzer would help you with that unless you were planning to physically vibrate the battery - and doing that at megahertz frequencies sounds rather difficult.

If you're planning to actually power down the nRF module it might make sense to supply it from an Arduino digital output pin (as long as the nRF module is not the amplified type, it doesn't need much current). I haven't measured the voltage drop between the Arduino's logic supply and a digital output but presumably there will be some. You could just leave the nRF disconnected, power it up and see what voltage you actually get on the digital output. If you need to drop it slightly I'd suggest one or more diodes in series, but it may be that it's already within the safe range for the nRF. If you decide to power it directly from the battery then most likely you will need to drop the voltage slightly and a couple of diodes would do that nicely.

Using goto: is a bit ugly but shouldn't cause any problems. Calling setup() again from within loop() is also pretty unconventional but I don't see you doing anything in setup that would cause any problems if you ran it again.

Since it works OK until you connect the load up I'd suspect a voltage supply issue, most likely that the Peltier is taking so much current that the Arduino's voltage regulator is browning out. Can you describe how the Arduino logic, L298 logic and L298 load power supplies are arranged?

I don't want a delay of 2 or 3 microseconds, neither nanoseconds, nothing, delay=0

A delay of zero is physically impossible, and it is physically impossible for any external device or circuit to detect whether you have achieved it. Since this is not a credible requirement, you ought to be more precise about what you're actually trying to achieve. How small a timing difference are you aiming for?

Im not sure what you mean by PP3 but its a normal 9 volt battery and yes the servo is running off of it.

I don't know what you think a 'normal' 9v battery is. PP3 is a standard battery package. If you don't know what a PP3 battery looks like, google is your friend.

Should i set up a completely different power source fore the servo? or if i switch to the AAs will that increase my overall battery life?

PP3 is a terrible choice for powering a servo. It only has a miniscule charge capacity and also very low current capacity and they are also relatively expensive. Replace that PP3 with four rechargeable AA batteries and you will get a massive increase in battery life. For the final product, I suggest you work out how long you need a battery to last for and then see whether the life of your AAs is sufficient - depending what you're trying to achieve it may be necessary to go to bigger batteries. Those tiny PP3s are a waste of time and money, though - get rid of that right away.

Is there a way to clear the program memory

Depends what you mean by 'clear'. A brand new out-of-the-box Arduino usually isn't clear - it comes preloaded with a bootloader and a small ketch that just blinks the LED. It might be possible to erase either the bootloader or the sketch, but it wouldn't be easy since the IDE is designed to upload a compiled sketch. In any case I can't imagine any situatin where that would be useful.

If you just want to stop your Arduino doing 'stuff', upload Fletcher Chr's sketch that does nothing.

Are you talking about quantization errors in the ADC, or that the ADCs are not consistent from sample to sample (i.e. consecutive samples of the same value gives significantly different answers) or that they are not consistent with each other (different ADCs give significantly different answers for the same voltage)?

If it's inaccuracy caused by errors in the resister values, these should be consistent and linear and would be easy to correct for by applying a scaling correction. If it's a different type of error you need to know the characteristics of the error to know how best to compensate for it. A lookup table would be a last resort given how little memory you have available, but without knowing what sort of error you're dealing with and what sort of accuracy and consistency you're trying to achieve, it's hard to know what other options are suitable.

I would like to know how I could develop automated testing for PCB's and hardware modules in Arduino.

ArduinoUnit looks as if it is intended to allow the Arduino to do a self test. That doesn't sound like the sort of thing you're trying to do, although I can't be sure because you've given almost no detail about what you're trying to do.

I suggest you take the following approach:

Decide what you are trying to achieve.
Identify the problems and issues that your solution needs to overcome.
Decide how to resolve each problem.
Design, implement and test your solution.

For example: what are you trying to achieve? Test one "PCB and hardware module"? Test multiple similar ones? (At what speed?) Test different ones? (How will the test criteria for new modules be defined?) What do you mean by 'test'? What types of faults do you intend to test for?

As far as I remember, the NRF24L01 is fussy about the supply voltage on Vin but will tolerate higher voltages on the signal lines. Does your Arduino provide a 3.3V output? If so, that's perfect to power the radio module. The other lines can use plain old digital pins. If you don't already have a 3.3V supply then you can put your 3.7V Li-Po through a couple of diodes to drop the voltage slightly (I seem to remember silicon=0.7v, germanium=0.3v).

If you can detect the presence of the milk, then you can take a picture when it changes from 'absent' to 'present' (to prove that the milk did actually arrive) and again when it changes from 'present' to 'absent' (to record what happened when it was taken).

If you get that working I would suggest taking several pictures at (say) one second intervals since you can't rely on a single picture giving everything you need.

I don't know what sort of camera you're envisaging - are you sure the whole thing won't just get stolen?

If you had a wireless webcam (and a means to power it) you could do the job from your PC using standard freely available motion detection software.

Given that you are not looking for a high precision RPM signal and have a lot of problems to solve before you  can use the motor's built-in RPM output, it might be more pragmatic to add a separate sensor. It would only take a dab of paint on the shaft and an optical pickup.

You don't seem to have any logic to control how rapidly the acceleration occurs - you just ramp the speed up each time accelerate() is called. Since it's called unconditionally from within loop(), it's not surprising that the acceleration is almost instantaneous. What puzzles me is why it wasn't behaving like that previously, but perhaps you had some code that took significant time to run which was slugging things for you.

I suggest you use the same technique you used (and then commented out) in monitor() to run the accelerate() function at regular intervals.