eLinux.org - User contributions [en]

EBC Exercise 22 Cross-Compiling and Finding the Right Kernel - bitbake

2012-11-14T07:10:57Z

Lobdeljt: /* meta-angstrom */

[[Category:ECE497]]
[[Category: BeagleBoard]]
{{YoderHead}}

This class is about developing software for embedded Linux. So far we have been doing all of our development on the Beagle. This works well for small (and not so small) programs. However, we are now moving into kernel development and that's best done on a more powerful host computer. In [[EBC Exercise 08 Installing Development Tools]] you learned how to download and install the cross-compilers and the source for kernel and u-boot. Now we'll use those tools.

First we'll check everything by compiling the Hello World program, then we'll try the kernel and u-boot.

== Stop Here, the rest hasn't been updated ==

== Cross-compiling Hello World ==

This shows how to setup the paths to use the compiler loaded by bitbake.

Listing 2-4 on page 29 of the text is an embedded version of Hello World. If you've set up your git repository you will find it in '''helloWorld.c''' when you do a''' git pull'''. Compile and run it on your host to be sure it works.

host$ '''gcc helloWorld.c'''
host$ '''./a.out'''
Hello, World! Main is executing at 0x400524
This address (0x7fff8260bdf8) is in our stack frame
This address (0x601038) is in our bss section
This address (0x601020) is in our data section

Now that you know it's working, let's cross compile it. First set the paths to find the cross-compilers. Put the following in a file, call it ~/.oe/'''crossCompileEnvBitbake.sh'''. Make sure the path is correct for your system. This is for a 32-bit linux.

# add cross tools to your path
export ARM_TOOLCHAIN_PATH=~/BeagleBoard/oe/build/tmp-angstrom_v2012_05-eglibc/sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi
PATH=$PATH:$ARM_TOOLCHAIN_PATH/..
PATH=$ARM_TOOLCHAIN_PATH:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-angstrom-linux-gnueabi-

Here it is for 64-bit

# add cross tools to your path
export ARM_TOOLCHAIN_PATH=~/BeagleBoard/oe/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux/usr/bin/armv7a-angstrom-linux-gnueabi
PATH=$PATH:$ARM_TOOLCHAIN_PATH/..
PATH=$ARM_TOOLCHAIN_PATH:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-angstrom-linux-gnueabi-

Now ''source'' the file and compile again. (Note: you only have to source once per terminal session.)
host$ '''source ~/.oe/crossCompileEnvBitbake.sh'''
host$ '''${CROSS_COMPILE}gcc helloWorld.c'''
host$ '''file a.out'''
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped

The '''file''' command tells what's in the file. In this case we have an ARM executable. Success! Now copy to your Beagle and run

host$ '''scp a.out root@beagle:.'''
host$ '''ssh root@beagle ./a.out'''
Hello, World! Main is executing at 0x8374
This address (0xbeb32d4c) is in our stack frame
This address (0x10650) is in our bss section
This address (0x10648) is in our data section

The '''scp''' copies a.out to the beagle and the '''ssh''' runs the a.out on the beagle. Notice the address are very different from the host version.

{{YoderFoot}}

== Finding the Kernel and Installing It ==

After doing [[EBC Exercise 08 Installing Development Tools - bitbake]] you have a Beagle kernel on your host computer. Let's see if it works.

Once compiled the kernel is put in a file called '''uImage'''. You may have seen it in the FAT partition on your SD card. Let's find it on your host. One way to find it is

host$ '''cd ~/BeagleBoard/oe'''
host$ '''find . -name uImage'''
./build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-mainline-3.2.18-r121b/git/arch/arm/boot/uImage
./build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-mainline-3.2.18-r121b/sysroot-destdir/kernel/uImage
./build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-mainline-3.2.18-r121b/image/kernel/uImage
./build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/kernel/uImage

It looks like I've compile the 3.2.18 version of the kernel. What version is the beagle running?

beagle$ '''uname -a'''
Linux yoder-bone 3.2.25 #1 Fri Aug 10 10:33:12 CEST 2012 armv7l GNU/Linux

The bone is running 3.2.25. Here's how to get our sources to match those used to compile the 3.2.25 kernel.

beagle$ '''cat /etc/angstrom-build-info'''
Configured Openembedded layers:
meta-angstrom = angstrom-v2012.05-yocto1.2:a029f5f5d19f788e2ab17227f35350ff5b6ca125
meta-oe
toolchain-layer
meta-efl
meta-gpe
meta-gnome
meta-xfce
meta-initramfs
meta-multimedia = denzil:b4488f4c012a64604b28bd2b6e93de411c34466d
meta-opie = master:efa3892b20a4ef80274e56e5633ebd62c16f9731
meta-java = master:3386ea6c96096f107f43f282f654e5afa456109e
meta-browser = master:c47f59df2e723495679c751cbdf6a8c6adec4b6a
meta-mono = master:83f8233b0498aadb18bf7605c3ba6c71d9e13a3a
meta-kde = master:5b0882d951cfd71886d423c190faaa7c7f932333
meta-ti = angstrom-staging:5364d0795bb27c2deb5a4e2df7d2f01ffb394cca
meta-efikamx = master:2c09a3a780b23448e8a6ca964256ff7f5ccba65d
meta-nslu2 = master:3d9fc951b05b4df476374b6fc3085ebac7f293ee
meta-htc
meta-nokia
meta-openmoko
meta-palm = master:2b106be01228f64298d6cb338f93088806594344
meta-handheld = master:1f05a15aceb4c3a19fa070463b58125b5658b2a9
meta-raspberrypi = denzil:34eef2ea4f5f24630dbb73b386861430167b8431
meta-intel
meta-sugarbay
meta-crownbay
meta-emenlow
meta-fishriver
meta-fri2
meta-jasperforest
meta-n450 = master:f75f9b6f68473eb0efac802409608f8389be0030
meta = denzil:b052427a6678b1b696f8c64cf0fdc55e6af86c48

This file shows the various repositories that were used to compile the kernel (and the root file system) for the given SD image (the bone A6A image in my case). Yes, the kernel comes from several git repositories. How many?
host$ '''cd ~/BeagleBoard/oe'''
host$ '''find . -name .git'''
./.git
./build/tmp-angstrom_v2012_05-eglibc/buildhistory/.git
./build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/u-boot-2011.12-r8/git/.git
./build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-mainline-3.2.18-r121b/git/.git
./build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/mtd-utils-1.4.9-r1/git/.git
./sources/meta-xilinx/.git
./sources/meta-intel/.git
./sources/bitbake/.git
./sources/meta-efikamx/.git
./sources/meta-angstrom/.git
./sources/openembedded-core/.git
./sources/meta-handheld/.git
./sources/meta-kde/.git
./sources/meta-nslu2/.git
./sources/meta-openembedded/.git
./sources/meta-raspberrypi/.git
./sources/meta-mono/.git
./sources/meta-java/.git
./sources/meta-ti/.git
./sources/meta-ettus/.git
./sources/meta-openpandora/.git
./sources/meta-smartphone/.git
./sources/meta-opie/.git
./sources/meta-browser/.git

The first '''.git''' is the repository you cloned to do the initial bitbake. The next is the u-boot repository. The next one is the kernel's repository. We'll be using that repository so much you should set up a symbolic link to it so you can find it easily.

host$ '''ln -s ~/BeagleBoard/oe/build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-mainline-3.2.18-r121b/git/ ~/...'''

Notice several '''.git'''s are in the '''sources''' directory. Note they have many names in common with the contents of '''/etc/angstrom-build-info'''. These are the repositories where we need to checkout the commits that correspond to the tags above. Here's how, take the first repository with a tag and '''cd''' to it.

=== meta-angstrom ===

host$ '''cd sources/meta-angstrom/'''
/home/beagle/BeagleBoard/oe/sources/meta-angstrom
host$ '''git status'''
# On branch angstrom-v2012.05-yocto1.2
nothing to commit (working directory clean)
host$ '''git remote update'''
Fetching origin
remote: Counting objects: 132, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 105 (delta 53), reused 96 (delta 45)
Receiving objects: 100% (105/105), 16.95 KiB, done.
Resolving deltas: 100% (53/53), completed with 18 local objects.
From git://github.com/Angstrom-distribution/meta-angstrom
140671a..784d76b master -> origin/master

Now checkout the corresponding tag
host$ '''git checkout a029f5f5d19f788e2ab17227f35350ff5b6ca125'''
Note: checking out 'a029f5f5d19f788e2ab17227f35350ff5b6ca125'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at a029f5f... base-files bbappend: move /var/run handling to systemd proper
host$ '''git status'''
# Not currently on any branch.
nothing to commit (working directory clean)

Don't worry that your HEAD is detached. That just means you're not on a branch. However it is the commit that was used to create the kernel we want.

=== meta-opie ===

Now, repeat this for each of the hash tags in '''/etc/angstrom-build-info'''. I'll get you started, you finish it.

host$ '''cd ../meta-opie'''
/home/beagle/BeagleBoard/oe/sources/meta-opie
host$ '''git remote update'''
Fetching origin
host$ '''git checkout efa3892b20a4ef80274e56e5633ebd62c16f9731'''
HEAD is now at efa3892... opie-packagemanager: fix a couple more quoting issues

=== and so on... ===
Keep going until you get an error.

=== meta-ti ===
This repository pulls from more than one place so the checkout will fail. Here's what to do.
host$ '''cd ../meta-ti'''
host$ '''git remote update'''
host$ '''git checkout 5364d0795bb27c2deb5a4e2df7d2f01ffb394cca'''
fatal: reference is not a tree: 5364d0795bb27c2deb5a4e2df7d2f01ffb394cca

So what repository has the tag '''5364d0795bb27c2deb5a4e2df7d2f01ffb394cca'''? Try google. With a bit of googling, I was able to find https://github.com/Angstrom-distribution/meta-ti/commit/5364d0795bb27c2deb5a4e2df7d2f01ffb394cca. Add this to the remote repositories.
host$ '''git remote add test https://github.com/Angstrom-distribution/meta-ti'''
host$ '''git remote update'''
host$ '''git checkout 5364d0795bb27c2deb5a4e2df7d2f01ffb394cca'''

Now continue on with the rest of the repositories.

=== Once all the repositories are all up to date ===

Now it's time to bitbake again and the 3.2.25 kernel should appear.

host$ '''cd ~/BeagleBoard/oe'''
host$ '''source ~/.oe/environment-angstromv2012.05'''
host$ '''time bitbake virtual/kernel'''

== Finding the Kernel for the ETC 2012 image ==
We are looking for uImage, but we only want the 2.6.32 version. The last grep file the file in the '''boot''' directory. Several lines are printed, but the one I'm interested in is:
''./build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r110b+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/git''/arch/arm/boot/uImage

The first part of the path (in italics) is the path to the kernel. Check it out.

host$ '''cd build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r110b+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/git'''
host$ '''ls -F'''
arch/ drivers/ Kbuild modules.order samples/ usr/
block/ firmware/ kernel/ Module.symvers scripts/ virt/
COPYING fs/ lib/ net/ security/ vmlinux*
CREDITS include/ MAINTAINERS patches/ sound/ vmlinux.o
crypto/ init/ Makefile README System.map
Documentation/ ipc/ mm/ REPORTING-BUGS tools/

We'll be learning what's in many of these over the next couple of weeks. Remember this location. Let's find uImage.

host$ '''cd arch/arm/boot; ls -shF'''
total 13M
4.0K bootp/ 6.3M Image* 4.0K Makefile 3.0M zImage*
4.0K compressed/ 4.0K install.sh 3.0M uImage
host$ '''ls -l uImage'''
-rw-r--r-- 1 beagle beagle 3144300 2011-12-08 01:02 uImage

It should have the date that you did the bitbake. Let's see if it runs on the Beagle
host$ '''scp uImage root@beagle:.'''
host$ '''ssh root@beagle'''
beagle$ '''cd /boot; ls -F'''
total 18M
4.0K MLO@
372K Module.symvers-2.6.32
1.4M System.map-2.6.32
80K config-2.6.32
4.0K u-boot.bin@
0 uImage@
3.1M uImage-2.6.32
8.9M vmlinux-2.6.32
beagle$ '''ls -l uImage'''
lrwxrwxrwx 1 www-data www-data 13 May 12 2011 uImage -> uImage-2.6.32

So the uImage that is there is a symbolic link to '''uImage-2.6.32'''. Let's save the working uImage in a difference file and copy our new uImage in.

beagle$ '''mv uImage-2.6.32 uImage-2.6.32.orig'''
beagle$ '''mv ~/uImage uImage-2.6.32'''

And then reboot.
beagle$ '''shutdown -r now'''

After a couple of minutes your should be back and running again. Check and see if you are really running the new kernel.
beagle$ '''uname -a'''
Linux beagleboard 2.6.32 #3 PREEMPT Thu Dec 8 01:02:13 EST 2011 armv7l GNU/Linux

It worked! That's the date I compiled mine on.

=== Failed Kernel ===
Here's what I get when trying to run the 3.2.18 kernel on the A6A bone image.

<pre>
reading u-boot.img
reading u-boot.img

U-Boot 2011.09-00053-gb423c52 (Aug 10 2012 - 11:26:55)

I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
No daughter card present
NAND: HW ECC Hamming Code selected
No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net: cpsw
Hit any key to stop autoboot: 0
SD/MMC found on device 0
reading uEnv.txt

27 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Loading file "/boot/uImage" from mmc device 0:2 xxa2
4385656 bytes read
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Linux-3.2.18
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4385592 Bytes = 4.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
XIP Kernel Image ... OK
OK

Starting kernel ...
</pre>

== Installing a New U-boot ==

While we're at it, let's install a new U-boot. Note: The new U-boot runs for me, but doesn't boot the kernel, yet.

host$ '''cd ~/BeagleBoard/oe/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/'''
host$ '''ls -F'''
linux-3.0.9-r110a/
linux-omap-psp-2.6.32-r110b+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/
shadow-4.1.4.3-r5/
u-boot-2011.09-r4/

There's the U-boot directory.

host$ cd u-boot-2011.09-r4/git/; ls -F
api/ COPYING fs/ mkconfig* post/ tools/
arch/ CREDITS include/ mmc_spl/ README u-boot*
board/ disk/ lib/ nand_spl/ rules.mk '''u-boot.bin'''
boards.cfg doc/ MAINTAINERS net/ snapshot.commit u-boot.lds
common/ drivers/ MAKEALL* onenand_ipl/ spl/ u-boot.map
config.mk examples/ Makefile patches/ System.map u-boot.srec

The file we want is right on the top level.

host$ '''scp u-boot.bin root@beagle:.'''
host$ '''ssh -X root@beagle'''
beagle$ '''cd /media/mmcblk0p1/; ls -F'''
MLO* u-boot.bin.broken* uEnv.txt*
U-BOOT.BIN* UIMAGE* uEnv/

Be sure you are logged into the Beagle via the serial port, rather than using ssh. Otherwise you won't see the boot sequence that appears before the kernel is running.

Here we've changed to the FAT partition which is where u-boot lives. Back it up and install the new one.

beagle$ '''mv U-BOOT-BIN u-boot-bin.orig'''
beagle$ '''mv ~/.u-boot-bin .'''
beagle$ '''shutdown -r now'''

You should now see the new u-boot running if you are logged in via the serial port.

== Compile via make ==

When you use bitbake it sets up all the paths to use the correct cross compilers. You can also build the kernel or u-boot by using '''make''' if you set the paths like we did above.

If you haven't already, ''source'' the file and ''cd'' to the kernel directory and try a ''make''.

host$ '''source ~/.oe/crossCompileEnv.sh'''
host$ '''cd ~/BeagleBoard/oe/build/tmp-angstrom_2010_x-eglibc/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r110b+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/git'''
host$ '''make xconfig'''

([[EBC Exercise 13 Configuring the Kernel]] has details on configuring the kernel.)

To make the kernel run

host$ '''make uImage'''

Now, follow the instructions above to install your freshly compiled kernel.

== Getting the A6A Kernel ==

beagle$ '''cat /etc/angstrom-build-info'''
Configured Openembedded layers:
meta-angstrom = angstrom-v2012.05-yocto1.2:a029f5f5d19f788e2ab17227f35350ff5b6ca125
meta-oe
toolchain-layer
meta-efl
meta-gpe
meta-gnome
meta-xfce
meta-initramfs
meta-multimedia = denzil:b4488f4c012a64604b28bd2b6e93de411c34466d
meta-opie = master:efa3892b20a4ef80274e56e5633ebd62c16f9731
meta-java = master:3386ea6c96096f107f43f282f654e5afa456109e
meta-browser = master:c47f59df2e723495679c751cbdf6a8c6adec4b6a
meta-mono = master:83f8233b0498aadb18bf7605c3ba6c71d9e13a3a
meta-kde = master:5b0882d951cfd71886d423c190faaa7c7f932333
meta-ti = angstrom-staging:5364d0795bb27c2deb5a4e2df7d2f01ffb394cca
meta-efikamx = master:2c09a3a780b23448e8a6ca964256ff7f5ccba65d
meta-nslu2 = master:3d9fc951b05b4df476374b6fc3085ebac7f293ee
meta-htc
meta-nokia
meta-openmoko
meta-palm = master:2b106be01228f64298d6cb338f93088806594344
meta-handheld = master:1f05a15aceb4c3a19fa070463b58125b5658b2a9
meta-raspberrypi = denzil:34eef2ea4f5f24630dbb73b386861430167b8431
meta-intel
meta-sugarbay
meta-crownbay
meta-emenlow
meta-fishriver
meta-fri2
meta-jasperforest
meta-n450 = master:f75f9b6f68473eb0efac802409608f8389be0030
meta = denzil:b052427a6678b1b696f8c64cf0fdc55e6af86c48

host$ '''cd BeagleBoard/oe/sources/meta-ti'''
host$ '''git checkout master'''

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:58:59Z

Lobdeljt: /* Future Work */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following to get the xM's IP address. It is needed quite soon
<source lang="text">
xm$ ifconfig
</source>

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

The current code does not automatically direct the VLC plugin to play from the correct IP address; it relies instead on passing a hard-coded IP address to the client in the WebcamFeed.html file. Modify the following code in the file to use your xM's IP address:
<source lang="text">
<embed
type="application/x-vlc-plugin"
name="videoplayer"
autoplay="yes" loop="no" hidden="no"
width="320" height="240"
target="tcp://[YOUR_BEAGLE_IP]:8080" />
</source>

Once the installation is done, the program is ready. Run it using:
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation]. A picture of the test setup is shown below:

[[File:BbWebFeed_demo_setup.jpg|400px]]

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to accomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get GStreamer to stream a video or camera input onto port 8080 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an HTML document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was identified by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the VLC viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allowed for a simplified approach to running the needed utilities without having to port code into the Javascript language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the xM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the VLC plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the HTML file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

The server should automatically detect its external IP and then use it to direct the client's VLC plugin to the video stream.

The video should stream through UDP rather than TCP. UDP would have better performance, and data loss is not a major concern for low-resolution video.

Audio can be added to the video stream.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:50:17Z

Lobdeljt: /* User Instructions */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following to get the xM's IP address. It is needed quite soon
<source lang="text">
xm$ ifconfig
</source>

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

The current code does not automatically direct the VLC plugin to play from the correct IP address; it relies instead on passing a hard-coded IP address to the client in the WebcamFeed.html file. Modify the following code in the file to use your xM's IP address:
<source lang="text">
<embed
type="application/x-vlc-plugin"
name="videoplayer"
autoplay="yes" loop="no" hidden="no"
width="320" height="240"
target="tcp://[YOUR_BEAGLE_IP]:8080" />
</source>

Once the installation is done, the program is ready. Run it using:
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation]. A picture of the test setup is shown below:

[[File:BbWebFeed_demo_setup.jpg|400px]]

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to accomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get GStreamer to stream a video or camera input onto port 8080 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an HTML document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was identified by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the VLC viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allowed for a simplified approach to running the needed utilities without having to port code into the Javascript language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:44:58Z

Lobdeljt: /* Installation Instructions */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following to get the xM's IP address. It is needed quite soon
<source lang="text">
xm$ ifconfig
</source>

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation]. A picture of the test setup is shown below:

[[File:BbWebFeed_demo_setup.jpg|400px]]

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to accomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get GStreamer to stream a video or camera input onto port 8080 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an HTML document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was identified by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the VLC viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allowed for a simplified approach to running the needed utilities without having to port code into the Javascript language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:26:58Z

Lobdeljt: /* Highlights */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation]. A picture of the test setup is shown below:

[[File:BbWebFeed_demo_setup.jpg|400px]]

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to accomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get GStreamer to stream a video or camera input onto port 8080 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an HTML document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was identified by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the VLC viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allowed for a simplified approach to running the needed utilities without having to port code into the Javascript language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

File:BbWebFeed demo setup.jpg

2012-11-14T06:25:46Z

Lobdeljt: Setup for the video demo of the Beagle Board Web Video Feed project

Setup for the video demo of the Beagle Board Web Video Feed project

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:07:26Z

Lobdeljt: /* Work Breakdown */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to accomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get GStreamer to stream a video or camera input onto port 8080 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an HTML document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was identified by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the VLC viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allowed for a simplified approach to running the needed utilities without having to port code into the Javascript language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:02:50Z

Lobdeljt: /* Work Breakdown */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdell investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:02:30Z

Lobdeljt:

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdell]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:01:29Z

Lobdeljt: /* Work Breakdown */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdell used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T06:00:22Z

Lobdeljt: /* Theory of Operation */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
<source lang="text">
xm$ cd ./WebcamFeeds/
</source>

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are four buttons for convenience. These function identically as entering the number's 0 though 3 into the text box and clicking Set Cam for each number.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

This program implements node.js and GStreamer working together to accomplish the video output and control over which video device to be viewed.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used. We only access one webcam at any given time and so the only increasing overhead on the system is that which is associated with the individual USB webcam's.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

This video starts out very slow and illustrates some of the hardware related issues that were encountered. While the most effective implementation currently is the two camera version we wished to show that four camera feeds could be accessed on the xM.

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

[[File:BbWebcamFeed_Gstreamer_pipeline.png|400px|Web Cam Feed - GStreamer Pipeline]]

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

[[File:BbWebcamFeed_Block_Diagram.png|400px|Web Cam Feed Block Diagram]]

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. Occasionally the camera just won't turn on. We have found that signaling it again usually fixes the problem without much effort. After trying to figure out what was causing the problem we could not definitively pin down the root cause of the problem and we found no simple or effective solution for it but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

Adafruit: Rotary Encoder

2012-11-14T05:54:05Z

Lobdeljt: /* Bone Usage */

[[Category:ECE497]]
[[Category:Adafruit]]

<pre style="color:red">
Overview: 2
Wiring: 1
Code: 1
git/Compiles with make: 2
Demo: 2
Total: 8/10
Comments: How do I do the pull ups?
</pre>

[[File:Adafruit_Rotary_Encoder.jpg|thumb|Adafruit's Rotary Encoder]]

==Overview==

[http://adafru.it/377 Adafruit's Rotary Encoder] is a device that detects rotation. As it rotates, it sends pulses on two pins. By comparing the signals, the direction of rotation can be determined. There are 24 pulses per rotation. The device also acts as a pushbutton switch.

==Inputs and Outputs==

The device has five pins - three on one side and two on the other. The side with three pins is for the encoder and is ordered (from left to right) signal A, ground, and signal B. The side with two pins is for the pushbutton switch. The signal pins require the use of pullup resistors, and the switch should use either a pullup or pulldown resistor. More information can be found on the [http://adafru.it/377 product page] or on the [http://www.adafruit.com/datasheets/pec11.pdf datasheet].

==Bone Usage==

The pins on the device can be difficult to use with a bread board, so it may be useful to solder the device to a perfboard and add connectors. [[File:Adafruit_Rotary_Encoder_With_Connectors.jpg|thumb|Rotary encoder with connectors added]]

<blockquote style="color:red">How do you configure the pullups?</blockquote>.

The two signal pins and one of the pushbutton pins can be hooked up directly to any of the GPIO ports on the BeagleBone. The pins should then be configured as pullups for the signal pins and either pullup or pulldown for the switch pin. The remaining pins can be hooked up to GND and +3,3v. The example below uses GPIO1_6 for signal A, GPIO1_15 for signal B, and GPIO1_16 for the pushbutton switch. [[File:Adafruit_Rotary_Encoder_in_BeagleBone.jpg|thumb|Rotary encoder hooked up to the BeagleBone]]

To configure the pull-up resistor, write 0x0037 to the pin's OMAP mux file (in /sys/kernel/debug/omap_mux). For example, the code below writes 0x0037 into /sys/kernel/debug/omap_mux/gpmc_ad6 for the B signal pin. Writing a value of 0x0027 to the file will configure it to use a pull-down resistor.

The C code below demonstrates how to use the encoder with the BeagleBone.

<pre>
/*

Port Congiguration:
-Encoder A: GPIO1_6 - Header P8, pin 3 - GPIO 38
-Encoder B: GPIO1_15 - Header P8, pin 15 - GPIO 47
-Encoder GND: Header P8, pin 1

-Pushbutton Switch: GPIO1_16 - Header P9, pin 15 - GPIO 48
-Pusshbuton Switch V+: Header P9, pin 3

This program keeps track of an encoder. CW rotation will
increment the ticks, and CCW will decrement it. The current
number of ticks is printed when the button is pressed.

The files gpio.h and gpio.c consist of the GPIO methods copied
directly from:
https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-test.c

*/

#include "gpio.h"
#include <signal.h>
#include <poll.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>

#define OMAP_DIR "/sys/kernel/debug/omap_mux"

int running = 1;

// Quit when ^C is pressed
void signal_handler(int sig)
{
printf("\n");
running = 0;
}

int main(int argc, char* argv[])
{
// Polling variables
int rc;
struct pollfd fdset[3];
int nfds = 3;
int len;
char* buf[MAX_BUF];

// Keeps track of encoder ticks.
int ticks = 0;

// Variables used to store GPIO values
unsigned int enc_a_val;
unsigned int enc_b_val;
unsigned int sw_val;

// Handle Ctrl^C
signal(SIGINT, signal_handler);

// Configure the pins to use internal pull-down resistors
FILE *mux_ptr;
char pullup_str[10];
char pulldown_str[10];
strcpy(pullup_str, "0x0037");
strcpy(pulldown_str, "0x0027");

// Configure pull-up for the A signal
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad6", "rb+")) == NULL)
{
printf("Failed to open gpmc_ad6. Quitting.\n");
exit(1);
}
else
{
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Configure pull-up for the B signal
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad15", "rb+")) == NULL)
{
printf("Failed to open gpmc_ad15. Quitting.\n");
exit(1);
}
else
{
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Configure pull-down for the switch
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_a0", "rb+")) == NULL)
{
printf("Failed to open gpmc_a0. Quitting.\n");
exit(1);
}
else
{
fwrite(&pulldown_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Set up GPIO pins
unsigned int gpio_a = 38;
unsigned int gpio_b = 47;
unsigned int gpio_sw = 48;

int enc_a_fd;
int enc_b_fd;
int enc_sw_fd;

printf("Exporting a... %d\n", gpio_export(gpio_a));
printf("Exporting b... %d\n", gpio_export(gpio_b));
printf("Exporting sw... %d\n", gpio_export(gpio_sw));

printf("Setting a direction... %d\n", gpio_set_dir(gpio_a, 0));
printf("Setting b direction... %d\n", gpio_set_dir(gpio_b, 0));
printf("Setting sw direction... %d\n", gpio_set_dir(gpio_sw, 0));

// Interrupts
printf("setting edge a... %d\n", gpio_set_edge(gpio_a, "rising"));
printf("setting edge sw... %d\n", gpio_set_edge(gpio_sw, "rising"));

// Open the file for the encoder A signal
enc_a_fd = gpio_fd_open(gpio_a);
enc_sw_fd = gpio_fd_open(gpio_sw);

// Main loop
while (running == 1)
{
memset((void*)fdset, 0, sizeof(fdset));

fdset[0].fd = STDIN_FILENO;
fdset[0].events = POLLIN;

fdset[1].fd = enc_a_fd;
fdset[1].events = POLLPRI;

fdset[2].fd = enc_sw_fd;
fdset[2].events = POLLPRI;

rc = poll(fdset, nfds, -1);

if (rc < 0)
{
// printf("poll() failed.\n");
}

if (rc == 0)
{
// printf(".");
}

if (fdset[0].revents & POLLIN)
{
(void) read(fdset[0].fd, buf, 1);
}

// Encoder click
if (fdset[1].revents & POLLPRI)
{
lseek(fdset[1].fd, 0, SEEK_SET);
len = read(fdset[1].fd, buf, MAX_BUF);

enc_a_val = atoi((const char*) buf);
gpio_get_value(gpio_b, &enc_b_val);

if (enc_a_val == 1) // rising edge
{
if (enc_b_val == 0) ticks--;
else ticks++;
}

}

// Button press - print the current number of encoder ticks
if (fdset[2].revents & POLLPRI)
{
lseek(fdset[2].fd, 0, SEEK_SET);
len = read(fdset[2].fd, buf, MAX_BUF);

// Very simple debouncing
usleep(5000);
gpio_get_value(gpio_sw, &sw_val);
if (sw_val == 1)
{
printf("Ticks: %d\n", ticks);
}
}

}

gpio_fd_close(enc_a_fd);

return 0;
}

</pre>

The full code can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].

==Interfacing with node.js==

Interfacing it with node.js is relatively straight-forward. The code is shwon below, and can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].

rotary_encoder.js:
<pre>
// From Getting Started With node.js and socket.io
// http://codehenge.net/blog/2011/12/getting-started-with-node-js-and-socket-io-v0-7-part-2/
"use strict";

var http = require('http'),
url = require('url'),
fs = require('fs'),
exec = require('child_process').exec,
server,
connectCount = 0; // Number of connections to server

server = http.createServer(function (req, res) {
// server code
var path = url.parse(req.url).pathname;
console.log("path: " + path);
switch (path) {
case '/':
res.writeHead(200, {'Content-Type': 'text/html'});
res.write('<h1>John Lobdell - Mini Project 4</h1>Try<ul><li><a href="/rotary_encoder.html">Rotary Encoder</a></li></ul>');

res.end();
break;

default: // This is so all the files will be sent.
fs.readFile(__dirname + path, function (err, data) {
if (err) {return send404(res); }
// console.log("path2: " + path);
res.write(data, 'utf8');
res.end();
});
break;

}
});

var send404 = function (res) {
res.writeHead(404);
res.write('404');
res.end();
};

server.listen(8081);

// socket.io, I choose you
var io = require('socket.io').listen(server);
io.set('log level', 2);

// on a 'connection' event
io.sockets.on('connection', function (socket) {
var frameCount = 0; // Counts the frames from arecord
var lastFrame = 0; // Last frame sent to browser
console.log("Connection " + socket.id + " accepted.");
// console.log("socket: " + socket);

// now that we have our connected 'socket' object, we can
// define its event handlers

// Make sure gpio 38, 47, and 48 are available.
exec("echo 38 > /sys/class/gpio/export");
exec("echo 47 > /sys/class/gpio/export");
exec("echo 48 > /sys/class/gpio/export");

// Configure pullup/pulldown resistors
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad6"); // Pullup for encoder A
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad15"); // Pullup for encoder B
exec("echo 0x0027 > /sys/kernel/debug/omap_mux/gpmc_a0"); // Pulldown for the switch

// Handle disconnects
socket.on('disconnect', function () {
console.log("Connection " + socket.id + " terminated.");
connectCount--;
if(connectCount === 0) {
}
console.log("connectCount = " + connectCount);
});

// Periodically send data
var push_interval = 20;
function push_data() {
// Send encoder A status
var gpioPath = "/sys/class/gpio/gpio38/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_a', data);
});

// Send encoder B status
gpioPath = "/sys/class/gpio/gpio47/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_b', data);
});

// Send encoder switch status
gpioPath = "/sys/class/gpio/gpio48/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_sw', data);
});

setTimeout(push_data, push_interval);
}
push_data();

connectCount++;
console.log("connectCount = " + connectCount);
});

</pre>

rotary_encoder.html:
<pre>
<!doctype html>
<html>
<head>
<title>Rotary Encoder Demo</title>

<script src="/json.js"></script> 
<script src="/socket.io/socket.io.js"></script>

<link href="layout.css" rel="stylesheet" type="text/css">
<script src="jquery.js"></script>
<script src="jquery.flot.js"></script>
<script src="jquery.flot.navigate.js"></script>
</head>
<body>
<h1>Rotary Encoder Demo <a href="http://Rose-Hulman.edu" target="_blank">
<img src="RoseLogo96.png" width=200 style="float:right"></a></h1>
<button id="connect" onClick='connect()'/>Connect</button>
<button id="disconnect" onClick='disconnect()'>Disconnect</button>

<table>
<tr>
<td><div id="plotTop" style="width:550px;height:150px;"></div>
<center>samples</center></td>
</tr>
<tr>
<td><div id="plotBot" style="width:550px;height:150px;"></div>
<center>samples<center></td>
</tr>
</table>

<br />
<br />

<a href="http://beagleboard.org" target="_blank">
<img src="beagle-hd-logo.gif" width=200 align="right"></a>
<div><p id="status">Waiting for input</p></div>
<div><p id="ticks"></p></div>
<a href="http://www.ti.com/sitara" target="_blank">
<img src="hdr_ti_logo.gif" width=200 align="right"></a>
By <i>John Lobdell</i>
<br />

<script>

var socket;
var firstconnect = true,
fs = 8000,
Ts = 1/fs*1000,
samples = 100,
plotTop,
enc_a = [], ienc_a = 0,
enc_b = [], ienc_b = 0,
sw_data = [], isw_data = 0,
gpio_enc_a = 38,
gpio_enc_b = 47,
gpio_sw = 48;

enc_a[samples] = 0;
enc_b[samples] = 0;
sw_data[samples] = 0;

function connect() {
if(firstconnect) {
socket = io.connect(null);

socket.on('message', function(data)
{ status_update("Received: message");});
socket.on('connect', function()
{ status_update("Connected to Server"); });
socket.on('disconnect', function()
{ status_update("Disconnected from Server"); });
socket.on('reconnect', function()
{ status_update("Reconnected to Server"); });
socket.on('reconnecting', function( nextRetry )
{ status_update("Reconnecting in " + nextRetry/1000 + " s"); });
socket.on('reconnect_failed', function()
{ message("Reconnect Failed"); });

socket.on('enc_a', enca);
socket.on('enc_b', encb);
socket.on('enc_sw', encsw);
socket.on('set_ticks', setTicks);

firstconnect = false;

}
else {
socket.socket.reconnect();
}
}

function disconnect() {
socket.disconnect();
}

// When new data arrives, convert it and plot it.
function enca(data) {
// status_update("enc_a " + data);
data = atob(data);
enc_a[ienc_a] = [ienc_a, data];
ienc_a++;
if (ienc_a >= samples) {
ienc_a = 0;
enc_a = [];
}
plotTop.setData([ enc_a, enc_b ]);
plotTop.draw();
}

function encb(data) {
// status_update("enc_b " + data);
data = atob(data);
enc_b[ienc_b] = [ienc_b, data];
ienc_b++;
if (ienc_b >= samples) {
ienc_b = 0;
enc_b = [];
}
plotTop.setData([ enc_a, enc_b ]);
plotTop.draw();
}

function encsw(data) {
// status_update("encsw " + data);
data = atob(data);
sw_data[isw_data] = [isw_data, data];
isw_data++;
if (isw_data >= samples) {
isw_data = 0;
sw_data = [];
}
plotBot.setData([ sw_data ]);
plotBot.draw();
}

function status_update(txt){
document.getElementById('status').innerHTML = txt;
}

function setTicks(numTicks){
document.getElementById('ticks').innerHTML = "Ticks: " + numTicks;
}

connect();

$(function () {

function initPlotData() {
// zip the generated y values with the x values
var result = [];
for (var i = 0; i <= samples; i++)
result[i] = [i, 0];
return result;
}

// setup plot
var optionsTop = {
series: {
shadowSize: 0, // drawing is faster without shadows
points: { show: false},
lines: { show: true, lineWidth: 5},
},
yaxis: { min: 0, max: 2,
zoomRange: [10, 256], panRange: [-128, 128] },
xaxis: { show: true,
zoomRange: [10, 100], panRange: [0, 100] },
legend: { position: "sw" },
zoom: { interactive: true, amount: 1.1 },
pan: { interactive: true }
};
plotTop = $.plot($("#plotTop"),
[
{ data: initPlotData(),
label: "Encoder A" },
{ data: initPlotData(),
label: "Encoder B" }
],
optionsTop);

var optionsBot = {
series: {
shadowSize: 0, // drawing is faster without shadows
points: { show: false},
lines: { show: true, lineWidth: 5},
color: 2
},
yaxis: { min: 0, max: 2,
zoomRange: [10, 256], panRange: [-128, 128] },
xaxis: { show: true,
zoomRange: [10, 100], panRange: [0, 100] },
legend: { position: "sw" },
zoom: { interactive: true, amount: 1.1 },
pan: { interactive: true }
};
plotBot = $.plot($("#plotBot"),
[
{ data: initPlotData(),
label: "Encoder Switch"}
],
optionsBot);
});
</script>

</body>
</html>
</pre>

File:BbWebcamFeed Block Diagram.png

2012-11-14T05:41:28Z

Lobdeljt: A block diagram for the Beagle Bone Webcam Feed project

A block diagram for the Beagle Bone Webcam Feed project

ECE497 Project Remote Web Cam Viewer

2012-11-14T05:40:41Z

Lobdeljt: /* Theory of Operation */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
xm$ '''cd ./WebcamFeeds/'''

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are two buttons for convenience. These function identically as entering the number's 1 or 0 into the text box and clicking Set Cam.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

== Theory of Operation ==

The project uses [http://gstreamer.freedesktop.org/ GStreamer] to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

TODO add picture of GStreamer pipeline

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

TODO add picture of block diagram

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. We found no simple or effective solution for this problem but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T05:40:00Z

Lobdeljt: /* Theory of Operation */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the browser's VLC Plugin. We have tested this with 4 webcams on the xM board.

Operating with four webcams hooked to the board causes many failures of the system to stream back the video information. We determined that this was due to the physical cameras and the overhead of the devices by testing the system with only two we cams where the issues experienced regularly with the four camera setup greatly reduced in frequency.

Investigation of how to accomplish this task took up the bulk of our time and effort largely due to the infancy of HTML5 Related standards(sockets.io and MediaStream). In the end we decided to utilize the vlc plugin when the HTML5 proved unfeasible at its current level of development. Implementing the four cameras did seem to cause some device issues that caused the webpage to not sync with the incoming feed, but this appears to be hardware related only and not from the implementation (a further explanation is later on).

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
xm$ '''cd ./WebcamFeeds/'''

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are two buttons for convenience. These function identically as entering the number's 1 or 0 into the text box and clicking Set Cam.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

== Theory of Operation ==

The project uses GStreamer to capture video from a webcam, convert it to video/ogg format, and stream it through Transmission Control Protocol (TCP). A diagram of the GStreamer pipeline is shown below.

TODO add picture of GStreamer pipeline

The client system connects to a node.js server running on the xM. The server embeds the video stream into the web page and also contains controls for selecting a webcam for the stream.

When the server begins running the node.js script, it launches the GStreamer pipeline discussed above. When the client connects, they receive a web page containing controls for the video source and the embedded video that gets played using the [http://www.videolan.org/vlc/index.html VLC] web plugin.

When the client uses the controls to change the video source, the server kills the current GStreamer process and launches a new one using the new video source. It then makes the client's page refresh to make the embedded video player use the new stream.

A block diagram of the system is shown below.

TODO add picture of block diagram

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

Solving the interesting problem with the random stream failure. This issue arises when switching between streams. Occasionally the video receiver does not receive the stream even though the stream is playing across the network. From experimentation we found that as cameras were added the performance of the entire program greatly decreased. Since we only access one camera at a time the only explanation we could find was that the OS was devoting resources to the devices when they were connected thus creating a much greater overhead as cameras were added. When the cameras were disconnected the performance returned to their previous levels. With four cameras operating a noticeable increase in stream failures was observed. With only two cameras operating about 1/5 of attempts would be unsuccessful. With four cameras the failure rate was significantly higher (as much as 1/3 of attempts would fail). One possible explanation of this is the overhead causing a slow down in setup time for the video out thread compared to the load up time of the browser. While this is set up to go first if the system hanged due to lack of resources this could cause the video stream to start after the html file stopped looking for it. We found no simple or effective solution for this problem but would like to see it fixed.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

File:BbWebcamFeed Gstreamer pipeline.png

2012-11-14T05:06:43Z

Lobdeljt: GStreamer pipeline for the BeagleBone xM Webcam Feed project

GStreamer pipeline for the BeagleBone xM Webcam Feed project

ECE497 Project Remote Web Cam Viewer

2012-11-14T04:57:06Z

Lobdeljt: /* Installation Instructions */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

//Give two sentences telling what works.
Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the VLC Plugin.

Give two sentences telling what isn't working.
Currently we do not have the system switching between camera's via user inputs. We have not tested with multiple cameras.

End with a two sentence conclusion.
Investigation of how to accomplish this task took up the bulk of our time and effort due to the infancy of HTML5 Related standards(sockets.io and MediaStream). We decided to utilize the vlc plugin when solving the problem with HTML5 proved unfeasible at its current level of development.

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ mkdir WebcamFeed
xm$ git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed
xm$ cd WebcamFeed
</source>

Install Node.js
<source lang="text">
xm$ opkg update
xm$ opkg install nodejs
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ opkg update
xm$ opkg install gstreamer
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ ifconfig
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
xm$ '''cd ./WebcamFeeds/'''

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are two buttons for convenience. These function identically as entering the number's 1 or 0 into the text box and clicking Set Cam.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

== Theory of Operation ==

Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T04:56:41Z

Lobdeljt: /* User Instructions */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

//Give two sentences telling what works.
Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the VLC Plugin.

Give two sentences telling what isn't working.
Currently we do not have the system switching between camera's via user inputs. We have not tested with multiple cameras.

End with a two sentence conclusion.
Investigation of how to accomplish this task took up the bulk of our time and effort due to the infancy of HTML5 Related standards(sockets.io and MediaStream). We decided to utilize the vlc plugin when solving the problem with HTML5 proved unfeasible at its current level of development.

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ '''mkdir WebcamFeed'''
xm$ '''git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed'''
xm$ '''cd WebcamFeed'''
</source>

Install Node.js
<source lang="text">
xm$ '''opkg update'''
xm$ '''opkg install nodejs'''
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ '''opkg update'''
xm$ '''opkg install gstreamer'''
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ '''ifconfig'''
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
xm$ '''cd ./WebcamFeeds/'''

Once the instillation is done the program can be ran
<source lang="text">
xm$ node WebcamFeed.js
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are two buttons for convenience. These function identically as entering the number's 1 or 0 into the text box and clicking Set Cam.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

== Theory of Operation ==

Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

ECE497 Project Remote Web Cam Viewer

2012-11-14T04:56:11Z

Lobdeljt: /* Highlights */

[[Category:ECE497]]
{{YoderHead}}

Team members: [[user:Draneaw|Alexander W. Drane]], [[user:Lobdeljt|John Lobdel]]

== Grading Template ==
I'm using the following template to grade. Each slot is 10 points.
0 = Missing, 5=OK, 10=Wow!

<pre style="color:red">
00 Executive Summary
00 Installation Instructions
00 User Instructions
00 Highlights
00 Theory of Operation
00 Work Breakdown
00 Future Work
00 Conclusions
00 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score: 10/100
</pre>

<span style="color:red">(Inline Comment)</span>

== Executive Summary ==
The goal of this project is to create a simple webcam based security system that allows a user to remotely view the devices web cam by navigating to a webpage. Then using buttons the user can change what camera they are viewing.

//Give two sentences telling what works.
Currently we have the ability to select a camera and view the stream in a remote webpage. This view uses the VLC Plugin.

Give two sentences telling what isn't working.
Currently we do not have the system switching between camera's via user inputs. We have not tested with multiple cameras.

End with a two sentence conclusion.
Investigation of how to accomplish this task took up the bulk of our time and effort due to the infancy of HTML5 Related standards(sockets.io and MediaStream). We decided to utilize the vlc plugin when solving the problem with HTML5 proved unfeasible at its current level of development.

== Installation Instructions ==

Extra Hardware Required:
*Webcam 1+ (or Playstation Eye's) Max 4 without other supplementary hardware. Best performing build currently is 2 web cams on the board. 4 makes the XM Slow down too much.

*Connected to the internet.

First Download the git Repository, it is located here:[https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed]

<source lang="text">
xm$ '''mkdir WebcamFeed'''
xm$ '''git clone https://github.com/jtlobdell/bbWebcamFeed.git WebcamFeed'''
xm$ '''cd WebcamFeed'''
</source>

Install Node.js
<source lang="text">
xm$ '''opkg update'''
xm$ '''opkg install nodejs'''
</source>
Verify gstreamer is available and up to date
<source lang="text">
xm$ '''opkg update'''
xm$ '''opkg install gstreamer'''
</source>
One last thing must be done on the user computer. VLC Media Player Plugin must be available in your browser of choice. This can be done by downloading the software here: [[http://www.videolan.org/vlc/index.html]] and making sure during installation to install the browser plugin. Many modern browsers will guide you through this if you run into a page that requires a missing plugin.

Now for reference type the following you will need it quite soon
<source lang="text">
xm$ '''ifconfig'''
</source>
Take note of the IP Address as you will need to enter it in your user's web browser and to align to the video feed. (This is due to the address being in the client HTML file and not able to be easily informed of its source IP Address.)

== User Instructions ==
Move to the source directory
xm$ '''cd ./WebcamFeeds/'''

Once the instillation is done the program can be ran
<source lang="text">
xm$ '''node WebcamFeed.js'''
</source>
Now navigate on the user computer using a web browser to your computers IP Address. Once there click on the link to the video feed page. The program will start and video should play.

NOTE: When changing video feeds the XM will randomly not load and play the feed. This we believe is due to the physical limitations of the hardware. We tested this by attaching 4 webcams to the board and found that the failure rate went up drastically. When the extra 2 webcams were removed the failure rate returned to where it was before. Since the program only ever calls one feed at a time(it changes which device it targets) this has to be a memory or hardware related issue and not due to the software.

At the top of the screen is a text box which can be entered the desired video device. Each camera is added sequentially starting at 0. Below the Set Cam button are two buttons for convenience. These function identically as entering the number's 1 or 0 into the text box and clicking Set Cam.

== Highlights ==

A single video is captured from a web cam and streamed to a web page. The video capture device can be selected from the same page.

The software allows for as many video capture devices (webcams) as can be connected to the device. In the case of the Beagle Board xM, up to four cameras can be used.

[http://youtu.be/kPK35JGzazY Here is a YouTube video demo of the four camera operation].

== Theory of Operation ==

Give a high level overview of the structure of your software. Are you using GStreamer? Show a diagram of the pipeline. Are you running multiple tasks? Show what they do and how they interact.

== Work Breakdown ==

List the major tasks in your project and who did what.

Also list here what doesn't work yet and when you think it will be finished and who is finishing it.

*Research- Research took up the bulk of our time and effort on this project due to the obscure nature of video streaming on the web using HTML5 and related tools. Most sources online advise you to use a plugin or third party software and treat the idea of using Javascript of HTML5 for this task as a taboo subject.
**GStreamer Implementation- John Lobdel investigated using GStreamer to acomplish this project. This implementation in the end proved effective and the easiest to implement.
**HTML5/JavaScript Implementation - Alex Drane investigated using a pure HTML5 implementation in order to not require anything to be done by the user to view the video streams. From initial research this appeared to be something that could be done quite easily. After considerable research wading through the draft standards that have been developed I found very little sample code or examples that pertained to remote video viewing. The easiest implementation I found was using it to create a 1-to-1 chat application. This is not suitable for our needs.

*Program Creation- John Lobdel used his research to get gstreamer to stream a video or camera input onto port 8081 that could then be read by the VLC Media Player on a remote computer. The further integration of this into a program was done with the introduction of the VLC-plugin in an html document. The final program was jointly compiled by both John and Alex.

The program creation went quite fast after a working method was discovered by John. Then it was a matter of putting the pieces together. The program consists of a node.js client server using the example provided in the examples/node.js folder, which provides the HTML server and controls for which video to stream. We embedded the vlc viewer into the page and pointed it to the location where the video would be streamed by an external function call in the .js file. This allows for a simplified approach to running the needed utilities without having to port code into the java script language.

== Future Work ==

Adding video capture would add true security camera capabilities to this system. In addition adding motion detection into the video selection stream would be interesting. Though this might be too much for the XM's hardware.

Having a webpage that displayed all of the video feeds at once would also be an interesting feature but this could over tax the XM's hardware or internet connection.

Figuring out how to implement this project with only HTML5 and make it so that no plugin is required by the end user was Alex's original plan but the maturity of the knowledge base for HTML5 is not adequate to accomplish this task at this time. But in the future when many of the draft standards are finished this project could be implemented without the vlc-plugin.

== Conclusions ==

This project was quite surprising by how difficult it is to do using the new HTML5 standards. Through the research we learned that there were currently no simple implementations of what we wished to do with this project. We had originally assumed that something as common as video streaming would have a direct implementation in the new standard but in fact it is far more restricted then we expected. By splitting each of our focuses during the research stage we were able to research the use of the bleeding edge of development and the use of the common implementation and then whoever found an implementation that worked first would allow the project to progress. In addition our parallel research gave us greater insight into the potential ways of accomplishing this task then if we had both focused on the HTML5 implementation and did not allow the project to reach a dead end as it would have if we had both focused on the HTML5 method.

In the end we did settle on using the vlc-plugin to capture the outgoing stream that John setup using gstreamer. This worked exactly as we wished it to without all of the syntax fighting that took place when trying to port the HTML5 sample code into code we had the codex's for(i.e. websocket to socket.io syntax Note: websocket wanted a Microsoft related XML file which after searching for could not be found when we tried to just use websocket).

Many of the ideas listed in Future Work would be amazing addon's to the project that would greatly expand and enhance this projects implementation.

{{YoderFoot}}

User:Lobdeljt

2012-11-08T16:49:25Z

Lobdeljt:

[[Category:ECE497|ULo]]

EBC Exercise 25 Configuring U-boot

2012-11-05T17:28:25Z

Lobdeljt: /* Assignment */

[[Category:ECE497]]
[[Category:BeagleBoard]]
{{YoderHead}}

This follows the approach taken in [[EBC Exercise 13 Configuring the Kernel]]. We'll use '''bitbake''' to get the source files for U-boot and then we'll edit them.

== bitbake ==

When you did [[EBC Exercise 22 Cross-Compiling and Finding the Right Kernel]] u-boot was downloaded and compiled. If you used the default configure, the source code was removed once it was done. Check and see:

host$ '''cd ~/BeagleBoard/oe/build/tmp-angstrom_v2012_05-eglibc/work/beagleboard-angstrom-linux-gnueabi/'''
host$ '''ls'''

You should see a directory starting with <code>u-boot-</code>. The rest of the name tells what version you have. Change to that directory and see what's there:

host$ '''cd u-boot-*'''
host$ '''ls'''

If you see a '''git''' directory, you are in luck. If you see just a '''temp''' directory you need to go back to [[EBC Exercise 22 Cross-Compiling and Finding the Right Kernel]] and get it installed.

Once you have the '''git''' directory, ''cd'' to it and look around.

== Compiling U-boot ==

You can now compile U-boot.

host$ '''source ~/.oe/crossCompileEnv.sh'''
host$ '''make'''
host$ '''scp u-boot.bin root@beagle:.'''

On the beagle, first be sure the FAT partition is mounted
beagle$ '''cd /media/'''
beagle$ '''mkdir mmcblk0p1'''
beagle$ '''mount /dev/mmcblk0p1 mmcblk0p1/'''
beagle$ '''cd mmcblk0p1/'''
beagle$ '''ls -ls'''
total 354
2 drwxr-xr-x 4 root root 2048 May 16 15:29 Docs
2 drwxr-xr-x 5 root root 2048 May 16 15:29 Drivers
6 -rwxr-xr-x 1 root root 5829 Aug 14 10:10 LICENSE.txt
84 -rwxr-xr-x 1 root root 85058 Aug 14 08:19 MLO
14 -rwxr-xr-x 1 root root 13976 Aug 14 10:10 README.htm
2 -rwxr-xr-x 1 root root 27 Aug 14 10:23 Uenv.txt
2 -rwxr-xr-x 1 root root 178 Aug 14 10:10 autorun.inf
2 -rwxr-xr-x 1 root root 171 Aug 14 10:10 info.txt
238 -rwxr-xr-x 1 root root 241948 Aug 14 08:19 u-boot.img
2 -rwxr-xr-x 1 root root 33 Aug 14 10:23 uEnv.txt.orig

Make a backup of the original u-boot.
beagle$ '''cp u-boot.bin u-boot.bin.orig'''
beagle$ '''cp ~/u-boot.bin .'''
beagle$ shutdown -r now

You should now be running the new u-boot.

== <span style="color:green">Assignment</span> ==

# Modify u-boot to include your initials in the prompt. (Hint: Look for the '''omap3_beagle.h''' file for the xM or '''am335x_evm.h''' for the bone.)
# Learn what is done when the '''boot''' command in entered in u-boot.
# Find where the code for boot is defined in the u-boot source.

Hint:
u-boot# '''help boot'''
boot - boot default, i.e., run 'bootcmd'

Usage:
boot
u-boot# '''print bootcmd'''
bootcmd=if mmc rescan ${mmcdev}; then if userbutton; then setenv bootenv user.txt;fi;echo SD/MMC found on device ${mmcdev};if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run loaduimage; then run mmcboot;fi;fi;run nandboot;

{{YoderFoot}}

ECE497 Editing a Wiki

2012-11-05T06:13:08Z

Lobdeljt:

[[Category:ECE497]]
{{YoderHead}}

Here is a wiki you can practice editing. Before you can edit it you will have to create an login. Pick something that will make it easy for me to identify you as part of my class. Then just add your name and date on the end of the table.

You can get help here: [[Help:Contents]].

If you need help with syntax check out the [[Editing Quickstart Guide|eLinux guide]] or the [http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet Wikipedia Cheatsheet].

== Fall 2012 ==

{|
|-
| [[user:Yoder | Mark A. Yoder]]
| 18-July-2012
|-
| [[user:atniptw | Tom Atnip]]
| 20-July-2012
|-
| [[user:Xinyu1991 | Xinyu Cheng]]
| 31-August-2012
|-
| [[user:bssachin45 | B S Sachin]]
| 25-July-2012
|-
| [[user:ruff | Ruffin White]]
| 16-August-2012
|-
| [[user:Popenhjc | James Popenhagen]]
| 30-August-2012
|-
| [[user:mmoravec | Matthew Moravec]]
| 30-August-2012
|-
| [[user:ngop | Peter Ngo]]
| 30-August-2012
|-
| [[user:duganje | Josh Dugan]]
| 30-August-2012
|-
| [[user:hansenrl | Ross Hansen]]
| 30-August-2012
|-
| [[user:jungeml | Michael Junge]]
| 05-September-2012
|-
| [[User:shinnsm|Stephen Shinn]]
| 30-August-2012
|-
| [[User:draneaw|Alex Drane]]
| 30-August-2012
|-
| [[User:larmorgs|Greg Larmore]]
| 31-August-2012
|-
| [[User:jessebrannon|Jesse Brannon]]
| 31-August-2012
|-
| [[User:lix|Xia Li]]
| 31-August-2012
|-
| [[User:whiteer|Elias White]]
| 31-August-2012
|-
| [[User:Astroricks|Yue Zhang]]
| 31-August-2012
|-
| [[User:millerap|Andrew Miller]]
| 31-August-2012
|-
| [[user:Geislekj | Kevin Geisler]]
| 1-September-2012
|-
| [[user:chris.good | Christopher A Good]]
| 3-September-2012
|-
| [[user:Lobdeljt | John Lobdell]]
| 5-November-2012
|}

== Winter 2011-2012 ==

{|
|-
| [[user:Yoder | Mark A. Yoder]]
| 21-Nov-2011
|-
| [[user:Yuming | Yuming Cao]]
| 21-Nov-2011
|-
| [[user:Yuhasmj | Michael Yuhas]]
| 21-Nov-2011
|-
| [[user:Yifei | Yifei Li]]
| 22-Nov-2011
|-
| [[user:Ziyi Zhang | Ziyi Zhang]]
| 24-Nov-2011
|-
|[[user: mac | Jack Ma]]
| 28-Nov-2011
|-
| [[user:Zitnikdj | David Zitnik]]
| 25-Nov-2011
|-
| [[user:Harrisgw | Greg Harrison]]
| 26-Nov-2011
|-
| [[user:Yanj | Mona J Yan]]
| 27-Nov-2011
|-
| [[user:Gemini91 | Guanqun Wang]]
| 28-Nov-2011
|-
| [[user:vsn1985 | Narayanan VS]]
| 28-Nov-2011
|}

{{YoderFoot}}

EBC Exercise 26 Device Drivers

2012-11-05T05:47:06Z

Lobdeljt:

[[Category:ECE497]]
{{YoderHead}}

Chapter 8 of the text [http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839] gives a nice example of a minimal device driver. The purpose of this lab is to implement that driver.

== Minimal Device Driver Example ==

=== Compiling ===

Follow the 5 steps given in Section 8.1.4 on page 205. You can get a copy of Listing 8-1 here ([[ECE497_Listings_for_Embedded_Linux_Primer_Chapter_8]]). Once finished you will have a file called <code>hello1.c</code> in <code>.../drivers/char/examples</code> and have the kernel configure file and Makefile updated for the new driver. See Section 4.4 on page 89 for help with modifying the config files.

Note: There is a typo in Listing 8-2.

If you have created the '''crossCompileEnv.sh''' file and sourced it, all you have to do to make the modules is cd to the top of the kernel directory and then:

host$ '''source ~/.oe/crossCompileEnv.sh''' (Only need to run once per terminal session.)
host$ '''make modules''' (or make -j''X'' modules, where ''X'' = number of cores on host.)

Mine took a while the first time as it compiles all the modules. The second it only took 31 seconds.

If you want to install all the modules that are created.

host$ '''make INSTALL_MOD_PATH=~/BeagleBoard modules_install'''

This will create '''lib''' directory in '''~/BeagleBoard''' with everything that goes in '''/lib''' on the Beagle. Then

host$ '''rsync --progress -avhe ssh ~/BeagleBoard/lib root@beagle:/'''

Could take a while to transfer.

====Improvements to the Code in the Book====
The code in Listing 8-10 is incomplete. If you compile it as is and load the module, it will work, but if you then remove the module and try to reinsert it it will fail with an error like this:
<pre>
ERROR GOES HERE
</pre>
The reason for this is that the module is registered with the kernel on load with a command like this:
<pre>
register_chrdev(MAJOR_NUMBER, NAME, FILE_OPERATIONS*);
</pre>
But it is never unregistered when the module is unloaded. To properly unload the module, add this line of code to your module's exit function
<pre>
unregister_chrdev(MAJOR_NUMBER, NAME);
</pre>
This will properly unregister the module from the kernel and allow it to be inserted and removed from the kernel at will without restarting your system in between.
<br /><br />Listing 8-10 also uses the ioctl field in the file_operations struct. Newer kernels have removed this. If the code from the listing complains about ioctl being an unknown field, use unlocked_ioctl in its place:
<pre>
struct file_operations hello_fops = {
owner: THIS_MODULE,
read: hello_read,
write: hello_write,
unlocked_ioctl: hello_ioctl,
open: hello_open,
release: hello_release,
};
</pre>

=== Moving to Beagle ===

On the beagle edit <code>/lib/modules/2.6.32/modules.dep</code> and add

/lib/modules/2.6.32/kernel/drivers/char/examples/hello1.ko:

Then copy the file <code>…/drivers/char/examples/hello1.ko</code> on the host computer to <code>/lib/modules/2.6.32/kernel/drivers/char/examples/</code> on your Beagle. This can be done with a single command though you may have to mkdir the char/examples directory on the Beagle first.

host$ '''cd …/drivers/char/examples'''
host$ '''scp hello1.ko root@beagle:/lib/modules/2.6.32/kernel/drivers/char/examples'''

I suggest putting the <code>scp</code> command in the <code>Makefile</code> since you may use it several times while developing your code.

Now, on the Beagle, add the module to '''modules.dep'''

beagle$ '''cd /lib/modules/2.6.32'''
beagle$ '''gedit modules.dep'''

Add the path to your new module and save. You will also have to move the '''modules.dep.bin''', otherwise the beagle will read from it rather than the modules.dep.

beagle$ '''mv modules.dep.bin modules.dep.bin.orig'''

Now, modprobe the module and check the log file.

beagle$ '''modprobe hello1'''
beagle$ '''dmesg | tail -4'''

You should see your Init message. And then...

beagle$ '''modprobe -r hello1'''
beagle$ '''dmesg | tail -4'''

should show your Exit message.

== Module Parameters ==

Section 8.1.7 on page 211 of the text shows how to pass a parameter to a module. Modify your <code>hello1.c</code> to take a parameter as shown.

Modify it so you can pass two parameters.

== Module Utilities ==

Play with the mod utilities listed in section 8.2 on page 212.

== Driver Methods ==

Section 8.3 on page 217 gives a longer example of how to use the file interface with modules. Implement the example. Be sure to fix the ''unsigned int'' format error, and make sure your <code>exit</code> function unregisters the device (unlike the Listing). When compiling the <code>use-hello</code> command be sure you are using the cross compiler for the ARM rather than the x86 compiler. If you sourced the '''crossCompilerEnv.sh''' file this should work:

host$ '''${CROSS_COMPILE}gcc use-hello.c -o use-hello'''
host$ '''file use-hello'''

The <code>file</code> command will tell you if you got the right compiler. Modify your <code>Makefile</code> to make <code>use-hello</code>.

Some questions...
* The major device number 234 is part of a range of unassigned numbers. What is the range?
* What's the new line added to <code>hello_init</code> do?
* What does <code>mknod</code> do?
* Once your device is running try <code>$ cat /proc/devices</code>. Do you see your device?

=== Optional Driver Work ===

Chapter 3 of ''Linux Device Drivers'' by Corbet, Rubini and Kroah-Hartman ([http://www.rose-hulman.edu/~yoder/Beagle/]) gives some more details on device drivers. Our text uses an older, static, method for major device number allocation. The book, referenced above, uses the newer dynamic allocation.
* Convert the example in our text to use the newer method. It's only a couple of additional lines, but you will have to read the book to know how to do it.
* Modify the ''scull_load'' script (call it ''hello_load'') on page 47, of chapter 3, to load your module. Hint: the back quotes are missing in this line in the text:

major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices)`

* Test it with <code>use-hello.c</code> from page 222 of ''Embedded Linux Primer''.
* Write a ''hello_unload'' script that will rmmod the driver and remove the nodes in /dev
* Modify ''hello.c'' to pass the major device number in as a parameter during <code>insmod</code>.

Optional: Stretch time, I though these would be easy, but after reading up on them, they look rather involved.
* How can your driver find what the minor device number is?
* Modify the driver to return some characters when <code>/dev/hello1</code> is read.

== Reference ==

[http://www.cnx-software.com/2011/08/19/how-to-write-and-submit-a-linux-kernel-patch/ How to Write and Submit a Linux Kernel Patch]

{{YoderFoot}}

File:Adafruit Rotary Encoder in BeagleBone.jpg

2012-10-24T05:41:08Z

Lobdeljt: uploaded a new version of "File:Adafruit Rotary Encoder in BeagleBone.jpg"

The Adafruit Rotary Encoder hooked up to the BeagleBone.

Adafruit: Rotary Encoder

2012-10-24T05:40:23Z

Lobdeljt:

[[Category:ECE497]]
[[Category:Adafruit]]

<pre style="color:red">
Overview: 2
Wiring: 2
Code: 1
git/Compiles with make: 1
Demo: 0
Total: 7/10
Comments: Address the concerns in Red below.

Please move your functions definitions to a .c file.
</pre>

[[File:Adafruit_Rotary_Encoder.jpg|thumb|Adafruit's Rotary Encoder]]

==Overview==

[http://adafru.it/377 Adafruit's Rotary Encoder] is a device that detects rotation. As it rotates, it sends pulses on two pins. By comparing the signals, the direction of rotation can be determined. There are 24 pulses per rotation. The device also acts as a pushbutton switch.

==Inputs and Outputs==

<blockquote style="color:red">The datasheet shows common in the middle. Please check.</blockquote>

The device has five pins - three on one side and two on the other. The side with three pins is for the encoder and is ordered (from left to right) signal A, ground, and signal B. The side with two pins is for the pushbutton switch. The signal pins require the use of pullup resistors, and the switch should use either a pullup or pulldown resistor. More information can be found on the [http://adafru.it/377 product page] or on the [http://www.adafruit.com/datasheets/pec11.pdf datasheet].

==Bone Usage==

The pins on the device can be difficult to use with a bread board, so it may be useful to solder the devide to a perfboard and add connectors. [[File:Adafruit_Rotary_Encoder_With_Connectors.jpg|thumb|Rotary encoder with connectors added]]

<blockquote style="color:red">What about pullup resistors? The default is for gpio38 (1_6) to be pull up and gpio48 (1_16) to be pull down. Is this intended?</blockquote>.

The two signal pins and one of the pushbutton pins can be hooked up directly to any of the GPIO ports on the BeagleBone. The pins should then be configured as pullups for the signal pins and either pullup or pulldown for the switch pin. The remaining pins can be hooked up to GND and +3,3v. The example below uses GPIO1_6 for signal A, GPIO1_15 for signal B, and GPIO1_16 for the pushbutton switch. [[File:Adafruit_Rotary_Encoder_in_BeagleBone.jpg|thumb|Rotary encoder hooked up to the BeagleBone]]

The C code below demonstrates how to use the encoder with the BeagleBone.

<blockquote style="color:red">Generally functions aren't defined in .h files.</blockquote>

<pre>

/*

Port Congiguration:
-Encoder A: GPIO1_6 - Header P8, pin 3 - GPIO 38
-Encoder B: GPIO1_15 - Header P8, pin 15 - GPIO 47
-Encoder GND: Header P8, pin 1

-Pushbutton Switch: GPIO1_16 - Header P9, pin 15 - GPIO 48
-Pusshbuton Switch V+: Header P9, pin 3

This program keeps track of an encoder. CW rotation will
increment the ticks, and CCW will decrement it. The current
number of ticks is printed when the button is pressed.

The files gpio.h and gpio.c consist of the GPIO methods copied
directly from:
https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-test.c

*/

#include "gpio.h"
#include <signal.h>
#include <poll.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>

#define OMAP_DIR "/sys/kernel/debug/omap_mux"

int running = 1;

// Quit when ^C is pressed
void signal_handler(int sig)
{
printf("\n");
running = 0;
}

int main(int argc, char* argv[])
{
// Polling variables
int rc;
struct pollfd fdset[3];
int nfds = 3;
int len;
char* buf[MAX_BUF];

// Keeps track of encoder ticks.
int ticks = 0;

// Variables used to store GPIO values
unsigned int enc_a_val;
unsigned int enc_b_val;
unsigned int sw_val;

// Handle Ctrl^C
signal(SIGINT, signal_handler);

// Configure the pins to use internal pull-down resistors
FILE *mux_ptr;
char pullup_str[10];
char pulldown_str[10];
strcpy(pullup_str, "0x0037");
strcpy(pulldown_str, "0x0027");

// Configure pull-up for the A signal
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad6", "rb+")) == NULL)
{
printf("Failed to open gpmc_ad6. Quitting.\n");
exit(1);
}
else
{
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Configure pull-up for the B signal
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad15", "rb+")) == NULL)
{
printf("Failed to open gpmc_ad15. Quitting.\n");
exit(1);
}
else
{
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Configure pull-down for the switch
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_a0", "rb+")) == NULL)
{
printf("Failed to open gpmc_a0. Quitting.\n");
exit(1);
}
else
{
fwrite(&pulldown_str, sizeof(char), 6, mux_ptr);
fclose(mux_ptr);
}

// Set up GPIO pins
unsigned int gpio_a = 38;
unsigned int gpio_b = 47;
unsigned int gpio_sw = 48;

int enc_a_fd;
int enc_b_fd;
int enc_sw_fd;

printf("Exporting a... %d\n", gpio_export(gpio_a));
printf("Exporting b... %d\n", gpio_export(gpio_b));
printf("Exporting sw... %d\n", gpio_export(gpio_sw));

printf("Setting a direction... %d\n", gpio_set_dir(gpio_a, 0));
printf("Setting b direction... %d\n", gpio_set_dir(gpio_b, 0));
printf("Setting sw direction... %d\n", gpio_set_dir(gpio_sw, 0));

// Interrupts
printf("setting edge a... %d\n", gpio_set_edge(gpio_a, "rising"));
printf("setting edge sw... %d\n", gpio_set_edge(gpio_sw, "rising"));

// Open the file for the encoder A signal
enc_a_fd = gpio_fd_open(gpio_a);
enc_sw_fd = gpio_fd_open(gpio_sw);

// Main loop
while (running == 1)
{
memset((void*)fdset, 0, sizeof(fdset));

fdset[0].fd = STDIN_FILENO;
fdset[0].events = POLLIN;

fdset[1].fd = enc_a_fd;
fdset[1].events = POLLPRI;

fdset[2].fd = enc_sw_fd;
fdset[2].events = POLLPRI;

rc = poll(fdset, nfds, -1);

if (rc < 0)
{
// printf("poll() failed.\n");
}

if (rc == 0)
{
// printf(".");
}

if (fdset[0].revents & POLLIN)
{
(void) read(fdset[0].fd, buf, 1);
}

// Encoder click
if (fdset[1].revents & POLLPRI)
{
lseek(fdset[1].fd, 0, SEEK_SET);
len = read(fdset[1].fd, buf, MAX_BUF);

enc_a_val = atoi((const char*) buf);
gpio_get_value(gpio_b, &enc_b_val);

if (enc_a_val == 1) // rising edge
{
if (enc_b_val == 0) ticks--;
else ticks++;
}

}

// Button press - print the current number of encoder ticks
if (fdset[2].revents & POLLPRI)
{
lseek(fdset[2].fd, 0, SEEK_SET);
len = read(fdset[2].fd, buf, MAX_BUF);

// Very simple debouncing
usleep(5000);
gpio_get_value(gpio_sw, &sw_val);
if (sw_val == 1)
{
printf("Ticks: %d\n", ticks);
}
}

}

gpio_fd_close(enc_a_fd);

return 0;
}

</pre>

The full code can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].

==Interfacing with node.js==

Interfacing it with node.js is relatively straight-forward. The code is shwon below, and can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].

rotary_encoder.js:
<pre>
// From Getting Started With node.js and socket.io
// http://codehenge.net/blog/2011/12/getting-started-with-node-js-and-socket-io-v0-7-part-2/
"use strict";

var http = require('http'),
url = require('url'),
fs = require('fs'),
exec = require('child_process').exec,
server,
connectCount = 0; // Number of connections to server

server = http.createServer(function (req, res) {
// server code
var path = url.parse(req.url).pathname;
console.log("path: " + path);
switch (path) {
case '/':
res.writeHead(200, {'Content-Type': 'text/html'});
res.write('<h1>John Lobdell - Mini Project 4</h1>Try<ul><li><a href="/rotary_encoder.html">Rotary Encoder</a></li></ul>');

res.end();
break;

default: // This is so all the files will be sent.
fs.readFile(__dirname + path, function (err, data) {
if (err) {return send404(res); }
// console.log("path2: " + path);
res.write(data, 'utf8');
res.end();
});
break;

}
});

var send404 = function (res) {
res.writeHead(404);
res.write('404');
res.end();
};

server.listen(8081);

// socket.io, I choose you
var io = require('socket.io').listen(server);
io.set('log level', 2);

// on a 'connection' event
io.sockets.on('connection', function (socket) {
var frameCount = 0; // Counts the frames from arecord
var lastFrame = 0; // Last frame sent to browser
console.log("Connection " + socket.id + " accepted.");
// console.log("socket: " + socket);

// now that we have our connected 'socket' object, we can
// define its event handlers

// Make sure gpio 38, 47, and 48 are available.
exec("echo 38 > /sys/class/gpio/export");
exec("echo 47 > /sys/class/gpio/export");
exec("echo 48 > /sys/class/gpio/export");

// Configure pullup/pulldown resistors
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad6"); // Pullup for encoder A
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad15"); // Pullup for encoder B
exec("echo 0x0027 > /sys/kernel/debug/omap_mux/gpmc_a0"); // Pulldown for the switch

// Handle disconnects
socket.on('disconnect', function () {
console.log("Connection " + socket.id + " terminated.");
connectCount--;
if(connectCount === 0) {
}
console.log("connectCount = " + connectCount);
});

// Periodically send data
var push_interval = 20;
function push_data() {
// Send encoder A status
var gpioPath = "/sys/class/gpio/gpio38/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_a', data);
});

// Send encoder B status
gpioPath = "/sys/class/gpio/gpio47/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_b', data);
});

// Send encoder switch status
gpioPath = "/sys/class/gpio/gpio48/value";
fs.readFile(gpioPath, 'base64', function (err, data) {
if (err) throw err;
socket.emit('enc_sw', data);
});

setTimeout(push_data, push_interval);
}
push_data();

connectCount++;
console.log("connectCount = " + connectCount);
});

</pre>

rotary_encoder.html:
<pre>
<!doctype html>
<html>
<head>
<title>Rotary Encoder Demo</title>

<script src="/json.js"></script> 
<script src="/socket.io/socket.io.js"></script>

<link href="layout.css" rel="stylesheet" type="text/css">
<script src="jquery.js"></script>
<script src="jquery.flot.js"></script>
<script src="jquery.flot.navigate.js"></script>
</head>
<body>
<h1>Rotary Encoder Demo <a href="http://Rose-Hulman.edu" target="_blank">
<img src="RoseLogo96.png" width=200 style="float:right"></a></h1>
<button id="connect" onClick='connect()'/>Connect</button>
<button id="disconnect" onClick='disconnect()'>Disconnect</button>

<table>
<tr>
<td><div id="plotTop" style="width:550px;height:150px;"></div>
<center>samples</center></td>
</tr>
<tr>
<td><div id="plotBot" style="width:550px;height:150px;"></div>
<center>samples<center></td>
</tr>
</table>

<br />
<br />

<a href="http://beagleboard.org" target="_blank">
<img src="beagle-hd-logo.gif" width=200 align="right"></a>
<div><p id="status">Waiting for input</p></div>
<div><p id="ticks"></p></div>
<a href="http://www.ti.com/sitara" target="_blank">
<img src="hdr_ti_logo.gif" width=200 align="right"></a>
By <i>John Lobdell</i>
<br />

<script>

var socket;
var firstconnect = true,
fs = 8000,
Ts = 1/fs*1000,
samples = 100,
plotTop,
enc_a = [], ienc_a = 0,
enc_b = [], ienc_b = 0,
sw_data = [], isw_data = 0,
gpio_enc_a = 38,
gpio_enc_b = 47,
gpio_sw = 48;

enc_a[samples] = 0;
enc_b[samples] = 0;
sw_data[samples] = 0;

function connect() {
if(firstconnect) {
socket = io.connect(null);

socket.on('message', function(data)
{ status_update("Received: message");});
socket.on('connect', function()
{ status_update("Connected to Server"); });
socket.on('disconnect', function()
{ status_update("Disconnected from Server"); });
socket.on('reconnect', function()
{ status_update("Reconnected to Server"); });
socket.on('reconnecting', function( nextRetry )
{ status_update("Reconnecting in " + nextRetry/1000 + " s"); });
socket.on('reconnect_failed', function()
{ message("Reconnect Failed"); });

socket.on('enc_a', enca);
socket.on('enc_b', encb);
socket.on('enc_sw', encsw);
socket.on('set_ticks', setTicks);

firstconnect = false;

}
else {
socket.socket.reconnect();
}
}

function disconnect() {
socket.disconnect();
}

// When new data arrives, convert it and plot it.
function enca(data) {
// status_update("enc_a " + data);
data = atob(data);
enc_a[ienc_a] = [ienc_a, data];
ienc_a++;
if (ienc_a >= samples) {
ienc_a = 0;
enc_a = [];
}
plotTop.setData([ enc_a, enc_b ]);
plotTop.draw();
}

function encb(data) {
// status_update("enc_b " + data);
data = atob(data);
enc_b[ienc_b] = [ienc_b, data];
ienc_b++;
if (ienc_b >= samples) {
ienc_b = 0;
enc_b = [];
}
plotTop.setData([ enc_a, enc_b ]);
plotTop.draw();
}

function encsw(data) {
// status_update("encsw " + data);
data = atob(data);
sw_data[isw_data] = [isw_data, data];
isw_data++;
if (isw_data >= samples) {
isw_data = 0;
sw_data = [];
}
plotBot.setData([ sw_data ]);
plotBot.draw();
}

function status_update(txt){
document.getElementById('status').innerHTML = txt;
}

function setTicks(numTicks){
document.getElementById('ticks').innerHTML = "Ticks: " + numTicks;
}

connect();

$(function () {

function initPlotData() {
// zip the generated y values with the x values
var result = [];
for (var i = 0; i <= samples; i++)
result[i] = [i, 0];
return result;
}

// setup plot
var optionsTop = {
series: {
shadowSize: 0, // drawing is faster without shadows
points: { show: false},
lines: { show: true, lineWidth: 5},
},
yaxis: { min: 0, max: 2,
zoomRange: [10, 256], panRange: [-128, 128] },
xaxis: { show: true,
zoomRange: [10, 100], panRange: [0, 100] },
legend: { position: "sw" },
zoom: { interactive: true, amount: 1.1 },
pan: { interactive: true }
};
plotTop = $.plot($("#plotTop"),
[
{ data: initPlotData(),
label: "Encoder A" },
{ data: initPlotData(),
label: "Encoder B" }
],
optionsTop);

var optionsBot = {
series: {
shadowSize: 0, // drawing is faster without shadows
points: { show: false},
lines: { show: true, lineWidth: 5},
color: 2
},
yaxis: { min: 0, max: 2,
zoomRange: [10, 256], panRange: [-128, 128] },
xaxis: { show: true,
zoomRange: [10, 100], panRange: [0, 100] },
legend: { position: "sw" },
zoom: { interactive: true, amount: 1.1 },
pan: { interactive: true }
};
plotBot = $.plot($("#plotBot"),
[
{ data: initPlotData(),
label: "Encoder Switch"}
],
optionsBot);
});
</script>

</body>
</html>
</pre>

File:Adafruit Rotary Encoder With Connectors.jpg

2012-10-24T05:11:20Z

Lobdeljt: Adafruit's rotary encoder with connectors added

Adafruit's rotary encoder with connectors added

Adafruit: Rotary Encoder

2012-10-02T00:14:38Z

Lobdeljt: /* Bone Usage */

[[Category:ECE497]]
[[Category:Adafruit]]

[[File:Adafruit_Rotary_Encoder.jpg|thumb|Adafruit's Rotary Encoder]]

==Overview==

[http://adafru.it/377 Adafruit's Rotary Encoder] is a device that detects rotation. As it rotates, it sends pulses on two pins. By comparing the signals, the direction of rotation can be determined. There are 24 pulses per rotation. The device also acts as a pushbutton switch.

==Inputs and Outputs==

The device has five pins - three on one side and two on the other. The side with three pins is for the encoder and is ordered (from left to right) ground, signal A, and signal B. The side with two pins is for the pushbutton switch. More information can be found on the [http://adafru.it/377 product page] or on the [http://www.adafruit.com/datasheets/pec11.pdf datasheet].

==Bone Usage==

The pins on the device can be difficult to use with a bread board, so soldering wire leads may prove useful. [[File:Adafruit_Rotary_Encoder_with_Wires.jpg|thumb|Rotary encoder with soldered wire leads]]

The two signal pins and one of the pushbutton pins can be hooked up directly to any of the GPIO ports on the BeagleBone. The remaining pins can be hooked up to GND and +3,3v. The example below uses GPIO1_6 for signal A, GPIO1_15 for signal B, and GPIO1_16 for the pushbutton switch. [[File:Adafruit_Rotary_Encoder_in_BeagleBone.jpg|thumb|Rotary encoder hooked up to the BeagleBone]]

The C code below demonstrates how to use the encoder with the BeagleBone.

<pre>
/*

Port Congiguration:
-Encoder A: GPIO1_6 - Header P8, pin 3 - GPIO 38
-Encoder B: GPIO1_15 - Header P8, pin 15 - GPIO 47
-Pushbutton Switch: GPIO1_16 - Header P9, pin 15 - GPIO 48

This program keeps track of an encoder. CW rotation will
increment the ticks, and CCW will decrement it. The current
number of ticks is printed when the button is pressed.

The gpio.h header consists of the GPIO methods copied directly from:
https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-test.c

*/

#include <signal.h>
#include <poll.h>
#include "gpio.h"

int running = 1;

void signal_handler(int sig)
{
running = 0;
}

int main(int argc, char* argv[])
{
int rc;
struct pollfd fdset[3];
int nfds = 3;
int len;
char* buf[MAX_BUF];
int i;

int pos = 0;

unsigned int enc_a_val;
unsigned int enc_b_val;

// Handle Ctrl^C
signal(SIGINT, signal_handler);

// Set up GPIO pins
unsigned int gpio_a = 38;
unsigned int gpio_b = 47;
unsigned int gpio_sw = 48;

int enc_a_fd;
int enc_b_fd;
int enc_sw_fd;

gpio_export(gpio_a);
gpio_export(gpio_b);
gpio_export(gpio_sw);

gpio_set_dir(gpio_a, 0);
gpio_set_dir(gpio_b, 0);
gpio_set_dir(gpio_sw, 0);

// Interrupts
gpio_set_edge(gpio_a, "rising");
gpio_set_edge(gpio_sw, "rising");

// Open the file for the encoder A signal
enc_a_fd = gpio_fd_open(gpio_a);

// Main loop
while (running == 1)
{
memset((void*)fdset, 0, sizeof(fdset));

fdset[0].fd = STDIN_FILENO;
fdset[0].events = POLLIN;

fdset[1].fd = enc_a_fd;
fdset[1].events = POLLPRI;

fdset[2].fd = enc_sw_fd;
fdset[2].events = POLLPRI;

rc = poll(fdset, nfds, -1);

if (rc < 0)
{
// printf("poll() failed.\n");
}

if (rc == 0)
{
// printf(".");
}

if (fdset[0].revents & POLLIN)
{
(void) read(fdset[0].fd, buf, 1);
}

// Encoder click
if (fdset[1].revents & POLLPRI)
{
lseek(fdset[1].fd, 0, SEEK_SET);
len = read(fdset[1].fd, buf, MAX_BUF);

enc_a_val = atoi((const char*) buf);
gpio_get_value(gpio_b, &enc_b_val);

if (enc_a_val == 1) // rising edge
{
if (enc_b_val == 0) pos--;
else pos++;
}

}

// Button Press
if (fdset[2].revents & POLLPRI)
{
lseek(fdset[2].fd, 0, SEEK_SET);
len = read(fdset[2].fd, buf, MAX_BUF);

printf("Ticks: %d\n", pos);
}

}

gpio_fd_close(enc_a_fd);

return 0;
}

</pre>

The full code can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].

EBC Mini Project 02

2012-10-01T23:36:01Z

Lobdeljt:

[[Category:ECE497 |Mini02]]
{{YoderHead}}

Pick one of the senors from the [https://www.sparkfun.com/products/11016 SparkFun Sensor Kit] or from [http://adafruit.com Adafruit] and interface it to the Bone. Create a wiki page describing how to use the sensor.

Add your name next to the sensor/display you want to use and pick it up from me.

== Sparkfun ==

{|
! Name
! Sensor
! Description
|-
| Josh Dugan
| HMC5883L - Triple-Axis Magnetometer Breakout Board
| An accurate, simple-to-use digital magnetometer with an I2C interface.
|-
| Ross Hansen
| ADXL335 - Triple-Axis Accelerometer Breakout Board
| Senses acceleration along all three axes, with a range of up to ±3g. Fully analog interface. [[Sparkfun:_ADXL335,_three-axis_accelerometer]]
ITG-3200
|-
| Alex Drane
| ADXL345 - Accelerometer Breakout Board
|
|-
| Ruffin White
| Triple-Axis Gyro Breakout Board
| Senses angular velocity along three axes of rotation. Fully digital interface with a range of up to ±2000°/s. [[Sparkfun:_ITG-3200,Triple-Axis_Gyro]]
|-
| Kevin Geisler
| [[Large Piezo Vibration Sensor - With Mass]]
| A flexible film able to sense for vibration, touch, shock, etc. When the film moves back and forth an AC wave is created, with a voltage of up to ±90.
|-
| Mark A. Yoder
| Reed Switch
| Senses magnetic fields, makes for a great non-contact switch.
|-
| Mark A. Yoder
| 0.25" Magnet Square
| Plays nicely with the reed switch. Embed the magnet into stuffed animals or inside a box to create a hidden actuator to the reed switch.
|-
| Stephen Shinn
| [[Sparkfun: 0.5" Force Sensitive Resistor|0.5" Force Sensitive Resistor]]
| A force sensing resistor with a 0.5" diameter sensing area. Great for sensing pressure (i.e. if it's being squeezed).
|-
| Tom Atnip
| [[Sparkfun:_PIR_Motion_Sensor]]
| Easy-to-use motion detector with an analog interface. Power it with 5-12VDC, and you'll be alerted of any movement.
|-
|
| Ultrasonic Rangefinder - Maxbotix LV-EZ1
| Distance sensor with both analog and RS-232 interfaces, providing sonar range information from 6 to 254 inches.
|-
|
| HIH-4030 Humidity Sensor
| A high precision humidity sensor with an analog output.
|-
| Andrew Miller
| IR Receiver Breakout Board
| An analog interfaced IR receiver, sensitive to a wide range of IR waves. Great for 'listening' to TV remotes.
|-
| James Popenhagen
| [[Mini Photocell]]
| The photocell will vary its resistance based on how much light it's exposed to. Will vary from 1kΩ in the light to 10kΩ in the dark.
|-
| Peter Ngo
| Optical Detector/Phototransistor
| An all-in-one infrared emitter and detector. Ideal for sensing black-to-white transitions or can be used to detect nearby objects.
|-
| Jesse Brannon
| BMP085 Barometric Pressure Sensor
| Low power, high precision barometric pressure sensor with I2C output.
|-
| James Popenhagen
| [[Flex Sensor]]
| As the sensor is flexed, the resistance across the sensor increases. Useful for sensing motion or positioning
|-
| Chris Good
| SoftPot
| These are very thin variable potentiometers. By pressing on various positions along the strip, you vary the resistance
|}

== Adafruit ==

{|
! Name
! Device
! Description
|-
| Matthew Moravec & Yue Zhang
| [https://www.adafruit.com/products/512 Analog 2-axis Thumb Joystick]
| Analog 2-axis Thumb Joystick with Select Button + Breakout Board
|-
|
| [https://www.adafruit.com/products/377 Rotary Encoder]
| This rotary encoder is a high quality 24-pulse encoder, with detents and a nice feel. This encoder also has a push-button built into it so you can press onto the knob to close a separate switch. One side has a 3 pin connector (ground and two coding pins) and the other side has two pins for a normally-open switch.
|-
|
| [https://www.adafruit.com/products/333 Touch screen (Nintendo DSL digitizer)]
| This resistive touch screen can be used with a stylus or fingertip and is easy to use with a microcontroller.
600 ohms across X pins, 300 ohms across Y pins
4 wire resistive display, on a 0.5mm FPC connector
|-
|Xinyu Cheng
| [https://www.adafruit.com/products/871 Mini 8x8 LED Matrix w/I2C - Yellow]
|
|-
|Mike Junge
|[https://www.adafruit.com/products/959 Mini 8x8 LED Matrix w/I2C - Blue]
|
|-
|Xia Li
|[https://www.adafruit.com/products/870 Mini 8x8 LED Matrix w/I2C - Red]
|
|-
|Peter Ngo & Bryan Correll
|[[Bicolor LED Square Pixel Matrix]]
| The matrices use a driver chip that does all the heavy lifting for you: They have a built in clock so they multiplex the display. They use constant-current drivers for ultra-bright, consistent color, 1/16 step display dimming, all via a simple I2C interface.
|-
|
| [https://www.adafruit.com/products/812 Green 7-segment clock display]
| These displays are multiplexed, common-cathode. What that means it that you can use a 74HC595. Sorry, I didn't order the version with i2c.
|-
| Sean Richardson
| [https://www.adafruit.com/products/306 Digital Addressable RGB LED]
| These LED strips are fun and glowy. There are 32 RGB LEDs per meter, and you can control each LED individually! We have 5 meters worth!
|-
|
|-
|Greg Larmore
| [https://www.adafruit.com/products/555 16x24 Red LED Matrix Panel]
| These LED panels take care of all the work of making a big matrix display. Each panel has six 8x8 red matrix modules, for a 16x24 matrix. The panel has a HT1632C chip on the back with does all the multiplexing work for you and has a 3-pin SPI-like serial interface to talk to it and set LEDs on or off (you cannot set the LED to be individually dimmed, as in 'grayscale'). There's a few extras as well, such as being able to change the brightness of the entire display, or blink the entire display at 1 Hz. [[Adafruit: 16x24 Red LED Matrix Panel]]
|-
|
|-
|John Lobdell
| [https://www.adafruit.com/products/377 Rotary Encoder]
|These rotary encoders rotate all the way around continuously, and are divided up into 24 'segments'. Each segment has a click-y feeling to it, and each movement clockwise or counter-clockwise causes the two switches to open and close. There is no way to know what the current 'position' is - instead you would use a microcontroller to count how many 'clicks' left or right it has been turned. If you need to detect rotational 'position' a potentiometer would be a better choice. [[Adafruit: Rotary Encoder]]
|}

{{YoderFoot}}

Adafruit: Rotary Encoder

2012-10-01T23:33:03Z

Lobdeljt: /* Bone Usage */

Adafruit: Rotary Encoder

2012-10-01T23:31:59Z

Lobdeljt: Created page with "Category:ECE497 Category:Adafruit Adafruit's Rotary Encoder ==Overview== [http://adafru.it/377 Adafruit's Rotary Encoder] i..."

[[Category:ECE497]]
[[Category:Adafruit]]

[[File:Adafruit_Rotary_Encoder.jpg|thumb|Adafruit's Rotary Encoder]]

==Overview==

[http://adafru.it/377 Adafruit's Rotary Encoder] is a device that detects rotation. As it rotates, it sends pulses on two pins. By comparing the signals, the direction of rotation can be determined. There are 24 pulses per rotation. The device also acts as a pushbutton switch.

==Inputs and Outputs==

The device has five pins - three on one side and two on the other. The side with three pins is for the encoder and is ordered (from left to right) ground, signal A, and signal B. The side with two pins is for the pushbutton switch. More information can be found on the [http://adafru.it/377 product page] or on the [http://www.adafruit.com/datasheets/pec11.pdf datasheet].

==Bone Usage==

The pins on the device can be difficult to use with a bread board, so soldering wire leads may prove useful. [[File:Adafruit_Rotary_Encoder_with_Wires.jpg|thumb|Rotary encoder with soldered wire leads]]

The two signal pins and one of the pushbutton pins can be hooked up directly to any of the GPIO ports on the BeagleBone. The remaining pins can be hooked up to GND and +3,3v. The example below uses GPIO1_6 for signal A, GPIO1_15 for signal B, and GPIO1_16 for the pushbutton switch. [[File:Adafruit_Rotary_Encoder_in_BeagleBone.jpg|thumb|Rotary encoder hooked up to the BeagleBone]]

The C code below demonstrates how to use the encoder with the BeagleBone.

<pre>
/*

Port Congiguration:
-Encoder A: GPIO1_6 - Header P8, pin 3 - GPIO 38
-Encoder B: GPIO1_15 - Header P8, pin 15 - GPIO 47
-Pushbutton Switch: GPIO1_16 - Header P9, pin 15 - GPIO 48

This program keeps track of an encoder. CW rotation will
increment the ticks, and CCW will decrement it. The current
number of ticks is printed when the button is pressed.

The gpio.h header consists of the GPIO methods copied directly from:
https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-tst

*/

#include <signal.h>
#include <poll.h>
#include "gpio.h"

int running = 1;

void signal_handler(int sig)
{
running = 0;
}

int main(int argc, char* argv[])
{
int rc;
struct pollfd fdset[3];
int nfds = 3;
int len;
char* buf[MAX_BUF];
int i;

int pos = 0;

unsigned int enc_a_val;
unsigned int enc_b_val;

// Handle Ctrl^C
signal(SIGINT, signal_handler);

// Set up GPIO pins
unsigned int gpio_a = 38;
unsigned int gpio_b = 47;
unsigned int gpio_sw = 48;

int enc_a_fd;
int enc_b_fd;
int enc_sw_fd;

gpio_export(gpio_a);
gpio_export(gpio_b);
gpio_export(gpio_sw);

gpio_set_dir(gpio_a, 0);
gpio_set_dir(gpio_b, 0);
gpio_set_dir(gpio_sw, 0);

// Interrupts
gpio_set_edge(gpio_a, "rising");
gpio_set_edge(gpio_sw, "rising");

// Open the file for the encoder A signal
enc_a_fd = gpio_fd_open(gpio_a);

// Main loop
while (running == 1)
{
memset((void*)fdset, 0, sizeof(fdset));

fdset[0].fd = STDIN_FILENO;
fdset[0].events = POLLIN;

fdset[1].fd = enc_a_fd;
fdset[1].events = POLLPRI;

fdset[2].fd = enc_sw_fd;
fdset[2].events = POLLPRI;

rc = poll(fdset, nfds, -1);

if (rc < 0)
{
// printf("poll() failed.\n");
}

if (rc == 0)
{
// printf(".");
}

if (fdset[0].revents & POLLIN)
{
(void) read(fdset[0].fd, buf, 1);
}

// Encoder click
if (fdset[1].revents & POLLPRI)
{
lseek(fdset[1].fd, 0, SEEK_SET);
len = read(fdset[1].fd, buf, MAX_BUF);

enc_a_val = atoi((const char*) buf);
gpio_get_value(gpio_b, &enc_b_val);

if (enc_a_val == 1) // rising edge
{
if (enc_b_val == 0) pos--;
else pos++;
}

}

// Button Press
if (fdset[2].revents & POLLPRI)
{
lseek(fdset[2].fd, 0, SEEK_SET);
len = read(fdset[2].fd, buf, MAX_BUF);

printf("Ticks: %d\n", pos);
}

}

gpio_fd_close(enc_a_fd);

return 0;
}

</pre>

File:Adafruit Rotary Encoder in BeagleBone.jpg

2012-10-01T23:25:40Z

Lobdeljt: The Adafruit Rotary Encoder hooked up to the BeagleBone.

The Adafruit Rotary Encoder hooked up to the BeagleBone.

File:Adafruit Rotary Encoder with Wires.jpg

2012-10-01T22:51:02Z

Lobdeljt: uploaded a new version of "File:Adafruit Rotary Encoder with Wires.jpg"

Adafruit's Rotary Encoder with wire leads soldered on.

File:Adafruit Rotary Encoder with Wires.jpg

2012-10-01T22:50:17Z

Lobdeljt: Adafruit's Rotary Encoder with wire leads soldered on.

Adafruit's Rotary Encoder with wire leads soldered on.

File:Adafruit Rotary Encoder.jpg

2012-10-01T22:20:12Z

Lobdeljt: uploaded a new version of "File:Adafruit Rotary Encoder.jpg"

Adafruit Rotary Encoder

File:Adafruit Rotary Encoder.jpg

2012-10-01T22:18:34Z

Lobdeljt: Adafruit Rotary Encoder

Adafruit Rotary Encoder

EBC Mini Project 02

2012-09-22T23:16:53Z

Lobdeljt: /* Adafruit */

[[Category:ECE497 |Mini02]]
{{YoderHead}}

Pick one of the senors from the [https://www.sparkfun.com/products/11016 SparkFun Sensor Kit] or from [http://adafruit.com Adafruit] and interface it to the Bone. Create a wiki page describing how to use the sensor.

Add your name next to the sensor/display you want to use and pick it up from me.

== Sparkfun ==

{|
! Name
! Sensor
! Description
|-
| Josh Dugan
| HMC5883L - Triple-Axis Magnetometer Breakout Board
| An accurate, simple-to-use digital magnetometer with an I2C interface.
|-
| Ross Hansen
| ADXL335 - Triple-Axis Accelerometer Breakout Board
| Senses acceleration along all three axes, with a range of up to ±3g. Fully analog interface. [[Sparkfun:_ADXL335,_three-axis_accelerometer]]
ITG-3200
|-
| Ruffin White
| Triple-Axis Gyro Breakout Board
| Senses angular velocity along three axes of rotation. Fully digital interface with a range of up to ±2000°/s.
|-
| Kevin Geisler
| Large Piezo Vibration Sensor - With Mass
| A flexible film able to sense for vibration, touch, shock, etc. When the film moves back and forth an AC wave is created, with a voltage of up to ±90.
|-
| Mark A. Yoder
| Reed Switch
| Senses magnetic fields, makes for a great non-contact switch.
|-
| Mark A. Yoder
| 0.25" Magnet Square
| Plays nicely with the reed switch. Embed the magnet into stuffed animals or inside a box to create a hidden actuator to the reed switch.
|-
| Stephen Shinn
| 0.5" Force Sensitive Resistor
| A force sensing resistor with a 0.5" diameter sensing area. Great for sensing pressure (i.e. if it's being squeezed).
|-
| Tom Atnip
| PIR Motion Sensor
| Easy-to-use motion detector with an analog interface. Power it with 5-12VDC, and you'll be alerted of any movement.
|-
|
| Ultrasonic Rangefinder - Maxbotix LV-EZ1
| Distance sensor with both analog and RS-232 interfaces, providing sonar range information from 6 to 254 inches.
|-
|
| HIH-4030 Humidity Sensor
| A high precision humidity sensor with an analog output.
|-
| Andrew Miller
| IR Receiver Breakout Board
| An analog interfaced IR receiver, sensitive to a wide range of IR waves. Great for 'listening' to TV remotes.
|-
| James Popenhagen
| Mini Photocell
| The photocell will vary its resistance based on how much light it's exposed to. Will vary from 1kΩ in the light to 10kΩ in the dark.
|-
|
| Optical Detector/Phototransistor
| An all-in-one infrared emitter and detector. Ideal for sensing black-to-white transitions or can be used to detect nearby objects.
|-
| Jesse Brannon
| BMP085 Barometric Pressure Sensor
| Low power, high precision barometric pressure sensor with I2C output.
|-
| James Popenhagen
| Flex Sensor
| As the sensor is flexed, the resistance across the sensor increases. Useful for sensing motion or positioning
|-
| Chris Good
| SoftPot
| These are very thin variable potentiometers. By pressing on various positions along the strip, you vary the resistance
|}

== Adafruit ==

{|
! Name
! Device
! Description
|-
| Matthew Moravec
| [https://www.adafruit.com/products/512 Analog 2-axis Thumb Joystick]
| Analog 2-axis Thumb Joystick with Select Button + Breakout Board
|-
|
| [https://www.adafruit.com/products/377 Rotary Encoder]
| This rotary encoder is a high quality 24-pulse encoder, with detents and a nice feel. This encoder also has a push-button built into it so you can press onto the knob to close a separate switch. One side has a 3 pin connector (ground and two coding pins) and the other side has two pins for a normally-open switch.
|-
|
| [https://www.adafruit.com/products/333 Touch screen (Nintendo DSL digitizer)]
| This resistive touch screen can be used with a stylus or fingertip and is easy to use with a microcontroller.
600 ohms across X pins, 300 ohms across Y pins
4 wire resistive display, on a 0.5mm FPC connector
|-
|Xinyu Cheng
| [https://www.adafruit.com/products/871 Mini 8x8 LED Matrix w/I2C - Yellow]
|
|-
|Mike Junge & Peter Ngo
|[https://www.adafruit.com/products/959 Mini 8x8 LED Matrix w/I2C - Blue]
|
|-
|Yue Zhang & Xia Li
|[https://www.adafruit.com/products/870 Mini 8x8 LED Matrix w/I2C - Red]
|
|-
|Alex Drane
|[https://www.adafruit.com/products/902 Bicolor LED Square Pixel Matrix]
| The matrices use a driver chip that does all the heavy lifting for you: They have a built in clock so they multiplex the display. They use constant-current drivers for ultra-bright, consistent color, 1/16 step display dimming, all via a simple I2C interface.
|-
|
| [https://www.adafruit.com/products/812 Green 7-segment clock display]
| These displays are multiplexed, common-cathode. What that means it that you can use a 74HC595. Sorry, I didn't order the version with i2c.
|-
| Sean Richardson
| [https://www.adafruit.com/products/306 Digital Addressable RGB LED]
| These LED strips are fun and glowy. There are 32 RGB LEDs per meter, and you can control each LED individually! We have 5 meters worth!
|-
|
|-
|Greg Larmore
| [https://www.adafruit.com/products/555 16x24 Red LED Matrix Panel]
| These LED panels take care of all the work of making a big matrix display. Each panel has six 8x8 red matrix modules, for a 16x24 matrix. The panel has a HT1632C chip on the back with does all the multiplexing work for you and has a 3-pin SPI-like serial interface to talk to it and set LEDs on or off (you cannot set the LED to be individually dimmed, as in 'grayscale'). There's a few extras as well, such as being able to change the brightness of the entire display, or blink the entire display at 1 Hz.
|-
|
|-
|John Lobdell
| [https://www.adafruit.com/products/377 Rotary Encoder]
|These rotary encoders rotate all the way around continuously, and are divided up into 24 'segments'. Each segment has a click-y feeling to it, and each movement clockwise or counter-clockwise causes the two switches to open and close. There is no way to know what the current 'position' is - instead you would use a microcontroller to count how many 'clicks' left or right it has been turned. If you need to detect rotational 'position' a potentiometer would be a better choice.
|}

{{YoderFoot}}

EBC Mini Project 02

2012-09-22T23:14:38Z

Lobdeljt: /* Adafruit */

[[Category:ECE497 |Mini02]]
{{YoderHead}}

Pick one of the senors from the [https://www.sparkfun.com/products/11016 SparkFun Sensor Kit] or from [http://adafruit.com Adafruit] and interface it to the Bone. Create a wiki page describing how to use the sensor.

Add your name next to the sensor/display you want to use and pick it up from me.

== Sparkfun ==

{|
! Name
! Sensor
! Description
|-
| Josh Dugan
| HMC5883L - Triple-Axis Magnetometer Breakout Board
| An accurate, simple-to-use digital magnetometer with an I2C interface.
|-
| Ross Hansen
| ADXL335 - Triple-Axis Accelerometer Breakout Board
| Senses acceleration along all three axes, with a range of up to ±3g. Fully analog interface. [[Sparkfun:_ADXL335,_three-axis_accelerometer]]
ITG-3200
|-
| Ruffin White
| Triple-Axis Gyro Breakout Board
| Senses angular velocity along three axes of rotation. Fully digital interface with a range of up to ±2000°/s.
|-
| Kevin Geisler
| Large Piezo Vibration Sensor - With Mass
| A flexible film able to sense for vibration, touch, shock, etc. When the film moves back and forth an AC wave is created, with a voltage of up to ±90.
|-
| Mark A. Yoder
| Reed Switch
| Senses magnetic fields, makes for a great non-contact switch.
|-
| Mark A. Yoder
| 0.25" Magnet Square
| Plays nicely with the reed switch. Embed the magnet into stuffed animals or inside a box to create a hidden actuator to the reed switch.
|-
| Stephen Shinn
| 0.5" Force Sensitive Resistor
| A force sensing resistor with a 0.5" diameter sensing area. Great for sensing pressure (i.e. if it's being squeezed).
|-
| Tom Atnip
| PIR Motion Sensor
| Easy-to-use motion detector with an analog interface. Power it with 5-12VDC, and you'll be alerted of any movement.
|-
|
| Ultrasonic Rangefinder - Maxbotix LV-EZ1
| Distance sensor with both analog and RS-232 interfaces, providing sonar range information from 6 to 254 inches.
|-
|
| HIH-4030 Humidity Sensor
| A high precision humidity sensor with an analog output.
|-
| Andrew Miller
| IR Receiver Breakout Board
| An analog interfaced IR receiver, sensitive to a wide range of IR waves. Great for 'listening' to TV remotes.
|-
| James Popenhagen
| Mini Photocell
| The photocell will vary its resistance based on how much light it's exposed to. Will vary from 1kΩ in the light to 10kΩ in the dark.
|-
|
| Optical Detector/Phototransistor
| An all-in-one infrared emitter and detector. Ideal for sensing black-to-white transitions or can be used to detect nearby objects.
|-
| Jesse Brannon
| BMP085 Barometric Pressure Sensor
| Low power, high precision barometric pressure sensor with I2C output.
|-
| James Popenhagen
| Flex Sensor
| As the sensor is flexed, the resistance across the sensor increases. Useful for sensing motion or positioning
|-
| Chris Good
| SoftPot
| These are very thin variable potentiometers. By pressing on various positions along the strip, you vary the resistance
|}

== Adafruit ==

{|
! Name
! Device
! Description
|-
| Matthew Moravec
| [https://www.adafruit.com/products/512 Analog 2-axis Thumb Joystick]
| Analog 2-axis Thumb Joystick with Select Button + Breakout Board
|-
|
| [https://www.adafruit.com/products/377 Rotary Encoder]
| This rotary encoder is a high quality 24-pulse encoder, with detents and a nice feel. This encoder also has a push-button built into it so you can press onto the knob to close a separate switch. One side has a 3 pin connector (ground and two coding pins) and the other side has two pins for a normally-open switch.
|-
|
| [https://www.adafruit.com/products/333 Touch screen (Nintendo DSL digitizer)]
| This resistive touch screen can be used with a stylus or fingertip and is easy to use with a microcontroller.
600 ohms across X pins, 300 ohms across Y pins
4 wire resistive display, on a 0.5mm FPC connector
|-
|Xinyu Cheng
| [https://www.adafruit.com/products/871 Mini 8x8 LED Matrix w/I2C - Yellow]
|
|-
|Mike Junge & Peter Ngo
|[https://www.adafruit.com/products/959 Mini 8x8 LED Matrix w/I2C - Blue]
|
|-
|Yue Zhang & Xia Li
|[https://www.adafruit.com/products/870 Mini 8x8 LED Matrix w/I2C - Red]
|
|-
|Alex Drane
|[https://www.adafruit.com/products/902 Bicolor LED Square Pixel Matrix]
| The matrices use a driver chip that does all the heavy lifting for you: They have a built in clock so they multiplex the display. They use constant-current drivers for ultra-bright, consistent color, 1/16 step display dimming, all via a simple I2C interface.
|-
|
| [https://www.adafruit.com/products/812 Green 7-segment clock display]
| These displays are multiplexed, common-cathode. What that means it that you can use a 74HC595. Sorry, I didn't order the version with i2c.
|-
| Sean Richardson
| [https://www.adafruit.com/products/306 Digital Addressable RGB LED]
| These LED strips are fun and glowy. There are 32 RGB LEDs per meter, and you can control each LED individually! We have 5 meters worth!
|-
|
|-
|Greg Larmore
| [https://www.adafruit.com/products/555 16x24 Red LED Matrix Panel]
| These LED panels take care of all the work of making a big matrix display. Each panel has six 8x8 red matrix modules, for a 16x24 matrix. The panel has a HT1632C chip on the back with does all the multiplexing work for you and has a 3-pin SPI-like serial interface to talk to it and set LEDs on or off (you cannot set the LED to be individually dimmed, as in 'grayscale'). There's a few extras as well, such as being able to change the brightness of the entire display, or blink the entire display at 1 Hz.
|-
|
|-
|John Lobdell
| [https://www.adafruit.com/products/377 Rotary Encoder]
|
|-
}

{{YoderFoot}}

ECE497 Contributions and Project Status

2012-09-13T16:35:02Z

Lobdeljt:

[[Category:ECE497 |Contributions]]
{{YoderHead}}

== Fall 2012 ==

=== Project Status ===

Please edit this page and add your project to this list. Copy my [[ECE497 Project Template]] to your own eLinux page and include the title of your project in the name of the page.

Please make the list alphabetical by family name.

Take a look at what you and others have contributed.

{|
|-
! Name
! Contributions
! Project
! git repository
|-
| [[User:atniptw | Tom Atnip]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/atniptw/ atniptw]
|-
| [[User:larmorgs | Greg Larmore]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/larmorgs/ larmorgs]
|-
| [[User:jessebrannon | Jesse Brannon]]
|
| [[ECE497 Project Template | My Beagle Project]]
|
|-
| [[User:Xinyu1991 | Xinyu Cheng]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/xinyu1991]
|-
| [[User:correlbn | Bryan Correll]]
| [[Special:Contributions/correlbn|contrib]]
| [[ECE497 Correlbn Project | My Beagle Project]]
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]
|-
| [[User:draneaw | Alex Drane]]
|
| [[ECE497 draneaw Project | My Beagle Project]]
| [https://github.com/draneaw/My-Beagle-Project draneaw]
|-
| [[User:duganje | Josh Dugan]]
|
| [[ECE497 duganje Project | My Beagle Project]]
| [https://github.com/duganje/ duganje]
|-
| [[User:Geislekj | Kevin Geisler]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/geislekj/ geislekj]
|
|-
| [[User:chris.good | Christopher A Good]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/goodca/ goodca]
|
|-
| [[User:hansenrl | Ross Hansen]]
| [[Special:Contributions/hansenrl|contrib]]
| [[ECE497 hansenrl Project | My Beagle Project]]
| [https://github.com/hansenrl/ Hansenrl]
|
|-
| [[User:jungeml | Michael Junge]]
| [[Special:Contributions/jungeml|contrib]]
| [[ECE497 jungeml Project | My Beagle Project]]
| [https://github.com/jungeml/ Jungeml]
|-
|
|-
| [[User:Lix | Xia Li]]
| [[Special:Contributions/Lix|contrib]]
| [[ECE497 Lix Project | My Beagle Project]]
| [https://github.com/1984xiali/ xiali]
|-
| [[User:mmoravec | Matthew Moravec]]
|
| [[ECE497 mmoravec Project | My Beagle Project]]
|
|-
| [[User:ngop | Peter Ngo]]
|
| [[ECE497 ngop Project | My Beagle Project]]
| [https://github.com/ngop/ ngop]
|
|-
| [[User:shinnsm|Stephen Shinn]]
| [[Special:Contributions/shinnsm|contrib]]
| Project TBD
| [https://github.com/shinnsm shinnsm]
|-
| [[User:Yoder | Mark A. Yoder]]
| [[Special:Contributions/Yoder | contrib]]
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/MarkAYoder MarkAYoder]
|-
| [[User:Popenhjc | James Popenhagen]]
|
| [[ECE497 popenhjc Project | My Beagle Project]]
| [https://github.com/popenhjc/ popenhjc]
|-
| [[User:Whiteer | Elias White]]
|
| [[ECE497 whiteer Project | My Beagle Project]]
| [https://github.com/whiteer whiteer]
|-
| [[User:ruff | Ruffin White]]
|
| [[ECE497 Project Template | My Beagle Project]]
| [https://github.com/ruffsl/ ruffsl]
|
|-
| [[User:Richarsm | Sean Richardson]]
|
| [[ECE497 richarsm Project | My Beagle Project]]
| [https://github.com/seanrich Sean Richardson]
|-
| [[User:Millerap | Andrew Miller]]
|
| [[ECE 497 millerap Project | My Beagle Project]]
| [https://github.com/millerap millerap]
|-|
| [[User:Astroricks | Yue Zhang]]
|
| [[ECE497 Yue Zhang Project | My Beagle Project]]
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]
|-
| [[User:Lobdeljt | John Lobdell]]
|
| [[ECE 497 lobdeljt Project | My Beagle Project]]
| [https://github.com/jtlobdell jtlobdell]
|-
|
|}

== Winter 2011-2012 ==

=== Contributions ===

# [[Special:Contributions/Yuming | Yuming Cao]]
# [[Special:Contributions/Yifei | Yifei Li]]
# [[Special:Contributions/Harrisgw | Greg Harrison]]
# [[Special:Contributions/mac | Jack Ma]]
# [[Special:Contributions/Gemini91 | Guanqun Wang]]
# [[Special:Contributions/Yanj | Mona Yan]]
# [[Special:Contributions/Yoder | Mark A. Yoder]]
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]
# [[Special:Contributions/Zitnikdj | David Zitnik]]
# [[Special:Contributions/Zitnikdj | Alex Drane]]
# [[Special:Contributions/jessebrannon | Jesse Brannon]]
# [[Special:Contributions/larmorgs | Greg Larmore]]
# [[Special:Contributions/jungeml | Michael Junge]]
# [[Special:Contributions/millerap | Andrew Miller]]
# [[Special:Contributions/correlbn | Bryan Correll]]

=== Project Status ===

# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]

{{YoderFoot}}

EBC Exercise 13 Pulse Width Modulation

2012-09-13T06:04:58Z

Lobdeljt: /* Either Way */

[[Category:EmbeddedBeagleClass]]
[[Category:ECE497]]
{{YoderHead}}

In a previous exercise ([[EBC Exercise 11 gpio Polling and Interrupts]]) you saw how to use the gpio to produce a square wave out using a C program and sysfs. I was able to get a 1.5kHz square wave out; however we can do much better using some built in hardware on the Beagle.

In this exercise you will learn how to use the Beagle's pulse width modulation (pwm) hardware using the sysfs interface and also learn about pin multiplexing (pin mux) on the way.

== PWM on the Bone ==

The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:

beagle$ '''cd /sys/class/pwm'''
beagle$ '''ls -F'''
ecap.0@ ecap.2@ ehrpwm.0:1@ ehrpwm.1:1@ ehrpwm.2:1@
ecap.1@ ehrpwm.0:0@ ehrpwm.1:0@ ehrpwm.2:0@

The [http://processors.wiki.ti.com/index.php/AM335x_PWM_Driver's_Guide AM335x PWM Driver's Guide] details what eCAP and eHRPWM are and gives some examples. Before you can use the PWM's, you need to make sure the pin MUXes are set correctly. There are two ways to do this, the slick way (which may not work) and the sure way.

=== The Slick Way ===

On your Bone

beagle$ '''cd exercises'''
beagle$ '''git pull'''
beagle$ '''cd pinMux'''
beagle$ '''ln -s $PWD/pinMux.html /var/lib/cloud9/bone101'''
beagle$ '''ls -ls /var/lib/cloud9/bone101/pinMux.html'''
0 lrwxrwxrwx 1 root root 39 Sep 6 14:19 /var/lib/cloud9/bone101/pinMux.html -> /home/root/exercises/pinMux/pinMux.html
beagle$ '''cd /var/lib/cloud9'''
beagle$ '''git pull'''
beagle$ '''shutdown -r now'''

Yup, after updating /var/lib/cloud9 you have to reboot.

Now, check the settings by browsing to [http://beagle/pinMux.html http://''bone''/pinMux.html] (where ''bone'' is the IP address of your Bone.) to see how the pins are set. You'll see something like:

[[File:PimMux1.png]]

=== The Sure Way ===

beagle$ '''cd ~/exercises/pinMux'''
beagle$ '''./pinMux.sh'''

This just lists all the files in the mux directory and their contents.

=== Either Way ===

This just lists every find in the mux directory.

You can control the pin MUXing this way:

beagle$ '''cd /sys/kernel/debug/omap_mux'''
beagle$ '''ls'''
ain0 gpmc_ad2 lcd_data3 mii1_txd2
ain1 gpmc_ad3 lcd_data4 mii1_txd3
ain2 gpmc_ad4 lcd_data5 mii1_txen
ain3 gpmc_ad5 lcd_data6 mmc0_clk
ain4 gpmc_ad6 lcd_data7 mmc0_cmd
ain5 gpmc_ad7 lcd_data8 mmc0_dat0
ain6 gpmc_ad8 lcd_data9 mmc0_dat1
ain7 gpmc_ad9 lcd_hsync mmc0_dat2
...

There are some 126 pins that you can control what they output. How do you know which one to change? Let's use ehrpwm.1:0. This will show up at ehrpwm1A (the 0 maps to A). Try:

beagle$ grep ehrpwm *
gpmc_a0:signals: gpmc_a0 | gmii2_txen | rgmii2_tctl | rmii2_txen | gpmc_a16 | pr1_mii_mt1_clk | ehrpwm1_tripzone_input | gpio1_16
gpmc_a1:signals: gpmc_a1 | gmii2_rxdv | rgmii2_rctl | mmc2_dat0 | gpmc_a17 | pr1_mii1_txd3 | ehrpwm0_synco | gpio1_17
'''gpmc_a2''':signals: gpmc_a2 | gmii2_txd3 | rgmii2_td3 | mmc2_dat1 | gpmc_a18 | pr1_mii1_txd2 | '''ehrpwm1A''' | gpio1_18
gpmc_a3:signals: gpmc_a3 | gmii2_txd2 | rgmii2_td2 | mmc2_dat2 | gpmc_a19 | pr1_mii1_txd1 | ehrpwm1B | gpio1_19
...
This shows that '''ehrpwm1A''' shows up in the file '''gpmc_a2'''. Look in the file
beagle$ '''cat gpmc_a2'''
name: gpmc_a2.gpio1_18 (0x44e10848/0x848 = 0x0007), b NA, t NA
mode: OMAP_PIN_OUTPUT | '''OMAP_MUX_MODE7'''
signals: gpmc_a2 | gmii2_txd3 | rgmii2_td3 | mmc2_dat1 | gpmc_a18 | pr1_mii1_txd2 | ehrpwm1A | gpio1_18

This says the MUX is presently set on pin '''7'''. Counting starts on the left with 0. We want pin '''6'''. So:

beagle$ '''echo 6 > gpmc_a2'''
beagle$ '''cat gpmc_a2'''
name: gpmc_a2.ehrpwm1A (0x44e10848/0x848 = 0x0006), b NA, t NA
mode: OMAP_PIN_OUTPUT | '''OMAP_MUX_MODE6'''
signals: gpmc_a2 | gmii2_txd3 | rgmii2_td3 | mmc2_dat1 | gpmc_a18 | pr1_mii1_txd2 | '''ehrpwm1A''' | gpio1_18

Now it's mode 6, which is the PWM output. Refresh you pin MUX web page to see.

[[File:PinMux2.png]]

Notice header P9, pin 14 has changed! Now let's turn on the PWM.

beagle$ '''cd /sys/class/pwm/ehrpwm.1\:0'''
beagle$ '''echo 1 > run'''
beagle$ '''echo 10 > period_freq'''
beagle$ '''echo 25 > duty_percent'''

Note: If these command cause the SSH connection to close, you may have to get a newer version of Angstrom. Follow the instructions at [[EBC_Exercise_03_Installing_a_Beagle_OS]] and try it again.

Connect the LED from [[EBC_Exercise_10_Flashing_an_LED#Adding_your_own_LED_-_bone]] and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?

Stick a scope on the pin and see if the frequency and duty cycle are right. What's the highest frequency you can get? What's the lowest?

[https://groups.google.com/forum/#!searchin/beagleboard/bone$20pwm/beagleboard/alKf67dwMHI/t_tIQpJyM8wJ Good discussion]

=== Assignment ===

If your git repository is set up just:
beagle$ '''cd exercises'''
beagle$ '''git pull'''
beagle$ '''cd pwm'''
(Follow the instructions [[EBC_Exercise_01a_Getting_Exercise_Support_Materials | here]] if you aren't set up for git.)

# Attach an LED and verify that it's blinking correctly.
# Hook up a oscilloscope. Are the PWM outputs doing what you expected?
# What's the highest frequency you can generate? What's the lowest?
# Verify your understanding of pin MUXing by generating a PWM signal that appears on pin 45 of P8. Document how you did it.

== PWM on the xM ==
'''This section needs updating to use /sys/kernel/debug/omap_mux to get the pin MUXes.'''

The DM3730 has 11 general purpose timers, 4 of which (gpt8-gpt11) can be brought out of the chip and used for pulse width modulation ([http://www.ti.com/product/dm3730#technicaldocuments DM3730 TRM page 2689]). The problem is the DM3730 has more internal lines than hardware I/O pins. The solution is that I/O pins run though a MUX that selects which internal lines appear on I/O pins. A given pin can have one from as many as eight lines assigned to it.

These MUXes are set at boot time, and must be set when the kernel boots, or in u-boot. I couldn't set them during kernel boot with the 2.6.32 kernel, so I used u-boot. [[BeagleBoardPinMux]] is a good place to learn about the pin MUXing. The u-boot details are [[BeagleBoardPinMux#Setting_Mux_Through_u-boot | here]].

[[BeagleBoardPWM]] is a nice overview of how to do PWM on the Beagle. The version of the kernel and u-boot that I've given you should already be configured to access the PWM pins. If it isn't you'll have to recompile the Kernel and u-boot.

The standard way to interface with the outside world in Linux is through Kernel Drivers. Currently there are no standard PWM driver for the Beagle, though a couple have been proposed ([https://groups.google.com/d/topic/beagleboard/RI3qTxn68bY/discussion], [http://git.billgatliff.com/pwm.git/?p=pwm.git;a=commit;h=a49cbfff0fa09bff40d328f8985a0a7a7b951d6f] and [http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=137654cde98a2ffe548f47f02e7fde512bc2091c]). [[BeagleBoardPWM]] takes a more traditional MCU approach by accessing the memory mapped PWD registers directly using '''mmap''' in a C program. Although this approach works, it is really transitional until a standard can be established.

You could even do PWM from a shell command by using [http://esdw.wordpress.com/2010/03/25/a-useful-tool-devmem2/ devmem2] to write to the memory mapped registers from a command line.

[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=56&Itemid=63 Here's] another PWM lead.

=== Assignment ===

If your git repository is set up just:
beagle$ '''cd exercises'''
beagle$ '''git pull'''
beagle$ '''cd pwm'''
(Follow the instructions [[EBC_Exercise_01a_Getting_Exercise_Support_Materials | here]] if you aren't set up for git.)

# Look at the files to see what they are doing.
# Run '''make''', then '''pwm-demo'''.
# Hook up a oscilloscope. (See Table 22 of the [http://beagleboard.org/static/BBxMSRM_latest.pdf Beagle System Reference manual] to see where to probe.) Are the pwm outputs doing what you expected?
# What's the highest frequency you can generate? What's the lowest?
# Create a new C program, based on pwm-demo, that takes 3 parameters, the <pwm to use>, <frequency> and <duty cycle>.
# Create a shell file that will call your new program and set up the three pwm's that appear on the expansion header and program them to do something interesting.
# Write a shell file that will do the pin MUXing using '''devmem2'''.
# Rewrite '''pwm-demo''' as a shell file that uses '''devmem2'''.

== Resources ==

# [[BeagleBoardPWM]] from ECE597
# [[BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation]] Google SoC project
# [[BeagleBoardPinMux]], how to set the pin mux.
# [http://www.gigamegablog.com/ Buttons and PWM]
# [http://veter-project.blogspot.com/2011/09/real-time-enough-about-pwms-and-shaky.html Shaky PWMs]
# [https://groups.google.com/forum/#!searchin/beagleboard/bone$20pwm/beagleboard/alKf67dwMHI/t_tIQpJyM8wJ PWM on the bone]

{{YoderFoot}}

User:Lobdeljt

2012-09-10T15:55:29Z

Lobdeljt: Created page with "Category:ECE497"

[[Category:ECE497]]

ECE497 Signup

2012-04-30T22:07:35Z

Lobdeljt:

[[Category:ECE497]]

This page is for those who are interested in my ECE497 class. Please add your name to the list by copying the blank line at the end and adding your information. Please leave a blank line at the end.

Adding your name here doesn't put you in the class. I want to talk to you first before adding to the official class list.

{| style="color:green; background-color:#ffffcc;" cellpadding="10" cellspacing="0" border="1"
! Name
! Major
! Year
! Have you had an OS class? Which one(s)?
! Have you had an embedded class? Which one(s)?
! Linux experience

0 = What's Linux

5 = Used it in OS

10 = Written Drivers
! Open Source Experience
|-
| Mark A. Yoder
| ECE
| Faculty
| Yes
| Yes
| 9
| Much
|-
| Matt Fuson
| ECE
| Junior
| No
| Yes (ECE230,ECE333)
| 4
| Program Arduino in spare time.
|-
| Tom Atnip
| CS/SE
| Junior (Current)
| Yes (CSSE332)
| Yes (CSSE232)
| 7
| Open Source Project W/ Last Internship
|-
| Kevin Geisler
| CS
| Junior
| Yes (CSSE332)
| Yes (CSSE232)(ECE 332)
| 6
| Arduino Programming
|-
| Alex Drane
| CPE
| Junior(Current)
| Yes (CSSE332)
| Yes (ECE 331)
| 7
| Cross-compiled Angstrom for the Arm AT91SAM9G10-EK
|-
| Josh Dugan
| CPE
| Junior (Current)
| Yes (CSSE 332)
| Yes (ECE 331, ECE 530)
| 5
| No
|-
| Stephen Shinn
| CPE
| Junior (Current)
| Yes (CSSE 332)
| Yes (ECE 331)
| 6
| Usage/modification of open-source server software
|-
| Andrew Miller
| CPE
| Senior
| Yes (CSSE 332)
| Yes (ECE 331)
| 7
| No
|-
| James Popenhagen
| CPE
| Senior
| Yes (CSSE 332)
| Yes (ECE 331)
| 7
| No
|-
| John Lobdell
| CPE
| Senior
| Yes (CSSE 332)
| Yes (ECE 331)
| 7
| Programmed with SDL
|-
|
|
|
|
|
|
|
|}