eLinux.org - User contributions [en]

ECE597 Project 3D Chess

2010-05-21T03:36:09Z

SStark: Added details about our project's chess logic

This project will simulate a hand-held chess game, and the game will allow two player games using two BeagleBoards over a network connection. The graphics will use the beagle's PowerVR SGX for hardware accelerated graphics by using OpenGL. If time permits, a third portion of the project will be to optimize the boot time because a chess computer should start up quickly.

==Team Members==
Paul Morrison

Steven Stark

==Timeline==
Below is an estimated timetable of tasks to be completed. Some adjustments may be necessary.

{| border="1" cellspacing="0" cellpadding="5"
! Task
! Owner
! Priority
! Estimated Completion
! Status
! Description
|-
| 1. Working OpenGL Code
| Paul
| High
| Fri, 4/2/2010
| Completed Wed, 4/21/2010
| Create our own OpenGL code and get it running on our BeagleBoard.
|-
| 2. Port 3D Chess Graphics
| Paul
| High
| Mon, 5/10/2010
| Completed, Mon, 4/17/2010
| Port Paul's existing 3D chess graphics to the BeagleBoard. This task includes a significant amount of modification to the OpenGL code because OpenGL ES provides only a subset of the OpenGL API. This task does not include porting chess game play.
|-
| 3. Refactor Piece Movement Architecture
| Steven
| High
| Sat, 5/8/2010
| Completed Mon, 5/10/2010
| Evaluate and refactor piece movement architecture so that piece movements can be handled from the network just as easily as from the mouse.
|-
| 4. Two Player Game Through Networking
| Steven
| High
| Sat, 5/15/2010
| Not Implemented
| Allow two BeagleBoards to play a game of chess through a network connection. This functionality was dropped in order to focus on other areas of the project.
|-
| 5. Handle Mouse Interaction
| Paul
| High
| Wed, 5/19/2010
| Completed Mon, 5/10/2010
| An extension of task 2, this task will continue porting the existing 3D chess game, including the user's mouse interactions and graphical display of legal moves. At the completion of this task, each player will be able to click on a piece and make a move.
|-
| 6. Implement Game Rules
| Paul and Steven
| Medium
| End of Quarter, Time Permitting
| Mostly Complete, Mon, 5/17/2010. Castling and En passant unimplemented
| This task will finish porting the existing chess logic, including all game rules. Additional features will be added to the original code. At the completion of this task, each player will be able to make only legal moves. The game will determine and handle when the game ends.
|-
| 7. Integration and Testing
| Steven
| Medium
| Wed, 5/19/2010
| Completed Mon, 5/17/2010
| Integration and testing will take place throughout the project, but this task represents final testing and bug fixes.
|-
| 8. Interface with Chess A/I Engine
| Steven
| Low
| Unlikely
| Unimplemented
| Building off task 3, chess movements should be able to come from an existing chess A/I engine. This task will involve hooking up an existing chess A/I engine to the game so that a player can play against the chess engine.
|-
| 9. Networking Server
| Steven
| Low
| Unlikely
| Unimplemented
| To facilitate multiplayer games, games will connect to a simple game server that we develop. Then players will not need to know the IP address of the other BeagleBoard to play a multiplayer game. Instead, players would find each other through our game server.
|-
| 10. Optimize Boot Process
| Paul
| Low
| Unlikely
| Unimplemented
| We want to minimize the startup time and boot directly into the chess game.
|}
About priorities: High Priority items need to be completed for a successful project. Medium Priority items should be completed for an effective project, but the project can still be successful without the item's completion. Low Priority items should be completed if time allows.

==Developing with OpenGL ES==
This section will explain how to set up and use the graphics SDK to compile using the cross compiler previously set up during ECE597. The 2010.3 Angstrom demo image was used to run the programs.

===Obtaining the Software===
The Graphics SDK is available from [http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html TI's website]. Download OMAP35x_Graphics_SDK_setuplinux_3_01_00_06.bin (you will need to create an account).

Make sure the file is executable
<pre>$ chmod +x OMAP35x_Graphics_SDK_setuplinux_3_01_00_06.bin</pre>
Extract the files to your desired location
<pre>./OMAP35x_Graphics_SDK_setuplinux_3_01_00_06.bin</pre>
Everything necessary for 3D Chess is contained in <your chosen directory>/GFX_Linux_SDK/OGLES2/SDKPackage/. This will simply be referred to as SDKPackage/ in the future.

===Compiling a Training Course Program===
The general instructions on compiling the programs are provided in SDKPackage/OpenGL ES 2.x SDK.User Guide.1.20f.External.pdf. The following instructions are specific to the cross compiler used with OpenEmbedded:

Create a new source-me.txt similar to what was done for the u-boot exercise. Note the addition of PLATFORM and X11ROOT variables. X11ROOT specifies the directory of the X11 freedesktop binaries which is necessary if you want the programs to run inside a window using X11.

<pre>
export OETREE="${HOME}/oe"
export ARCH=arm
export CROSS_COMPILE=arm-angstrom-linux-gnueabi-

export PLATFORM=LinuxOMAP3
export X11ROOT=${OETREE}/angstrom-dev/staging/armv7a-angstrom-linux-gnueabi/usr/lib/X11/

PATH=${OETREE}/angstrom-dev/staging/i686-linux/usr/bin/:${PATH}
PATH=${OETREE}/angstrom-dev/cross/armv7a/bin/:${PATH}
</pre>

Now to compile an interesting first program: 02_HelloTriangle. The source can be found in SDKPackage/TrainingCourse/02_HelloTriangle/OGLES2. There are two files, one for using X11 and one without. We need to set the flag, X11BUILD, to 1 if we want to build the X11 version.

<pre>
cd SDKPackage/TrainingCourse/02_HelloTriangle/OGLES2/Build/LinuxOMAP3
make X11BUILD=1
</pre>

It may be necessary to modify SDKPackage/Builds/OGLES2/LinuxOMAP3/make_platform.mak if the build fails. Modify the compiler lines to append the prefix arm-angstrom-linux-gnueabi-

<pre>
ifdef TOOLCHAIN
PLAT_CC = $(TOOLCHAIN)/bin/arm-angstrom-linux-gnueabi-gcc
PLAT_CPP = $(TOOLCHAIN)/bin/arm-angstrom-linux-gnueabi-g++
PLAT_AR = $(TOOLCHAIN)/bin/arm-angstrom-linux-gnueabi-ar
else
PLAT_CC = arm-angstrom-linux-gnueabi-gcc
PLAT_CPP = arm-angstrom-linux-gnueabi-g++
PLAT_AR = arm-angstrom-linux-gnueabi-ar
endif
</pre>

After the program is built, it will be in SDKPackage/TrainingCourse/02_HelloTriangle/OGLES2/Build/LinuxOMAP3/ReleaseRaw/OGLES2HelloTriangle.

To move this file to a running Beagleboard without setting up NFS, secure copy can be used:
<pre>$ scp ../LinuxOMAP3/ReleaseX11/OGLES2HelloTriangle user@beagleoard:/home/<user>/Documents/HelloTriangle/</pre>

Finally, on the Beagleboard, run the program:
<pre>
$ cd /home/<user>/Documents/HelloTriangle
$ ./OGLES2HelloTriangle
</pre>

All of the other training course programs and the demo programs should compile similarly.

===Understanding the Tools===
Originally, Paul had intended to use [http://www.libsdl.org/ Simple Direct Media Layer] for mouse input, texture loading and creation of an OpenGL context because it was used in the project to be ported. However, SDL 1.2 does not support OpenGL ES at all, SDL 1.3 is still in development, and the development version would not compile easily. It is also unknown how much additional work would be necessary to get SDL 1.3 to work well with OpenGL ES on the Beagleboard. Rather than sinking more days into trying, it was decided that the port would move to using PVRShell for the OpenGL ES context creation, and PVRTools for the texture loading.

====PVRShell====
This is a very basic class that is used to wrap the EGL and X11 calls that are necessary for creating a window with an OpenGL ES context. Training course programs 01 and 02 do not use PVRShell, so their source is a good place to see some code which would be necessary without PVRShell.

PVRShell is documented in SDKPackage/Shell/Documentation/html/index.html

====PVRTools (OGLES2Tools)====
This library contains many tools that are used to perform common graphics related tasks. Some of the tools that will be used directly by the 3D chess game include:

;PVRTMat4
:This class implements the necessary matrix operations for translation, rotation, perspective, and other transformations. Much of this functionality was available in OpenGL 1.0 and 2.0 and for the chess game will need to be ported from OpenGL calls to PVRTMat4.

;PVRTPrint3D
:This is used to draw text to the OpenGL window.

;PVRTTexture
:This is used to perform texture loading from the application's binary to an OpenGL ES texture.

;PVRTShader
:All OpenGL ES 2.0 programs must have shader programs to specify how the hardware will perform rendering. This tool will load the shader program.

All of the PVRTools are documented in SDKPackage/Tools/Documentation/html/index.html

====Makefiles====
If you look in a makefile for a training course program (try 06_IntroducingPVRTools) you will see that it includes another file, make_demo.mak, which then includes make_platform.mak. Additionally, make_demo.mak's build_textures_and_shaders uses two more makefiles: maketex.mak and content.mak. This initially confusing arrangement is allows one make command to compile all the necessary PVR libraries and to package application specific data into the binary which will be loaded at runtime.

content.mak is of particular interest because it specifies what textures, shaders, and 3D models should be wrapped inside the binary. This file is specific to each program and can be found in SDKPackage/TrainingCourse/06_IntroducingPVRTools/OGLES2/.

For example, in the 3D chess graphics port, a texture is used to make the board look like marble. In order to use this texture with PVRTTexture (one of the PVRTools used to load textures for use with OpenGL ES), the texture must be converted to a format usable by PVRTTexture and linked into the actual binary of the program. This can be accomplished by placing the texture (marble.bmp) into the Media folder and making a few modifications to content.mak and Makefile.

;Modifying content.mak:

<pre>
TEXTURES = \
Marble.pvr

BIN_SHADERS = \
FragShader.fsc \
VertShader.vsc

RESOURCES = \
$(CONTENTDIR)/Marble.cpp \
$(CONTENTDIR)/FragShader.cpp \
$(CONTENTDIR)/VertShader.cpp
</pre>

TEXTURES, BIN_SHADERS and RESOURCES indicate what files need to be created during the building process. Lines for the actual building are below:

<pre>
Marble.pvr: $(MEDIAPATH)/marble.bmp
$(PVRTEXTOOL) -m -fOGLPVRTC4 -i$(MEDIAPATH)/marble.bmp -o$@

$(CONTENTDIR)/Marble.cpp: Marble.pvr
$(FILEWRAP) -o $@ Marble.pvr
</pre>

What does all this do? A couple more tools are used to convert the bitmap texture into a usable form. These utilities are located in SDKPackage/Utilities/.

The Marble.pvr: command converts the bitmap texture to a compressed pvr form using the PVRTexTool utililty. The next command is then used to take the compressed data and wrap it .cpp file with the Filewrap utility. Finally, the .cpp files can be compiled and linked into the binary.

;Modifying Makefile:
Two changes need to be made to Makefile before we can use the marble texture in the program.

Add Marble.o to OBJECTS:
<pre>
OBJECTS += Marble.o FragShader.o VertShader.o
</pre>

Add Marble.cpp to build_textures_and_shaders:
<pre>
../../Content/Marble.cpp ../../Content/MarbleRookTexture.cpp ../../Content/FragShader.cpp ../../Content/VertShader.cpp: build_textures_and_shaders
</pre>

Now we can load the texture in our program with a call to PVRTTextureLoadFromPVR.

==Chess Logic==
The chess logic includes several features. One feature is that the board is represented by a 12 x 12 grid of pieces. A chess board only has 8 x 8 spaces, but including extra spaces around the outside eliminates edge cases. For example, consider the computation of a rook's possible moves. Four loops are used to determine what spaces in each of the four directions are legal. When a space is occupied by another piece the loop breaks, and a movement to that space is possible only if the space is occupied by the opponent's color, which allows for a piece to attack the opponent's piece. The spaces that are beyond the 8 x 8 grid are occupied by pieces that say the space is occupied, but is not on either team's side so a movement to those spaces is never legal. One may wonder why a 12 x 12 grid is necessary, since a 10 x 10 grid would work properly for computing the rook's possible moves. The reason for the extra pieces is because knight's can jump over pieces, so the outside must have two rows of dummy spaces.

The discussion above only determines the set of possible moves for a piece. However, not all moves that are generated by this process are legal because a player cannot leave the king in check or make a movement that causes the king to become in check. Thus, additional code is needed to examine each of the possible moves and ensure that the king is not in check at after making the possible move. This functionality automatically ends the game when a checkmate occurs because there no legal moves would remain.

==Chess Graphics==
All chess graphics were implemented using the OpenGL ES API. This API is well documented, and there are many tutorials available, so the details of how to use OpenGL will not be covered here.

===Piece Meshes===
The piece mesh class consists of a file parser to load the data, arrays to hold the data, and OpenGL code to perform the actual drawing. The meshes were created by Paul using the open 3D modeling tool [http://www.blender.org/ Blender] before this project began. They were exported to a simple format, [http://en.wikipedia.org/wiki/Obj Wavefront OBJ]. The file parser is capable of reading in the vertices, normals, texture coordinates, and the texture itself.

===Piece Selection===
Piece picking is performed by rendering each distinct object in a unique color when the mouse is clicked. The color of the pixel that was clicked on is then returned by a call to glReadPixels() and the specific object that was clicked on can then be determined from the unique color returned. The drawing is done directly to the framebuffer, but the buffers are not swapped before the scene is drawn again with proper colors. This prevents the user from seeing the unique colors for each piece. In the future, this could be accomplished using framebuffer objects and a modified shader program to render this picking texture offscreen at the same time the correctly colored image is rendered on screen. This should be able help performance after a mouse click slightly, but at the cost of more memory usage. However, the performance penalty is likely not significant.

==Annotated Bibliography==
# [http://groups.google.com/group/beagleboard/browse_thread/thread/7dba9497d735cbe9/df2e09c98c8b47a3?lnk=gst&q=new+image#df2e09c98c8b47a3 New beagleboard demo image available] This thread describes how to obtain the latest image for the Angstrom distribution on the beagleboard which includes the SGX 3D demos. 
# [http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html OMAP Graphics SDK] This is the download page for the OMAP35x graphics SDK required to build your own image. It also links to a wiki containing the getting started guide. 
# [http://www.khronos.org/opengles/ OpenGL ES Overview] This is the official website for OpenGL ES. Of particular use is the OpenGL ES quick reference card that has a list of all OpenGL ES function prototypes and some information of the GLSL shading language.

[[Category:ECE597]]

User:SStark

2010-04-15T03:42:12Z

SStark: Showing listing for making kernel module

I'm a senior at Rose-Hulman enrolled in ECE597 working on [[ECE597 Project 3D Chess]].

[[Category:ECE597]]

== Ch 8 Listings ==

=== Listing 8-4 ===
Making a kernel module after cleaning the .o and .ko files in drivers/char/examples:
<pre>
steven@steven-beagle:.../git$ make CROSS_COMPILE=arm-angstrom-linux-gnueabi- ARCH=arm modules
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
<stdin>:1097:2: warning: #warning syscall fadvise64 not implemented
<stdin>:1265:2: warning: #warning syscall migrate_pages not implemented
CC [M] drivers/char/examples/hello1.o
Building modules, stage 2.
MODPOST 691 modules
CC drivers/char/examples/hello1.mod.o
LD [M] drivers/char/examples/hello1.ko
</pre>

ECE597 Project 3D Chess

2010-03-24T03:36:03Z

SStark: Fixing minor typos

ECE597 Project 3D Chess

2010-03-24T02:56:00Z

SStark: Created page with 'This project will simulate a hand-held chess game, and the game will allow two player games using two BeagleBoards over a network connection. The graphics will use the beagle's P…'

ECE497 Project Ideas

2010-03-24T02:54:38Z

SStark: Link to 3D Chess project page

[[Category:ECE597]]
[[Category:BeagleBoard]]

== Sources for Project Ideas ==

Here are some links where you'll find ideas for your project.
* [http://wiki.omap.com/index.php/ETechDays_Community_Lightning_Talks ETechDays Community Lightning Talks], this is a one-day web-based conference where many project ideas are presented. One of our 2009-2010 senior design projects was found here.
* [http://beagleboard.org/project Official list of Beagle Projects], there are many Beagle specific projects listed here. Many are inactive. ''List your project here once it running.''
* [http://www.youtube.com/watch?v=Mk1xjbA-ISE Augmented Reality Project], here's an idea that I think we can do on the Beagle. Rather than using augmented reality glasses, I'd suggest we use a [http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2235 TI DLP pico projector]. [http://www.hitlabnz.org/wiki/EmbeddedAR Here's] AR running on the Beagle.
* [http://code.google.com/p/0xdroid/ Android], this is one of a couple of efforts to port [http://source.android.com/ Google's Android OS] to the Beagle.
* [[BeagleBoard/Ideas-2009]] Google summer code ideas 2009.

== Projects you would like to do ==
Edit this page to add projects you would like to do. If you aren't in the class, add ideas you would like to see done by class members.

{| border="1" cellspacing="0" cellpadding="5"
! Team Members
! Project Title
! Description
|-
| Mark A. Yoder
| [[ECE597 Google PowerMeter]]
| Google has a [http://www.google.com/powermeter project] to view and manage home electricity usage. This project would involve designing the hardware to measure the power usage and the Beagle software in interface with it. The Beagle would talk to the local home network via a wireless link and the home owner would configure the Beagle via a web page served on the Beagle.
|-
| Yannick Polius
| Audio MBox
| This project is mostly software, with the hardware element being the use of the dsp. The idea is to tie together three technologies: speech recognition, speech synthesis, and internet access in order to create an interface capable of orating information to the user based on a vocal command. The implementation I have in mind is to use the Pocket Sphinx speech recognition engine to first understand what the user wants through speech, such as "Rose-Hulman". Once the speech is translated, the software can execute a Wikipedia search to pull said item's page. Most of the important info is contained within the introductory paragraph, so the software will take only that chunk and feed it into the Flite speech synthesis engine. The end result is a simple machine with "mother box" like usability, that is, no interaction besides what is natural to the user (speaking) should be necessary to retrieve the information.
|-
| Paul Morrison Steven Stark
| [[ECE597 3D Chess | 3D Chess with Networking]]
| This project would simulate a hand-held chess game, and the game would allow two player games using two beagleboards over a network connection. The graphics would use the beagle's PowerVR SGX for hardware accelerated graphics by using OpenGL. In addition to 3D graphics and networking, a third portion of the project would be to optimize the boot time because a chess computer should start up quickly.
|-
| Tom Most David Baty Mark Jacobson
| [[ECE597: Sumo Robot|Sumo Robot]]
| The goal of this project is to create a robot capable of competing in the 3.0 kg weight class of a sumo competition ([http://www.youtube.com/watch?v=V3OR_sHrOJM an example]). This would have minor hardware and electronics elements, but would focus on communication with sensors using the BeagleBoard and the Linux kernel. At minimum, this involves sensors to detect the edge of the ring and the opposing robot. This would likely be implemented using Sharp IR rangefinders, a ultrasonic rangefinders, and ideally a camera. [http://circ.mtco.com/competitions/2010/rules/sumo Sumo rules].
|-
|Brian Embry Jessica Lipscomb Paul Banister
| [[ECE597 Network based MP3 player]]
| Network based mp3 player. The Beagle will be programmed using a custom, protocol for transferring files from a network based server (x86 pc) to a Beagle. Speakers will be attached to the Beagle, where the file will be played back. Possible extensions are a LCD for displaying id3 tag information, and buttons for user interaction (next track, previous track, etc.) on the GPIO interface.
|-
|[[user:routhcr | Chris Routh]] [[user:collinjc | J. Cody Collins]] Greg Jackson Keqiong Xin
| [[ECE597: Auto HUD]]
| Use the beagle board to run image recognition on a camera feed located inside a car, and then signaling to the driver via a pico projector various objects of interest.
|-
| Adam Jesionowski Qiang Jiang
| Adding Sense to Beagle (See [[BeagleBoard/GSoC/Ideas]])
| Sensory aware applications are becoming more mainstream with the release of the Apple iPhone. This project would combine both HW and SW to add sensory awareness to beagle. First, additional modules such as GPS, 3-axis accelerometers, Gyroscopes, Temperature Sensors, Humidity Sensors, Pressure Sensors, etc, would be added to beagle to compliment the microphone input in order to allow sensing of the real world environment. Then SW APIs would need to be layered on top to allow easy access to the sensory data for use by applications.
|-
| Mitch Garvin Matt Luke Elliot Simon Jian Li
| [[ECE597 Interactive Pong]]
| Run classic pong, projecting the screen and using a camera to track user's hands for input.
|}

User:SStark

2010-03-17T03:05:58Z

SStark: Creating user page

I'm a senior at Rose-Hulman enrolled in ECE597.

[[Category:ECE597]]

ECE497 Project Ideas

2010-03-17T02:52:10Z

SStark: Adding 3D Chess Idea

[[Category:ECE597]]
[[Category:BeagleBoard]]

== Sources for Project Ideas ==

Here are some links where you'll find ideas for your project.
* [http://wiki.omap.com/index.php/ETechDays_Community_Lightning_Talks ETechDays Community Lightning Talks], this is a one-day web-based conference where many project ideas are presented. One of our 2009-2010 senior design projects was found here.
* [http://beagleboard.org/project Official list of Beagle Projects], there are many Beagle specific projects listed here. Many are inactive. ''List your project here once it running.''
* [http://www.youtube.com/watch?v=Mk1xjbA-ISE Augmented Reality Project], here's an idea that I think we can do on the Beagle. Rather than using augmented reality glasses, I'd suggest we use a [http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60&tabId=2235 TI DLP pico projector]. [http://www.hitlabnz.org/wiki/EmbeddedAR Here's] AR running on the Beagle.
* [http://code.google.com/p/0xdroid/ Android], this is one of a couple of efforts to port [http://source.android.com/ Google's Android OS] to the Beagle.
* [[BeagleBoard/Ideas-2009]] Google summer code ideas 2009.

== Projects you would like to do ==
Edit this page to add projects you would like to do. If you aren't in the class, add ideas you would like to see done by class members.

{| border="1" cellspacing="0" cellpadding="5"
! Team Members
! Project Title
! Description
|-
| Mark A. Yoder
| [[ECE597 Google PowerMeter]]
| Google has a [http://www.google.com/powermeter project] to view and manage home electricity usage. This project would involve designing the hardware to measure the power usage and the Beagle software in interface with it. The Beagle would talk to the local home network via a wireless link and the home owner would configure the Beagle via a web page served on the Beagle.
|-
| Yannick Polius Steven Stark Paul Morrison
| Audio MBox
| This project is mostly software, with the hardware element being the use of the dsp. The idea is to tie together three technologies: speech recognition, speech synthesis, and internet access in order to create an interface capable of orating information to the user based on a vocal command. The implementation I have in mind is to use the Pocket Sphinx speech recognition engine to first understand what the user wants through speech, such as "Rose-Hulman". Once the speech is translated, the software can execute a Wikipedia search to pull said item's page. Most of the important info is contained within the introductory paragraph, so the software will take only that chunk and feed it into the Flite speech synthesis engine. The end result is a simple machine with "mother box" like usability, that is, no interaction besides what is natural to the user (speaking) should be necessary to retrieve the information.
|-
| Paul Morrison Steven Stark
| 3D Chess with Networking
| This project would simulate a hand-held chess game, and the game would allow two player games using two beagleboards over a network connection. The graphics would use the beagle's PowerVR SGX for hardware accelerated graphics by using OpenGL. In addition to 3D graphics and networking, a third portion of the project would be to optimize the boot time because a chess computer should start up quickly.
|-
| David Baty Tom Most Mark Jacobson
| IRLP Node
| [http://www.irlp.net/ IRLP (Internet Radio Linking Project)] is an amateur radio project to allow the linking of repeaters across the world over the internet. It requires very little hardware, but due to an antiquated interface board and is typically run on old desktop hardware that uses significantly more power than a beagle board. All of the software already runs on Linux, but would require some porting. Interface hardware would also have to be designed, but if DTMF (dial tone) decoding is done in software, this external board would be very simple.
|-
| Tom Most David Baty Mark Jacobson
| Sumo Robot (fallback for IRLP project)
| The goal of this project is to create a robot capable of competing in the 3.0 kg weight class of a sumo competition ([http://www.youtube.com/watch?v=V3OR_sHrOJM an example]). This would have minor hardware and electronics elements, but would focus on communication with sensors using the BeagleBoard and the Linux kernel. At minimum, this involves sensors to detect the edge of the ring and the opposing robot. This would likely be implemented using Sharp IR rangefinders, a ultrasonic rangefinders, and ideally a camera. [http://circ.mtco.com/competitions/2010/rules/sumo Sumo rules].
|-
|Brian Embry Jessica Lipscomb Paul Banister
| [[ECE597: MythTV/DSP Pico Projector]]
| Have the Beagleboard act as a MythTV/portable video playback node. This may require work with the DSP acceleration of FFMPEG/Gstreamer. Additionally, interfacing with a Pico Projector to allow for portable media enjoyment. If MythTV support is not practical, simple localized video playback with DSP acceleration will be used.
|-
|Chris Routh [[user:collinjc | J. Cody Collins]] Greg Jackson Keqiong Xin
| [[ECE597: Auto HUD]]
| Use the beagle board to run image recognition on a camera feed located inside a car, and then signaling to the driver via a pico projector various objects of interest.
|-
| Adam Jesionowski Qiang Jiang
| Adding Sense to Beagle (See [[BeagleBoard/GSoC/Ideas]])
| Sensory aware applications are becoming more mainstream with the release of the Apple iPhone. This project would combine both HW and SW to add sensory awareness to beagle. First, additional modules such as GPS, 3-axis accelerometers, Gyroscopes, Temperature Sensors, Humidity Sensors, Pressure Sensors, etc, would be added to beagle to compliment the microphone input in order to allow sensing of the real world environment. Then SW APIs would need to be layered on top to allow easy access to the sensory data for use by applications.
|-
| Mitch Garvin Matt Luke Elliot Simon Jian Li
| [[ECE597 Interactive Pong]]
| Run classic pong, projecting the screen and using a camera to track user's hands for input.
|}

ECE497 Editing a Wiki

2010-03-09T00:34:22Z

SStark:

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]].

{|
! Name
! Date
|-
| Mark A. Yoder
| 2-Mar-2010
|-
| Elliot Simon
| 8-Mar-2010
|-
| Mitch Garvin
| 8-Mar-2010
|-
| J. Cody Collins
| 8-Mar-2010
|-
| Steven Stark
| 8-Mar-2010
|-
| Next name
| and date
|}

[[Category:ECE597]]