I have figured out what the issue is. The problem is the NewHaven displays can only handle i2c with a SCL clock rate of up to 100Khz, but no faster. By default, the SCL clock rate on an Arduino UNO R3 is much faster than this. You actually need to slow it down. The easiest way to do this is to adjust the TWBR variable.
I did this: TWBR = 100000; This solved the problem for me. Another person has suggested doing this, which would probably be a better way:
I have the EXACT same issue with 2 different Newhaven LCD's. Both LCD's work fine with serial communication, but when I try to use i2c, they miss characters. I can't get it to display "Hello World!!"... instead it displays "loWrl!!" as an example. What the heck is going on here?
The Arduino YUN might be perfect for this since it has wifi built-in.
I have a robot too that works in a similiar fashion, but I chose to do it a little bit differently. I have a Raspberry Pi in my robot that talks to an Arduino. The arduino handles the IR sensors and ultrasonic ping sensor, as well as the servos. The code on the arduino implements a simple serial interface where I send it commands from the raspberry pi over the pi's USB port. I can manually control the robot via SSH to the raspberry pi and opening a terminal to the com port and typing commands to the arduino. Or I can run my program on the pi and have it take control over the robot for autonomous functions. Actually most of the automous functions are handled on the Arduino code. But the cool thing about the Pi is I also have the Pi Camera, which allows me to stream live HD video from the robot. (Yes, I have a wifi adapter on the Pi)
You will want a 5V regulator if you are indeed building your own Arduino clone. You'll need a 5V or 6V regulator for the servos. You *could* run the whole thing off a single 5V regulator, but you'll need to make sure you have one that will handle the amps for both the Arduino and the servos. If you have big, beefy servos, and lots of em, a single 7805 might not cut it.
I have done a circuit where I had an Arduino controlling the servos but had separate power going to the servos. It wasn't battery powered, but it worked fine.
My custom RC ship transmitter has 8 AA batteries (12V) which is well within the UNO's regulator range.
I have a robot that is powered by an UNO and a 11.1V 3S LiPo battery and has 2 on-board servo motors. The servos are powered directly from the Arduino's 5V regulator. It worked fine until I added 5 IR sensors. Now the current load causes the polyfuse to constantly reset the Arduino... Because I'm pulling way too much currrent. I plan to move the servo power off the Arduino and supply it instead from a UBEC I have lying around. The UBEC is essentially a voltage regulator. Of course I could also just wire up a 7805 with 2 caps and get 5V to the servos that way.
Don't attempt to power the servos with more than 6V or you will likely smoke them -- unless the servo is specifically rated to take that kind of voltage. Most are not.
You can also put on a header for a FTDI USB to Serial adapter so you can use a FTDI serial adapter like the ones from Adafruit or Sparkfun, This will allow you to send Arduino code to your board without having to pull the chip. You'll still need to load the bootloader from another UNO the first time, though.
I saw a neat trick on the Ben Heck Show... Ben made a suitcase robot that follows the owner. He used 3 ultrasonic ping sensors, but he disabled the ultrasonic transmitter on the 2 units on the suitcase. He used xbee modules on teh suitcase and on a pocket micro that the person it was supposed to follow wears. The person puts a little gadget in his back pocket that has an ultrasonic ping module facing to the rear. The suitcase triggers the pocket to "ping" wirelessly by the xbee modules, and then the logic on the micro in the suitcase times how long it takes the ping to reach each of the 2 sensors on the suitcase. It then calculates a PDI (differential) based on the timings so that the suitcase steers to follow the person. Was fairly impressive and accurate. They also modified the transmitter ping sensor by cutting the "can" shroud down to widen the beam, and they did the same on the receivers.
That still doesn't answer the question. Why do you think you need an Arduino? You can buy an off-the-shelf 2.4Ghz RC transmitter and receiver for $26 from HobbyKing. You need an ESC (electronic speed controller) to operate the motor. This connects to one of the servo channels and converts the servo signal to engine speed / forward & reverse. There is no need to involve an Arduino unless there is something else you want to do that you are not telling us. Like if you want your hovercraft to have autonomous (i.e. robotic) functions.
There are many questions you need to ask. What is the desired bit resolution of the audio and the samples per second that you plan to record?
Sounds like you know this already if you're talking about using an ADC, but for the sake of it... Remember that a Mic gives you AC voltage. Sound pushes the diaphragm back and forth which generates very small negative and positive voltages. In order to read those on an analog pin on an Arduino, you need to level shift the signal so that negative voltage is read as 0, null voltage is read as 512, and full positive voltage is read as 1023. If you don't do that, you won't capture the audio properly. You'll only get half the waveform and it won't sound right.
The analog input pins on an Arduino will only give you a range of 0-1023 which is a 10-bit number. You would need to 2 bytes to store each sample. If you only need 8-bit audio, you could map the 10-bit number to an 8-bit number and only store a single byte per sample.
Now for the samples per second... 8kHz is 8000 samples per second. So if you were recording 8-bit audio, 1 second of audio would be 8000 bytes. If you are doing 10-bit audio, that would be 16,000 bytes for 1 second of audio!
As for file format... the most common would be a .wav file. A .wav file is basically just a header describing how may channels of audio, the sample rate, etc, followed by the raw stream of samples. You can find documentation explaining how to create .wav files on the Internet. The added bonus here is if you do it right, you can test your recordings on a computer to verify you are actually capturing the audio correctly.
As for playback... there are lots of different ways to about this. I'd look at using an SPI DAC (digital to analog converter) chip. Since you're already reading the .wav file back in via SPI, why not output the raw samples to the DAC?
You could of course pulse digital I/O pins with an added circuit to approximate the sound on a speaker, or you could try using the analog pins and level shift the voltage. In either case, you'll likely need an amplifier.
Yes, the UNO is just fine for the job. i2c is fairly easy to do with an Arduino. You'll just hook up 4 wires to the LCD. Do you know if the LCD is 3.3V or 5V? Connect SDA to A4 and SCL to A5. You'll need to use the Wire library. Take a look at the Wire example sketches in the Arduino IDE. Also plenty of tutorials talking to various i2c devices out there. Just google "Arduino i2c" and you'll get a bunch.
You'll need the datasheet for the LCD to learn what data you need to send to get it to do what you want. Usually it will look something like this:
I've actually got some related experience to this. I have been building a custom RC transmitter for a ship model with dual engine control (and rudder). While the ship is not exactly robotic, it has a lot of robotic concepts. Let me explain.
In a normal RC transmitter / receiver, you collect the stick positions from the joysticks by reading the analog pots. You then encode the stick values, usually to PPM, and then this is transmitted by radio. The radio receiver decodes the PPM for each of the servo channels and converts this to PWM which is output to the servos. For engines, you would have an ESC (electronic speed controller) that converts the PWM to engine speed and direction for each engine.
Here's how my controller is different. What I did is hack an existing RC transmitter and removed the circuit board from the transmitter. I disconnected both the joysticks and set them aside since I'm not using them. Each joystick has 2 axis, and each axis is hooked up to a 10k pot. I bought a quad 10k digital potentiometer chip which is an i2c chip that allows you to vary the voltage between the low and the high via microcontroller. It does exactly what a potentiometer does, but is controlled by a microcontroller. So... in my transmitter, I replaced the joysticks with my own controls, but the controls are connected to the Arduino, not the transmitter. I use the Arduino to read the values and then manage the analog signal being sent to the transmitter. Why would I go to all this trouble? Because my transmitter simulates the actual engine orders and response times on a WW2 Fletcher class destroyer. My transmitter has 2 engine telegraphs instead of throttle. When you want full speed ahead, you move both telegraphs to "Ahead Full". There is a slight delay followed by an audio acknowledgement of the order. (I use a serial-controlled MP3 player to play the sound effects. You'll actually hear "All ahead full, aye! followed by Ding! Ding!" which represents the engine room acknowledging the engine order. The the engines are commanded to slowly come up to speed, representing the actual time it would take for the turbines to get to full speed. Then if you throw the engine telegraphs into reverse, the same kind of thing happens. There's a an acknowledgement of the order, then the engines have to be slowed to a stop first (so you don't damage the turbines!)... then the "reverse" turbines are engaged and the motors start spinning in reverse, slowly at first, until they come up to speed. For steering, I'm actually using a rotary encoder. To get full 30 degree rudder deflection, you have to rotate the wheel 4 full revolutions, just like you would on the real ship. And on the real ship you are just setting the rudder position desired. The rudder motor in real life takes time to get the rudder to the ordered position. My transmitter simulates that as well.
I have a video demo of this whole thing on breadboard here:
Of course this is an RC model ship, and we could get in real trouble real quick by having such slow responses. There's of course an emergency override where the engine telegraphs become linear throttles and the steering only takes 1/2 a turn for full rudder deflection.
Anyway... since the transmitter is being driven by the Arduino, I could have the ship execute automatic patterns. For example, I could have button press make the ship run a figure 8 pattern. Or a zig-zag pattern. Or whatever. Completely autonomously.
One could also put an Arduino in the ship and have it read the PWM on some of the channels of the receiver and make certain ranges of values execute different functions on the ship.
Also, it turns out the transmitter board itself is really just a programmed microcontroller (MA803SA from Megawin) that is not all that different from an Atmel chip. The microcontroller is programmed to read the analog inputs for each of the channels, encodes these values as PPM data, then sends the PPM data to a separate RF module. One could reasonably figure out the PPM encoding and program an Arduino to create the PPM signal going to the RF module itself.
Anyway, I digress. For your robotic boat, I'd recommend using ESC speed controllers for the motors. Make sure you get brushed or brushless depending on whether the motors are brushed or brushless. Use a BEC (battery eliminator circuit) to provide 5V to the Arduino from a LiPo battery. Use a servo controller shield or servo controller on the Arduino (I really like Adafruit's 16-channel controller which can be had for $14.95 US) to output your signals to your motors and servos. If you ALSO want to be able to manually take over control by radio...consider hacking a HobbyKing 4Ch or 6CH transmitter and receiver... they are only like $26 US together. Cheap as heck and easy to hack into. Yes, there are more expensive TX/RC gear designed for hackers that have serial interfaces... but why bother spending $$$ on that when you can hack something for a fraction of the cost? Anyway, good luck on your project.