Raspberry Pi to Arduino over serial USB
Today I was playing around with sending data from the Raspberry Pi to an Arduino over serial USB, but there was an issue with the receive rate of the Arduino - it was lagging very badly behind the send rate of the RPi.
Here's a bit of background. To start this robotics project, I first bought a couple of items from Singapore Robotic, an online shop that specializes in robotics. The catalogue isn't as extensive as many of the larger online retailers, but I think the selection is good. We can't be too selective for a market as small as Singapore. Anyway here's my shopping list:
The idea was to use my orientation data to get some actuation going on my Arduino. Since I don't have any sensor besides the built-in LED on the Arduino, that is pretty much the only choice I have. The LED is to blink quickly when the phone is vertical or near-vertical, and blink slowly otherwise. For starters I would only have two blink rates - a fast one for the vertical state and a slow one for the not-so-vertical state.
I followed this article to get a skeletal program for USB communication. Sending from the RPi and receiving from the Arduino were both fine.
The problem came when I incorporated the LED blinking. The slow blinking consisted of 200 ms of light-on time and 200 ms of no-light time, repeated indefinitely. This by itself is a bit of a problem because say you want to change the blink rate to something faster: the program has to wait till the entire 400 ms cycle is done before it can read the new value (to know that the blink-rate need to be changed) and adjust accordingly. But this was a relatively minor problem.
The biggie was that it took a really long time for the Arduino to respond to my phone movement. My suspicion is that the serial communication has a buffer that's like a queue - when we transmit data from the RPi the queue gets longer, and each time the Arduino reads the data the queue gets shorter. But because the Arduino has that 400 ms cycle, it reads the buffer much more slowly than the RPi writes. The result is that it always lags behind the sensory input from the phone/RPi.
I'll need to investigate further on this.
Here's a bit of background. To start this robotics project, I first bought a couple of items from Singapore Robotic, an online shop that specializes in robotics. The catalogue isn't as extensive as many of the larger online retailers, but I think the selection is good. We can't be too selective for a market as small as Singapore. Anyway here's my shopping list:
- 1x Arduino Uno Rev 3
- 1x digital multimeter
- 1x wire stripper
- 1x soldering stand
- 1x 2-wheeled chassis with 2x DC motor and a battery holder
The idea was to use my orientation data to get some actuation going on my Arduino. Since I don't have any sensor besides the built-in LED on the Arduino, that is pretty much the only choice I have. The LED is to blink quickly when the phone is vertical or near-vertical, and blink slowly otherwise. For starters I would only have two blink rates - a fast one for the vertical state and a slow one for the not-so-vertical state.
I followed this article to get a skeletal program for USB communication. Sending from the RPi and receiving from the Arduino were both fine.
The problem came when I incorporated the LED blinking. The slow blinking consisted of 200 ms of light-on time and 200 ms of no-light time, repeated indefinitely. This by itself is a bit of a problem because say you want to change the blink rate to something faster: the program has to wait till the entire 400 ms cycle is done before it can read the new value (to know that the blink-rate need to be changed) and adjust accordingly. But this was a relatively minor problem.
The biggie was that it took a really long time for the Arduino to respond to my phone movement. My suspicion is that the serial communication has a buffer that's like a queue - when we transmit data from the RPi the queue gets longer, and each time the Arduino reads the data the queue gets shorter. But because the Arduino has that 400 ms cycle, it reads the buffer much more slowly than the RPi writes. The result is that it always lags behind the sensory input from the phone/RPi.
I'll need to investigate further on this.