Category Archives: Hardware

Raspberry pi setting up model A with camera module as bot.

Using my model B with a usb video camera was fun but with the new camera module and the cheaper model A I wanted to give those a go.

rPi model A (no ethernet, one usb) $25
Camera Module for rPi $25
RTL8188cus wifi dongle (<$5)
Something to drive around
Circuitry to drive motors
Circuitry to tell you when batteries are low
Connect Over Serial:

To do this I used a usb<->uart converter plugged directly into the rPi as the pinout describes here Using 115k, 8n1 and a putty session.

Connect wifi:

Update rPi, setup Camera files:

Free up some space (I’m on a 2 gig sd)

This will ruin X11/gui interface. You might want a bigger sd if you still need that, I dont want it for now.

sudo apt-get remove `sudo dpkg --get-selections | grep -v "deinstall" | grep x11 | sed s/install//`
After that I have about 400 megs left 🙁 not much to play with.If you want to take off more here is an article

Streaming from the Camera Module:

Looking around I see no /dev/video0. So upon looking through the vast internet I dont think there is a video4linux driver. How lame, I thought this would be plug and play. I’ve written my own cmos camera drivers and broadcast them through bluetooth with the stm32 it’s not trivial. I was hoping for a simpler solution being that this camera was expensive and that the pi is a powerhouse compared to my other units. See this article for more details about why it does not work and some ways that it might

This page has a more optimistic output with three different ways to stream.

First thing I had to install VLC, ouch 132mb gone. Then I tried

raspivid -o - -t 9999999 |cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264

The latency was really bad, seemed like minutes till I actually got the video. It kept restarting over and over and hitting this error

[0xd01d28] main input error: ES_OUT_SET_(GROUP_)PCR  is called too late (pts_delay increased to 1953 ms)
[0xd01d28] main input error: ES_OUT_RESET_PCR called

So I found this link that talks about “low latency” gstreamer and I was using gstreamer on my linux box the other day with much interest so I was pulled more to this.

Raspberry Pi camera board – Gstreamer

Before installing gstreamer I deleted more stuff with apt-get remove as in the above article. Left me with about 300mb, I didnt uninstall vlc since it was the only thing I have going so far. Gstreamer was 154mb, these packages are huge. Here goes another 20 minutes waiting for that.

Fought with this for a while, I could never get a client to work with gstreamer. Tried vlc again with slower/smaller settings and it was just as crappy.

VLC Sorta Success:

After working with these tools for a long time I got this to work pretty well. Its smooth fast and no freezing

raspivid -t 999999 -h 600 -w 800 -fps 30 -hf -b 2000000 -o - |cvlc -vvv stream:///dev/stdin --sout '#standard{access=http,mux=ts,dst=:8080}' :demux=h264

I tried to make it smaller and less framerate/size/bitrate each time it got worse and worse. With a smaller bitrate/fps it would freeze and disconnect, which does not make any sense to me, with less data it should work better right ? But I think it has to do more processing if you scale it in any way which hogs up the cpu and screws everything up. I read tons of articles the last one was this

Making Webpage:

Installed apache then used this on a video.html page

<!DOCTYPE html>
<OBJECT classid="clsid:9BE31822-FDAD-461B-AD51-BE1D1C159921"
 width="800" height="600" id="vlc" events="True">
 <param name="Src" value="http://PI_IP_ADDRESS:8080/" />
 <param name="ShowDisplay" value="True" />
 <param name="AutoLoop" value="False" />
 <param name="AutoPlay" value="True" />
 <embed id="vlcEmb" type="application/x-google-vlc-plugin" version="VideoLAN.VLCPlugin.2" autoplay="yes" loop="no" width="640" height="480"
 target="http://PI_IP_ADDRESS:8080/" ></embed>

Latency !!:

I’m getting like 4sec of latency which ruins everything. I had much better results with the usb cam. However these people seem to think it will work much faster with “no latency” so I’m going to try their netcat solution later

Yes at least 3 second delay. No change in delay with bitrate. Looking at the nc solution this is the most complete example I can find (first line run on pi, second on windows)

raspivid -t 999999 -o - | nc 5001
c:appsncnc.exe -L -p 5001 | c:appsmplayermplayer.exe -fps 31 -cache 1024 -

 My exact example was
On the Pi:

raspivid -t 999999 -vf -hf -b 2000000 -o - | nc 5001

Then on the machine (where I had to download mplayer and all the codecs)

raspivid -t 999999 -vf -hf -b 2000000 -o - | nc 5001

This would start off just like the rest but after about a minute of running the latency was gone. There is maybe a 200-300ms latency. I could snap my fingers and see it way before I could say “one Mississippi” (very scientific).

I don’t get it. I read online about all these “it does not have enough power” etc. etc. My stm32 could pump data out via the DMA as fast as we could process it.

  1. Video is shaky, camera is stable but it looks like what you are looking at is in a earthquake
  2. Motion is frequently blurred and pixelated, smearing across the screen
  3. Camera is much more expensive than a usb solution
  4. All normal ways of streaming have a 3+ second latency, some other methods have less latency (netcat) but they are not reliable and seem to crash all the sudden. Plus they are not streaming into a webpage or anything simple.
  5. reducing bitrate or resolution just seems to make things worse

If I have to choose between this and a simple usb camera I was having lots more luck with usb camera. I can see the application of the raspberry pi camera in maybe a webcam or something that takes pictures, but as eyes for a teleop bot the usb camera may not be as HQ but it also did not smear, shake, lag or cost as much !


rPi low voltage supervisor, let me know before batteries die


Know when the batteries voltage decrease to 7.0v because after that they cannot support the 7805 and decline rapidly. If we are moving and the batteries stop supplying enough current to the 7805 then the pi will stop responding and remain in whatever state it was in. So if we were going forward we will run into a wall and not stop. I want to make sure I know if the batteries are low and then at least I can stop controlling the unit!

 How I did it:

I used a P-Chan Mosfet, pull down and a voltage divider. The voltage divider takes the voltage right from the battery pack. So when the batteries get to 7v the voltage divider outputs about .538v. I was using the IRFD9120 because its all I had laying around (it is actually a poor choice for this circuit because its expensive!). The IRFD9120 has a Vgs(th) from -2v to -4v. It does not seem to be full “on” until I hit about 2.8v. My source to the mosfet is 3.3v coming out of the pi itself so to hit its threshold I need 3.3-2.8=.5v on the gate or less before it opens. The voltage divider is Ra=120k Rb=10k giving .0769 and .0769*7v = 0.538v giving the desired threshold.

Does it work ?

Yes it works pretty well. I’m using two CR123 rechargables and I get about 30 minutes before they start to drop. This circuit will let you know just as they start to drop off. From there you might still have another 5 minutes. I’m going to make the javascript in my control page turn all of the gpio off and disable the buttons when this gets triggered, along with logging the time. This way I will see how much time you have after you get notified.

Run Time Battery V ra rb vout LowOn State
1 8:17 7.97 120000 10000 0.613077 FALSE
1 8:18 7.76 120000 10000 0.596923 FALSE
1 8:22 7.4 120000 10000 0.569231 FALSE
1 8:26 7.3 120000 10000 0.561538 FALSE
1 8:27 7.27 120000 10000 0.559231 FALSE
1 8:29 7.22 120000 10000 0.555385 FALSE
1 8:32 7.18 120000 10000 0.552308 FALSE
1 8:37 6.83 120000 10000 0.525385 TRUE
End 20min
2 11:30 8.39 120000 10000 0.645385 FALSE Off
2 11:30 7.91 120000 10000 0.608462 FALSE Working
2 11:31 7.78 120000 10000 0.598462 FALSE Working
2 11:34 7.56 120000 10000 0.581538 FALSE Working
2 11:37 7.5 120000 10000 0.576923 FALSE Working
2 11:44 7.48 120000 10000 0.575385 FALSE Working
2 10:48 7.37 120000 10000 0.566923 FALSE Working
2 11:49 7.31 120000 10000 0.562308 FALSE Working
2 11:52 7.21 120000 10000 0.554615 FALSE Working
2 11:57 7.1 120000 10000 0.546154 TRUE Working
2 11:59 7 120000 10000 0.538462 TRUE Working
2 12:00 6.92 120000 10000 0.532308 TRUE Working
2 12:01 6.85 120000 10000 0.526923 TRUE Working
2 12:02 6.52 120000 10000 0.501538 TRUE Issues
2 12:04 5.35 120000 10000 0.411538 TRUE Broke
2 12:05 6.44 120000 10000 0.495385 TRUE Off
2 12:06 6.65 120000 10000 0.511538 TRUE Off
End 30min


The 3.3 volts I get are from the pi’s 3.3v output so when the pi eventually does loose power because the 7805 can no longer function the 3.3v disappears. This means the output of the circuit is unknown. But I dont think it really matters at that point because the feedback into the rPi is pointless if its not running. So be sure to do your house keeping first and then ignore its output later.

The P-Channel Mosfet is really not for this application and costs about $1 each. I should get a cheaper mosfet since I’m not driving anything through it. There are some on mouser that cost about 7c such as PMV160UP,215 there are also IC voltage detectors but none of them seem to work right at 7v, and if I need to put in a voltage divider anyway I could just use a mosfet.


Find Cheaper Mosfet, rebuild voltage divider for that mosfet.