https://elinux.org/api.php?action=feedcontributions&user=Tpurviance&feedformat=atomeLinux.org - User contributions [en]2024-03-29T14:04:16ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303104ECE497 Project Programmable Light Show2013-11-18T11:52:36Z<p>Tpurviance: /* Conclusions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
'''Required Hardware'''<br />
<br />
:In addition to a BeagleBone Black, this project requires 5 meters of [http://www.adafruit.com/products/306 Adafruit's LPD8806 LED Strip].<br />
<br />
'''Required Software'''<br />
<br />
:You'll find everything you need in this projects github repo: [https://github.com/tpurviance/programmable-light-show https://github.com/tpurviance/programmable-light-show] <br />
<br />
'''Installation'''<br />
<br />
:Connect the LED light strip <br />
::The LED light strip should be plugged in to 3.3V (should be hooked to the white dot on the LED plug), P9_22, P9_18, and ground. Be especially careful, as the LED light strip can be critically damaged through improper wiring or voltages.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
:Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
:Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
:With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
:Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
:Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Add idle playing behavior'''<br />
::While this project is cool, if the lights are up and running all the time then one can't expect someone to always be sending light displays to it. Thus, it might be a good idea to store up some light shows to display when no one else is trying to display something. After some amount of time or after all users have disconnected, have the boneserver start to play back a recording of the light setting commands someone had sent it. Perhaps a static batch of them loaded in from text files on startup, or perhaps just a rotation of the last X frames or videos that users have sent to it.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual and interactive. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest adding the video sending and idle playing features from above be added next, as both of them would help keep the lights playing constantly, they're both fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303098ECE497 Project Programmable Light Show2013-11-18T11:40:42Z<p>Tpurviance: /* User Instructions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
'''Required Hardware'''<br />
<br />
:In addition to a BeagleBone Black, this project requires 5 meters of [http://www.adafruit.com/products/306 Adafruit's LPD8806 LED Strip].<br />
<br />
'''Required Software'''<br />
<br />
:You'll find everything you need in this projects github repo: [https://github.com/tpurviance/programmable-light-show https://github.com/tpurviance/programmable-light-show] <br />
<br />
'''Installation'''<br />
<br />
:Connect the LED light strip <br />
::The LED light strip should be plugged in to 3.3V (should be hooked to the white dot on the LED plug), P9_22, P9_18, and ground. Be especially careful, as the LED light strip can be critically damaged through improper wiring or voltages.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
:Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
:Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
:With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
:Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
:Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Add idle playing behavior'''<br />
::While this project is cool, if the lights are up and running all the time then one can't expect someone to always be sending light displays to it. Thus, it might be a good idea to store up some light shows to display when no one else is trying to display something. After some amount of time or after all users have disconnected, have the boneserver start to play back a recording of the light setting commands someone had sent it. Perhaps a static batch of them loaded in from text files on startup, or perhaps just a rotation of the last X frames or videos that users have sent to it.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest that adding the video sending and idle playing features from above be added next, as both of them are fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303092ECE497 Project Programmable Light Show2013-11-18T11:40:03Z<p>Tpurviance: /* Installation Instructions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
'''Required Hardware'''<br />
<br />
:In addition to a BeagleBone Black, this project requires 5 meters of [http://www.adafruit.com/products/306 Adafruit's LPD8806 LED Strip].<br />
<br />
'''Required Software'''<br />
<br />
:You'll find everything you need in this projects github repo: [https://github.com/tpurviance/programmable-light-show https://github.com/tpurviance/programmable-light-show] <br />
<br />
'''Installation'''<br />
<br />
:Connect the LED light strip <br />
::The LED light strip should be plugged in to 3.3V (should be hooked to the white dot on the LED plug), P9_22, P9_18, and ground. Be especially careful, as the LED light strip can be critically damaged through improper wiring or voltages.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Add idle playing behavior'''<br />
::While this project is cool, if the lights are up and running all the time then one can't expect someone to always be sending light displays to it. Thus, it might be a good idea to store up some light shows to display when no one else is trying to display something. After some amount of time or after all users have disconnected, have the boneserver start to play back a recording of the light setting commands someone had sent it. Perhaps a static batch of them loaded in from text files on startup, or perhaps just a rotation of the last X frames or videos that users have sent to it.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest that adding the video sending and idle playing features from above be added next, as both of them are fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303086ECE497 Project Programmable Light Show2013-11-18T11:36:48Z<p>Tpurviance: /* Installation Instructions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
=== Required Hardware ===<br />
<br />
:In addition to a BeagleBone Black, this project requires 5 meters of [http://www.adafruit.com/products/306 Adafruit's LPD8806 LED Strip].<br />
<br />
=== Required Software ===<br />
<br />
:You'll find everything you need in this projects github repo: [https://github.com/tpurviance/programmable-light-show https://github.com/tpurviance/programmable-light-show] <br />
<br />
=== Installation ===<br />
<br />
'''Connect the LED light strip'''<br />
:The LED light strip should be plugged in to 3.3V (should be hooked to the white dot on the LED plug), P9_22, P9_18, and ground. Be especially careful, as the LED light strip can be critically damaged through improper wiring or voltages.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Add idle playing behavior'''<br />
::While this project is cool, if the lights are up and running all the time then one can't expect someone to always be sending light displays to it. Thus, it might be a good idea to store up some light shows to display when no one else is trying to display something. After some amount of time or after all users have disconnected, have the boneserver start to play back a recording of the light setting commands someone had sent it. Perhaps a static batch of them loaded in from text files on startup, or perhaps just a rotation of the last X frames or videos that users have sent to it.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest that adding the video sending and idle playing features from above be added next, as both of them are fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303026ECE497 Project Programmable Light Show2013-11-18T09:55:35Z<p>Tpurviance: /* Future Work */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Add idle playing behavior'''<br />
::While this project is cool, if the lights are up and running all the time then one can't expect someone to always be sending light displays to it. Thus, it might be a good idea to store up some light shows to display when no one else is trying to display something. After some amount of time or after all users have disconnected, have the boneserver start to play back a recording of the light setting commands someone had sent it. Perhaps a static batch of them loaded in from text files on startup, or perhaps just a rotation of the last X frames or videos that users have sent to it.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest that adding the video sending and idle playing features from above be added next, as both of them are fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=303008ECE497 Project Programmable Light Show2013-11-18T09:49:02Z<p>Tpurviance: /* Conclusions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Bringing the project this far has been lots of fun because it is so visual. Although there's still that rogue LED in the chain, for the most part it's all behaving fairly well. As one of the goals is to make this project usable to decorate the ECE department tree, I would suggest that adding the video sending and idle playing features from above be added next, as both of them are fairly easy to implement and can be up and running in time for the lights to be on the tree when it arrives.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302996ECE497 Project Programmable Light Show2013-11-18T09:41:44Z<p>Tpurviance: /* Highlights */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
[https://www.youtube.com/watch?v=9nvSi4OU698 Demo Video]<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302942ECE497 Project Programmable Light Show2013-11-18T09:01:40Z<p>Tpurviance: /* Work Breakdown */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multi-user handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302936ECE497 Project Programmable Light Show2013-11-18T09:01:10Z<p>Tpurviance: /* Future Work */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multiuser handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be performing for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it receives from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302930ECE497 Project Programmable Light Show2013-11-18T08:59:22Z<p>Tpurviance: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beaglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multi-user access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multiuser handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be preforming for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it recieves from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302924ECE497 Project Programmable Light Show2013-11-18T08:00:25Z<p>Tpurviance: /* Future Work */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multiuser access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multiuser handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multi-user handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave and mess up the display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that continually sends frames to the server, the server has to off the messages itself. The server currently has a maximum frame buffer size and maximum allowable delay for this purpose. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish, saving the server that much work. <br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Updating localized light visualization'''<br />
::If users won't be able to be next to the lights all the time, or the lights might not currently be preforming for them but rather performing some other user's code (if multi-user capabilities are added), it could be beneficial to the user experience to allow them to locally view the lightshow with the html canvas I had working before. It wouldn't be hard to do. You could copy exactly what the server does with the socket.io signals it recieves from users, and execute it locally, including the queuing and the delays.<br />
<br />
*'''Add more lights'''<br />
::Pretty self explanatory. A longer or more densely packed light strand would look better and give the users more to work with, though the strands don't come cheaply. However, adding more lights could slow down the light refresh rate of the strand.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302918ECE497 Project Programmable Light Show2013-11-18T07:22:25Z<p>Tpurviance: /* Future Work */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multiuser access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multiuser handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
There's a wealth of possible future features to add, as well as a few bugs to fix:<br />
<br />
*'''Multiuser handling'''<br />
::There's a number of ways one could go about doing this, but the simplest would be to have the server maintain not one queue of light messages, but to have a mapping of connections to queues so that each users interactions with the bone can be stored in a separate queue so their messages don't interleave, messing up display for both of them. Deciding when to play animations from which queue is also an interesting problem. One solution is to just play some amount of each user's animation on the bone, measured in number of frames and the amount of delay they use.<br />
<br />
*'''Video sending instead of frame sending'''<br />
::It may be beneficial performance-wise to send an entire video of animation instead of a single frame, as it currently does. This would allow for entire animations to easily be sent, stored, and played, as well as saving on socket.io overhead. It would also help to protect the server from bad code. If the user made in infinite loop that sends signals now, the server has to detect that and cut off the messages. If the entire message has to be sent at once, the user would just have to deal with his non-terminating loop, as the message would never be sent at the end because their code would never finish.<br />
<br />
*'''Add input controls'''<br />
::This one could be very tricky, but opens a whole new world of functionality for the project. Adding some physical buttons / dials / whatever near the lights to allow people to interact with them would be very interesting. The pacman "game" demo'd above would be one such example that would be vastly improved by some user input. However, doing this would likely force the project to move away from the current setup of making frames on the front end and sending them to the back end to be displayed, and instead force the Blockly-produced lightshow programs (not frames) to be sent to the bone to be run so they could handle real-time user data. Allowing execution of arbitrary user-generated javascript code on the bone certainly strikes me as being a big security problem, though I'm not hugely knowledgeable on the subject. Perhaps there is some other way to allow input to be handled without executing arbitrary code on the bone.<br />
<br />
*'''Fixing the first light'''<br />
::For some (I'm feeling driver-related) reason, the first light in the strand is not changing to be the correct color all the time.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302912ECE497 Project Programmable Light Show2013-11-18T06:03:13Z<p>Tpurviance: /* Work Breakdown */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multiuser access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
Here are some of the big accomplishments of the project to date:<br />
<br />
* Integrated Blockly (hosted externally) into a web page hosted from the bone<br />
* Added custom blocks to Blockly to 1) track the state of the lights being changed 2) sends the lights that are being changed via the program to the bone via socket.io<br />
* Added an html5 canvas / javascript powered display of the state of the lights to the top of the web display, though it doesn't yet know how to handle the recently added delay function, so it only shows the end result of running the program.<br />
* Added some new socket.io message handling to the server.<br />
* Added message queuing to the server code, allowing it to do things like delays in an intelligent way. This is queuing behavior also lays the groundwork for multiuser handling, as well as "recording" and "playing" back light shows, all of which require something other than "just display the lights when we're told".<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302900ECE497 Project Programmable Light Show2013-11-18T05:21:51Z<p>Tpurviance: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a Beglebone controlling a strand of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a simple web interface, allowing anyone to program the lights.<br />
<br />
The system works pretty well with a single user, allowing them to program the lights via web interface and have the lights update. Most issues of the light update speed have been rectified and now updates fast enough. <br />
<br />
Somewhere, the first light on the chain isn't always getting set properly for some reason (which I suspect is kernel driver related). Also, there's no support yet for remembering your Blockly program if you accidentally close the tab which you were working in, and every programmer knows irreversibly losing code can be infuriating.<br />
<br />
The project is actually in a really good position right now, though it isn't ready yet for public / multiuser access. With a few exceptions, it does what it does well and is enjoyable to use and see used, so the focus of future development can be on any of a plethora of possible new features.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302888ECE497 Project Programmable Light Show2013-11-18T03:51:32Z<p>Tpurviance: /* Theory of Operation */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|1000px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302882ECE497 Project Programmable Light Show2013-11-18T03:43:19Z<p>Tpurviance: /* Theory of Operation */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
[[File:lightShowDiagram.png|700px]]<br />
<br />
This diagram gives a good macro-scale view of the design. The Blockly code, both my custom blocks and the default ones, produce and run javascript code in the browser. The blocks that I added also send messages via socket.io to the boneserver. Each message contains a list of the lights that need changed, what they need changed to, and how long the boneserver should wait before processing the next message. <br />
The boneserver maintains a queue of the received messages which it process in the order they are received. The contents of the message are read and the bonescript writeToTextFile() method writes the appropriate batch of light changing data to the kernel driver, which then parses those messages and shifts the appropriate data down the light chain.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=File:LightShowDiagram.png&diff=302876File:LightShowDiagram.png2013-11-18T03:36:05Z<p>Tpurviance: diagram showing overview of the light show project's architecture.</p>
<hr />
<div>diagram showing overview of the light show project's architecture.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302816ECE497 Project Programmable Light Show2013-11-18T02:13:51Z<p>Tpurviance: /* Highlights */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
The thing about this project is that it's really just an enabler; it enables anyone that connects to the server to come up with their own ideas about what they want to have the LED string display, and it lets them do it. That being said, here's a video to demonstrate some of the things you can have it do.<br />
<br />
'''PUT VIDEO HERE'''<br />
<br />
In the video there are 3 things demo'd:<br />
<br />
*A red sine wave and a shorter-wavelengthed red sine wave<br />
*A single red light the races to the end of the strand and races back blue, then does the same thing but as a group of 10 lights.<br />
*A simplified no-controls version of pacman, which spawns some random white pellets and has a yellow group of pacman lights go down the strand until he's eaten them all, at which point he blinks a few times to show that he's won.<br />
<br />
These are just some of the things someone could make. Creativity and time were my limiting factors for this demo, but I hope to see others make more interesting displays with this tool.<br />
<br />
== Theory of Operation ==<br />
<br />
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.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302810ECE497 Project Programmable Light Show2013-11-18T01:16:15Z<p>Tpurviance: /* User Instructions */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
1. '''Run the setup script'''<br />
::Run the included <code>setup.sh</code> file.<br />
2. '''Start the boneserver'''<br />
::Start the included <code>boneserver.js</code> file.<br />
3. '''Navigate a the page via web browser'''<br />
::With the boneserver now running, point your web browser to your bone's IP address on port 8080.<br />
4. '''Drag and drop blocks'''<br />
::Although there are a plethora of blocks available in blockly, you will likely be interested in the blocks under the "lights" category. One of the blocks if for setting a light at a position to a color. The position value should be between 0 and 159, while the red, green, and blue values should be between 0 and 127. However, this is just queuing up the changes locally. To display the changes you've made, use the send lights block. If you want more than one light to change at the same time, use the set lights block multiple times before using the send lights block. If you're doing some animation, you'll likely want to give it a number of milliseconds to delay after the lights are changed before they will be set again.<br />
5. '''Click the "run" button'''<br />
::Once you are ready to see your code run, click the "run" button near the top of the web page. If you get a message saying something about "bad code" make sure that your blockly blocks have all of their input spots filled or simplify your design and try again.<br />
<br />
== Highlights ==<br />
<br />
Here is where you brag about what your project can do.<br />
<br />
Include a [http://www.youtube.com/ YouTube] demo.<br />
<br />
== Theory of Operation ==<br />
<br />
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.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=302582ECE497 Project Programmable Light Show2013-11-17T21:38:15Z<p>Tpurviance: /* Packaging */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.<br />
<br />
== Highlights ==<br />
<br />
Here is where you brag about what your project can do.<br />
<br />
Include a [http://www.youtube.com/ YouTube] demo.<br />
<br />
== Theory of Operation ==<br />
<br />
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.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=299666ECE497 Project Programmable Light Show2013-11-11T18:00:37Z<p>Tpurviance: /* Executive Summary */</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is up and running, allowing individual LEDs to be changed via a drag-and drop programming interface accessible via browser. However, the speed of communications / light changes is still a bit of a problem. Using the slow way, it would take 2 or 3 seconds to change all the lights.<br />
<br />
Most of the effort of the project is now focused on changing the interface so that multiple light changes can be bundled in messages, making fewer messages and (hopefully) faster update times.<br />
<br />
== Packaging ==<br />
<br />
If you have hardware, consider [http://cpprojects.blogspot.com/2013/07/small-build-big-execuition.html Small Build, Big Execuition] for ideas on the final packaging.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.<br />
<br />
== Highlights ==<br />
<br />
Here is where you brag about what your project can do.<br />
<br />
Include a [http://www.youtube.com/ YouTube] demo.<br />
<br />
== Theory of Operation ==<br />
<br />
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.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Contributions_and_Project_Status&diff=293372EBC Contributions and Project Status2013-10-22T11:36:59Z<p>Tpurviance: /* Project Status */</p>
<hr />
<div>[[Category:ECE497 |Contributions]]<br />
{{YoderHead}}<br />
<br />
== Fall 2013 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:Alvareap | Alex Alvarez]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project LCD Tetris Game| Tetris Game]]<br />
| [https://github.com/alvareap/classwork classwork ]<br />
|-<br />
| [[User:amesen | Eric Ames]]<br />
| [[Special:Contributions/amesen | contrib]]<br />
| [[ECE497 Project Music Server | Music Server]]<br />
| [https://github.com/Guiltygate/beaglebone-classwork classwork]<br />
|-<br />
| [[User:Andrewca | Chris Andrews]]<br />
| [[Special:Contributions/Andrewca| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Cooperdl | David Cooper]]<br />
| [[Special:Contributions/Cooperdl | contrib]]<br />
| [[ECE497 Project Music Server | Music Server]]<br />
| [https://github.com/cooperdl/Classwork Classwork]<br />
|-<br />
| [[User:elswicwj | Will Elswick]]<br />
| [[Special:Contributions/elswicwj| contrib]]<br />
| [[ECE497 Project Makeshift Drums | Makeshift Drums]]<br />
| [https://github.com/elswicwj/ECE497.git classwork]<br />
|-<br />
| [[User:fendrirj | Robert Fendricks]]<br />
| [[Special:Contributions/fendrirj| contrib]]<br />
| [[ECE497 Project GPS Tracker | GPS Tracker]]<br />
| [https://github.com/Fendrirj/ECE497 classwork]<br />
|-<br />
| [[User:Rockybulwinkle | Chris Hopwood]]<br />
| [[Special:Contributions/Rockybulwinkle| contrib]]<br />
| [[ECE497 Project GPS Tracker | GPS Tracker]]<br />
| [https://github.com/rockybulwinkle/beaglebone/ Classwork]<br />
|-<br />
| [[User:daniel.hou | Junxuan Hou]]<br />
| [[Special:Contributions/hou| contrib]]<br />
| [[ECE497 Project Electric Car | Electric Car]]<br />
| [https://github.com/houj/Homework.git Classwork]<br />
|-<br />
| [[User:Kowalsif | Ian Kowalski]]<br />
| [[Special:Contributions/kowalsif| contrib]]<br />
| [[ECE497 Project GameSystem | GameSystem]]<br />
| [https://github.com/kowalsif/Beagle BeagleCode]<br />
|-<br />
| [[User:FreeTymeKiyan | Yang Liu]]<br />
| [[Special:Contributions/FreeTymeKiyan | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/FreeTymeKiyan/EmbeddedLinux.git FreeTymeKiyan]<br />
|-<br />
| [[User:Mcdonamp | Mike McDonald]]<br />
| [[Special:Contributions/mcdonamp| contrib]]<br />
| [[ECE497 Project Quadcopter Server | Quadcopter Server]]<br />
| [https://github.com/mcdonamp/497Homework 497Homework]<br />
|-<br />
| [[User:Parasby| Ben Paras]]<br />
| [[Special:Contributions/Parasby | contrib]]<br />
| [[ECE497 Project WireShark| WireShark]]<br />
| [https://github.com/parasby2014/ECE497---Embedded-Linux ECE497HW]<br />
|-<br />
| [[User:Tpurviance| Taylor Purviance]]<br />
| [[Special:Contributions/Tpurviance | contrib]]<br />
| [[ECE497 Project Programmable Light Show | Light Show]]<br />
| [https://github.com/tpurviance/E32bL Homework]<br />
|-<br />
| [[User:Axiixc| James Savage]]<br />
| [[Special:Contributions/Axiixc | contrib]]<br />
| [[ECE497 Project Makeshift Drums | Makeshift Drums]]<br />
| [https://github.com/axiixc/ece497 axiixc/ece497]<br />
|-<br />
| [[User:savrdada | David Savrda]]<br />
| [[Special:Contributions/savrdada| contrib]]<br />
| [[ECE497 Project GameSystem | GameSystem]]<br />
| [https://github.com/muglump/BeagleBoneHomework BeagleBoneRepo]<br />
|-<br />
| [[User:skorinm | Matt Skorina]]<br />
| [[Special:Contributions/skorinm| contrib]]<br />
| [[ECE497 Project Quadcopter Server | Quadcopter Server]]<br />
| [https://github.com/skorinm/Homework Homework]<br />
|-<br />
| [[User:Manuel | Manuel Stephan]]<br />
| [[Special:Contributions/Manuel | contrib]]<br />
| [[ECE497 Project WireShark | WireShark]]<br />
| [https://github.com/manuelstephan/homework Homework]<br />
|-<br />
| [[User:Alvareap | Zhen Wei]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Electric Car | Electric Car]]<br />
| [https://github.com/weizhen1883/homework.git HomeWork]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Yuxuan | Yuxuan Zeng]]<br />
| [[Special:Contributions/zeng| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/yuxuanzeng classwork]<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:atniptw | Tom Atnip]]<br />
| [[Special:Contributions/atniptw|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/atniptw/ atniptw]<br />
|-<br />
| [[User:jessebrannon | Jesse Brannon]]<br />
| [[Special:Contributions/Jessebrannon|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/brannojs/ brannojs]<br />
|-<br />
| [[User:Xinyu1991 | Xinyu Cheng]]<br />
| [[Special:Contributions/Xinyu1991|contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/xinyu1991/ Xinyu Cheng]<br />
|-<br />
| [[User:correlbn | Bryan Correll]]<br />
| [[Special:Contributions/correlbn|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]<br />
|-<br />
| [[User:draneaw | Alex Drane]]<br />
| [[Special:Contributions/draneaw|contrib]]<br />
| [[ECE497: Remote Web Cam Viewer Final Project| Remote Web Cam Viewer]]<br />
| [https://github.com/draneaw/ Draneaw]<br />
|-<br />
| [[User:duganje | Josh Dugan]]<br />
| [[Special:Contributions/duganje|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/duganje/ duganje]<br />
|-<br />
| [[User:Geislekj | Kevin Geisler]]<br />
| [[Special:Contributions/geislekj|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/geislekj/ geislekj]<br />
| <br />
|-<br />
| [[User:chris.good | Christopher A Good]]<br />
| [[Special:Contributions/Chris.good|contrib]]<br />
| [[ECE497 Project RoverGUI | RoverGUI]]<br />
| [https://github.com/goodca/ goodca]<br />
| <br />
|-<br />
| [[User:hansenrl | Ross Hansen]]<br />
| [[Special:Contributions/hansenrl|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/hansenrl/ Hansenrl]<br />
| <br />
|-<br />
| [[User:jungeml | Michael Junge]]<br />
| [[Special:Contributions/jungeml|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/jungeml/ Jungeml]<br />
|-<br />
| [[User:larmorgs | Greg Larmore]]<br />
| [[Special:Contributions/larmorgs|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/larmorgs Greg Larmore]<br />
|-<br />
| [[User:Lobdeljt | John Lobdell]]<br />
| <br />
| [[ECE 497 lobdeljt Project | My Beagle Project]]<br />
| [https://github.com/jtlobdell jtlobdell]<br />
|-<br />
| [[User:Lix | Xia Li]]<br />
| [[Special:Contributions/Lix|contrib]]<br />
| [[ECE497 Project: Kinect | Kinect]]<br />
| [https://github.com/1984xiali/ xiali]<br />
|-<br />
| [[User:Millerap | Andrew Miller]]<br />
| [[Special:Contributions/Millerap|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/millerap millerap]<br />
|-<br />
| [[User:mmoravec | Matthew Moravec]]<br />
| [[Special:Contributions/mmoravec|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/mmoravec/ mmoravec]<br />
|-<br />
| [[User:ngop | Peter Ngo]]<br />
| [[Special:Contributions/ngop|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/ngop/ ngop]<br />
|-<br />
| [[User:Popenhjc | James Popenhagen]]<br />
| [[Special:Contributions/Popenhjc|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/popenhjc/ popenhjc]<br />
|-<br />
| [[User:Richarsm | Sean Richardson]]<br />
| [[Special:Contributions/Richarsm|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/seanrich Sean Richardson]<br />
|-<br />
| [[User:shinnsm|Stephen Shinn]]<br />
| [[Special:Contributions/shinnsm|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/shinnsm shinnsm]<br />
|-<br />
| [[User:Whiteer | Elias White]]<br />
| <br />
| [[ECE497 SLAM via ROS | My Beagle Project]]<br />
| [https://github.com/whiteer whiteer]<br />
|-<br />
| [[User:ruff | Ruffin White]]<br />
| [[Special:Contributions/ruff|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/ruffsl/ ruffsl]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Astroricks | Yue Zhang]]<br />
| [[Special:Contributions/Astroricks | contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Yuming | Yuming Cao]]<br />
# [[Special:Contributions/Yifei | Yifei Li]]<br />
# [[Special:Contributions/Harrisgw | Greg Harrison]]<br />
# [[Special:Contributions/mac | Jack Ma]]<br />
# [[Special:Contributions/Gemini91 | Guanqun Wang]]<br />
# [[Special:Contributions/Yanj | Mona Yan]]<br />
# [[Special:Contributions/Yoder | Mark A. Yoder]]<br />
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]<br />
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]<br />
# [[Special:Contributions/Zitnikdj | David Zitnik]]<br />
# [[Special:Contributions/Zitnikdj | Alex Drane]]<br />
# [[Special:Contributions/jessebrannon | Jesse Brannon]]<br />
# [[Special:Contributions/larmorgs | Greg Larmore]]<br />
# [[Special:Contributions/jungeml | Michael Junge]]<br />
# [[Special:Contributions/millerap | Andrew Miller]]<br />
# [[Special:Contributions/correlbn | Bryan Correll]]<br />
<br />
=== Project Status ===<br />
<br />
# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]<br />
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]<br />
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]<br />
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]<br />
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]<br />
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]<br />
<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Contributions_and_Project_Status&diff=293366EBC Contributions and Project Status2013-10-22T11:36:26Z<p>Tpurviance: /* Project Status */</p>
<hr />
<div>[[Category:ECE497 |Contributions]]<br />
{{YoderHead}}<br />
<br />
== Fall 2013 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:Alvareap | Alex Alvarez]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project LCD Tetris Game| Tetris Game]]<br />
| [https://github.com/alvareap/classwork classwork ]<br />
|-<br />
| [[User:amesen | Eric Ames]]<br />
| [[Special:Contributions/amesen | contrib]]<br />
| [[ECE497 Project Music Server | Music Server]]<br />
| [https://github.com/Guiltygate/beaglebone-classwork classwork]<br />
|-<br />
| [[User:Andrewca | Chris Andrews]]<br />
| [[Special:Contributions/Andrewca| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Cooperdl | David Cooper]]<br />
| [[Special:Contributions/Cooperdl | contrib]]<br />
| [[ECE497 Project Music Server | Music Server]]<br />
| [https://github.com/cooperdl/Classwork Classwork]<br />
|-<br />
| [[User:elswicwj | Will Elswick]]<br />
| [[Special:Contributions/elswicwj| contrib]]<br />
| [[ECE497 Project Makeshift Drums | Makeshift Drums]]<br />
| [https://github.com/elswicwj/ECE497.git classwork]<br />
|-<br />
| [[User:fendrirj | Robert Fendricks]]<br />
| [[Special:Contributions/fendrirj| contrib]]<br />
| [[ECE497 Project GPS Tracker | GPS Tracker]]<br />
| [https://github.com/Fendrirj/ECE497 classwork]<br />
|-<br />
| [[User:Rockybulwinkle | Chris Hopwood]]<br />
| [[Special:Contributions/Rockybulwinkle| contrib]]<br />
| [[ECE497 Project GPS Tracker | GPS Tracker]]<br />
| [https://github.com/rockybulwinkle/beaglebone/ Classwork]<br />
|-<br />
| [[User:daniel.hou | Junxuan Hou]]<br />
| [[Special:Contributions/hou| contrib]]<br />
| [[ECE497 Project Electric Car | Electric Car]]<br />
| [https://github.com/houj/Homework.git Classwork]<br />
|-<br />
| [[User:Kowalsif | Ian Kowalski]]<br />
| [[Special:Contributions/kowalsif| contrib]]<br />
| [[ECE497 Project GameSystem | GameSystem]]<br />
| [https://github.com/kowalsif/Beagle BeagleCode]<br />
|-<br />
| [[User:FreeTymeKiyan | Yang Liu]]<br />
| [[Special:Contributions/FreeTymeKiyan | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/FreeTymeKiyan/EmbeddedLinux.git FreeTymeKiyan]<br />
|-<br />
| [[User:Mcdonamp | Mike McDonald]]<br />
| [[Special:Contributions/mcdonamp| contrib]]<br />
| [[ECE497 Project Quadcopter Server | Quadcopter Server]]<br />
| [https://github.com/mcdonamp/497Homework 497Homework]<br />
|-<br />
| [[User:Parasby| Ben Paras]]<br />
| [[Special:Contributions/Parasby | contrib]]<br />
| [[ECE497 Project WireShark| WireShark]]<br />
| [https://github.com/parasby2014/ECE497---Embedded-Linux ECE497HW]<br />
|-<br />
| [[User:Tpurviance| Taylor Purviance]]<br />
| [[Special:Contributions/Tpurviance | contrib]]http://elinux.org/ECE497_Project_Programmable_Light_Show<br />
| [[ECE497 Project Programmable Light Show | Light Show]]<br />
| [https://github.com/tpurviance/E32bL Homework]<br />
|-<br />
| [[User:Axiixc| James Savage]]<br />
| [[Special:Contributions/Axiixc | contrib]]<br />
| [[ECE497 Project Makeshift Drums | Makeshift Drums]]<br />
| [https://github.com/axiixc/ece497 axiixc/ece497]<br />
|-<br />
| [[User:savrdada | David Savrda]]<br />
| [[Special:Contributions/savrdada| contrib]]<br />
| [[ECE497 Project GameSystem | GameSystem]]<br />
| [https://github.com/muglump/BeagleBoneHomework BeagleBoneRepo]<br />
|-<br />
| [[User:skorinm | Matt Skorina]]<br />
| [[Special:Contributions/skorinm| contrib]]<br />
| [[ECE497 Project Quadcopter Server | Quadcopter Server]]<br />
| [https://github.com/skorinm/Homework Homework]<br />
|-<br />
| [[User:Manuel | Manuel Stephan]]<br />
| [[Special:Contributions/Manuel | contrib]]<br />
| [[ECE497 Project WireShark | WireShark]]<br />
| [https://github.com/manuelstephan/homework Homework]<br />
|-<br />
| [[User:Alvareap | Zhen Wei]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Electric Car | Electric Car]]<br />
| [https://github.com/weizhen1883/homework.git HomeWork]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Yuxuan | Yuxuan Zeng]]<br />
| [[Special:Contributions/zeng| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/yuxuanzeng classwork]<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:atniptw | Tom Atnip]]<br />
| [[Special:Contributions/atniptw|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/atniptw/ atniptw]<br />
|-<br />
| [[User:jessebrannon | Jesse Brannon]]<br />
| [[Special:Contributions/Jessebrannon|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/brannojs/ brannojs]<br />
|-<br />
| [[User:Xinyu1991 | Xinyu Cheng]]<br />
| [[Special:Contributions/Xinyu1991|contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/xinyu1991/ Xinyu Cheng]<br />
|-<br />
| [[User:correlbn | Bryan Correll]]<br />
| [[Special:Contributions/correlbn|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]<br />
|-<br />
| [[User:draneaw | Alex Drane]]<br />
| [[Special:Contributions/draneaw|contrib]]<br />
| [[ECE497: Remote Web Cam Viewer Final Project| Remote Web Cam Viewer]]<br />
| [https://github.com/draneaw/ Draneaw]<br />
|-<br />
| [[User:duganje | Josh Dugan]]<br />
| [[Special:Contributions/duganje|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/duganje/ duganje]<br />
|-<br />
| [[User:Geislekj | Kevin Geisler]]<br />
| [[Special:Contributions/geislekj|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/geislekj/ geislekj]<br />
| <br />
|-<br />
| [[User:chris.good | Christopher A Good]]<br />
| [[Special:Contributions/Chris.good|contrib]]<br />
| [[ECE497 Project RoverGUI | RoverGUI]]<br />
| [https://github.com/goodca/ goodca]<br />
| <br />
|-<br />
| [[User:hansenrl | Ross Hansen]]<br />
| [[Special:Contributions/hansenrl|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/hansenrl/ Hansenrl]<br />
| <br />
|-<br />
| [[User:jungeml | Michael Junge]]<br />
| [[Special:Contributions/jungeml|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/jungeml/ Jungeml]<br />
|-<br />
| [[User:larmorgs | Greg Larmore]]<br />
| [[Special:Contributions/larmorgs|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/larmorgs Greg Larmore]<br />
|-<br />
| [[User:Lobdeljt | John Lobdell]]<br />
| <br />
| [[ECE 497 lobdeljt Project | My Beagle Project]]<br />
| [https://github.com/jtlobdell jtlobdell]<br />
|-<br />
| [[User:Lix | Xia Li]]<br />
| [[Special:Contributions/Lix|contrib]]<br />
| [[ECE497 Project: Kinect | Kinect]]<br />
| [https://github.com/1984xiali/ xiali]<br />
|-<br />
| [[User:Millerap | Andrew Miller]]<br />
| [[Special:Contributions/Millerap|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/millerap millerap]<br />
|-<br />
| [[User:mmoravec | Matthew Moravec]]<br />
| [[Special:Contributions/mmoravec|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/mmoravec/ mmoravec]<br />
|-<br />
| [[User:ngop | Peter Ngo]]<br />
| [[Special:Contributions/ngop|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/ngop/ ngop]<br />
|-<br />
| [[User:Popenhjc | James Popenhagen]]<br />
| [[Special:Contributions/Popenhjc|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/popenhjc/ popenhjc]<br />
|-<br />
| [[User:Richarsm | Sean Richardson]]<br />
| [[Special:Contributions/Richarsm|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/seanrich Sean Richardson]<br />
|-<br />
| [[User:shinnsm|Stephen Shinn]]<br />
| [[Special:Contributions/shinnsm|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/shinnsm shinnsm]<br />
|-<br />
| [[User:Whiteer | Elias White]]<br />
| <br />
| [[ECE497 SLAM via ROS | My Beagle Project]]<br />
| [https://github.com/whiteer whiteer]<br />
|-<br />
| [[User:ruff | Ruffin White]]<br />
| [[Special:Contributions/ruff|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/ruffsl/ ruffsl]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Astroricks | Yue Zhang]]<br />
| [[Special:Contributions/Astroricks | contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Yuming | Yuming Cao]]<br />
# [[Special:Contributions/Yifei | Yifei Li]]<br />
# [[Special:Contributions/Harrisgw | Greg Harrison]]<br />
# [[Special:Contributions/mac | Jack Ma]]<br />
# [[Special:Contributions/Gemini91 | Guanqun Wang]]<br />
# [[Special:Contributions/Yanj | Mona Yan]]<br />
# [[Special:Contributions/Yoder | Mark A. Yoder]]<br />
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]<br />
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]<br />
# [[Special:Contributions/Zitnikdj | David Zitnik]]<br />
# [[Special:Contributions/Zitnikdj | Alex Drane]]<br />
# [[Special:Contributions/jessebrannon | Jesse Brannon]]<br />
# [[Special:Contributions/larmorgs | Greg Larmore]]<br />
# [[Special:Contributions/jungeml | Michael Junge]]<br />
# [[Special:Contributions/millerap | Andrew Miller]]<br />
# [[Special:Contributions/correlbn | Bryan Correll]]<br />
<br />
=== Project Status ===<br />
<br />
# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]<br />
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]<br />
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]<br />
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]<br />
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]<br />
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]<br />
<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Project_Programmable_Light_Show&diff=293360ECE497 Project Programmable Light Show2013-10-22T11:34:44Z<p>Tpurviance: Created page with "Project Team members: Taylor Purviance == Executive Summary == The idea of this project is to have a bone controlling a chain of LE..."</p>
<hr />
<div>[[Category:ECE497 |Project]]<br />
<br />
Team members: [[user:Tpurviance|Taylor Purviance]]<br />
<br />
== Executive Summary ==<br />
<br />
The idea of this project is to have a bone controlling a chain of LEDs and drive the LEDs to flash different colors and patterns. The patterns and colors being displayed will be programmed via a web interface that is accessible to the public, allowing anyone to program the lights.<br />
<br />
At the moment, the project is still in the research/design phase, so there is nothing completed. Most of the effort is concentrated on deciding how to enable people to program via a web interface. Google's visual programming language, blockly, looks like a possible contender. <br />
<br />
I'm told that the hardware, an LED chain, already has some semblance of an interface created for the bone, so some portion of that work has already been done.<br />
<br />
== Packaging ==<br />
<br />
If you have hardware, consider [http://cpprojects.blogspot.com/2013/07/small-build-big-execuition.html Small Build, Big Execuition] for ideas on the final packaging.<br />
<br />
== Installation Instructions ==<br />
<br />
Give step by step instructions on how to install your project. <br />
<br />
* Include your [https://github.com/ github] path as a link like this to the read-only git site: [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn]. <br />
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.<br />
* Include a Makefile for you code.<br />
* Include any additional packages installed via '''opkg'''.<br />
* Include kernel mods.<br />
* If there is extra hardware needed, include links to where it can be obtained.<br />
<br />
== User Instructions ==<br />
<br />
Once everything is installed, how do you use the program? Give details here, so if you have a long user manual, link to it here.<br />
<br />
== Highlights ==<br />
<br />
Here is where you brag about what your project can do.<br />
<br />
Include a [http://www.youtube.com/ YouTube] demo.<br />
<br />
== Theory of Operation ==<br />
<br />
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.<br />
<br />
== Work Breakdown ==<br />
<br />
List the major tasks in your project and who did what.<br />
<br />
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.<br />
<br />
== Future Work ==<br />
<br />
Suggest addition things that could be done with this project.<br />
<br />
== Conclusions ==<br />
<br />
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Exercise_23_Configuring_the_Kernel&diff=291590EBC Exercise 23 Configuring the Kernel2013-10-11T19:10:13Z<p>Tpurviance: adding a check at the end for the newly installed kernel</p>
<hr />
<div>[[Category:ECE497]]<br />
[[Category:BeagleBoard]]<br />
{{YoderHead}}<br />
{{EBC3.8}}These instructions are for the 3.8 kernel. See [[EBC Exercise 23 Configuring the Kernel - bitbake]] for the 3.2 kernel.<br />
<br />
In a previous exercises ([[EBC Exercise 08a Cross-Compiling]] and [[EBC Exercise 08 Installing Development Tools]]) you learned how to get and compile the kernel. Here we'll look at configuring it.<br />
<br />
== Finding the kernel sources ==<br />
<br />
First set up the environment and go to the kernel directory<br />
<br />
host$ '''source ~/crossCompileEnv.sh''' (set up in [[EBC Exercise 08a Cross-Compiling]])<br />
host$ '''cd ~/BeagleBoard/linux-dev/KERNEL'''<br />
<br />
== Getting kernel make help ==<br />
Once there try some of the make commands. Help is a good place to start.<br />
<br />
host$ '''make help | less'''<br />
Cleaning targets:<br />
clean - Remove most generated files but keep the config and<br />
enough build support to build external modules<br />
mrproper - Remove all generated files + config + various backup files<br />
distclean - mrproper + remove editor backup and patch files<br />
<br />
Configuration targets:<br />
config - Update current config utilising a line-oriented program<br />
menuconfig - Update current config utilising a menu based program<br />
xconfig - Update current config utilising a QT based front-end<br />
gconfig - Update current config utilising a GTK based front-end<br />
...<br />
This produces a list of common make targets. <br />
<br />
== Finding and installing support software ==<br />
<br />
There are several ways to configure the kernel. '''make config''' will prompt you line-by-line for each of the settings, very tedious, not recommended. Try<br />
<br />
host$ '''make menuconfig'''<br />
*** Unable to find the ncurses libraries or the<br />
*** required header files.<br />
*** 'make menuconfig' requires the ncurses libraries.<br />
*** <br />
*** Install ncurses (ncurses-devel) and try again.<br />
*** <br />
make[1]: *** [scripts/kconfig/dochecklxdialog] Error 1<br />
make: *** [menuconfig] Error 2<br />
If you get the error above, you need to install the ncurses library. [[ECE497_Tips_and_Tricks#On_the_host | Here]] are notes on how to discover what to install and installing it.<br />
<br />
NOTE FOR UBUNTU USERS: 'sudo apt-get install libncurses5-dev' without quotes will install ncurses<br />
<br />
== Configuring the kernel ==<br />
<br />
Try the various interfaces for configuring the kernel.<br />
<br />
host$ '''make menuconfig'''<br />
host$ '''make xconfig'''<br />
host$ '''make gconfig'''<br />
<br />
I had to run the following to get these to work.<br />
host$ '''sudo apt-get install libncurses5-dev'''<br />
host$ '''sudo apt-get install qt3-dev-tools'''<br />
host$ '''sudo apt-get install libglade2-dev'''<br />
<br />
== Making and Installing the kernel ==<br />
Once you have the kernel configured it's easy to make and install it on the bone.<br />
host$ '''cd linux-dev'''<br />
host$ '''tools/rebuild.sh'''<br />
You'll be given a chance to configure, you can exit without saving if you don't want to change anything.<br />
<br />
After a while (depending on the number of cores) you will see.<br />
<br />
CHK include/generated/uapi/linux/version.h<br />
CHK include/generated/utsrelease.h<br />
make[1]: `include/generated/mach-types.h' is up to date.<br />
CALL scripts/checksyscalls.sh<br />
...<br />
LD [M] sound/usb/caiaq/snd-usb-caiaq.ko<br />
LD [M] sound/usb/misc/snd-ua101.ko<br />
LD [M] sound/usb/snd-usb-audio.ko<br />
LD [M] sound/usb/snd-usbmidi-lib.ko<br />
<br />
Now you are ready to install. Have your Bone running and on the network. On your host run:<br />
host$ '''cd linux-dev/tools'''<br />
host$ '''ln -s ../../exercises/setup/beagle_install_kernel.sh ../../exercises/setup/remote_install_kernel.sh .'''<br />
<br />
This will link in two files from the git repository that we'll use. Edit '''remote_install_kernel.sh''' and change '''BeagleAddr''' to the address of your beagle. Then run:<br />
host$ '''./remote_install_kernel.sh'''<br />
Image Name: 3.8.13-bone26.1<br />
Created: Tue Sep 3 13:33:35 2013<br />
Image Type: ARM Linux Kernel Image (uncompressed)<br />
Data Size: 3340904 Bytes = 3262.60 kB = 3.19 MB<br />
Load Address: 80008000<br />
Entry Point: 80008000<br />
utsrelease.h 100% 38 0.0KB/s 00:00 <br />
beagle_install_kernel.sh 100% 3043 3.0KB/s 00:00 <br />
version.sh 100% 915 0.9KB/s 00:00 <br />
system.sh 100% 1446 1.4KB/s 00:00 <br />
3.8.13-bone26.1.config 100% 107KB 106.5KB/s 00:00 <br />
uImage-3.8.13-bone26.1 100% 3263KB 1.6MB/s 00:02 <br />
3.8.13-bone26.1-firmware.tar.gz 100% 1198KB 1.2MB/s 00:00 <br />
3.8.13-bone26.1-dtbs.tar.gz 100% 33KB 32.7KB/s 00:00 <br />
3.8.13-bone26.1.zImage 100% 3263KB 1.1MB/s 00:03 <br />
3.8.13-bone26.1-modules.tar.gz 100% 11MB 5.7MB/s 00:02 <br />
<br />
This copies several files to your Bone. Then, on the Bone run:<br />
beagle$ '''cd linux-dev'''<br />
beagle$ '''tools/beagle_install.sh'''<br />
No manual entry for git-pull<br />
Installing 3.8.13-bone26.1-modules.tar.gz<br />
Installing 3.8.13-bone26.1-firmware.tar.gz<br />
`/home/root/linux-dev/deploy/tmp/BB-ADC-00A0.dtbo' -> `/home/root/linux-dev/deploy/disk/lib/firmware/BB-ADC-00A0.dtbo'<br />
...<br />
`/home/root/linux-dev/deploy/tmp/cape-bone-weather-00A0.dtbo' -> `/home/root/linux-dev/deploy/disk/lib/firmware/cape-bone-weather-00A0.dtbo'<br />
`/home/root/linux-dev/deploy/tmp/cape-boneblack-hdmi-00A0.dtbo' -> `/home/root/linux-dev/deploy/disk/lib/firmware/cape-boneblack-hdmi-00A0.dtbo'<br />
`/home/root/linux-dev/deploy/tmp/cape-boneblack-hdmin-00A0.dtbo' -> `/home/root/linux-dev/deploy/disk/lib/firmware/cape-boneblack-hdmin-00A0.dtbo'<br />
<br />
This uncompresses and installs the modules and firmware. You are now ready to reboot.<br />
beagle$ '''reboot'''<br />
<br />
If you Bone boots up and you can reconnect to it, you can verify that you are running the new kernel by running:<br />
beagle$ '''uname -a'''<br />
<br />
== Recovering ==<br />
If your Beagle fails to boot, follow the [[EBC_Exercise_22_Recovering]] instructions to recover.<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Contributions_and_Project_Status&diff=291386EBC Contributions and Project Status2013-10-10T19:20:27Z<p>Tpurviance: /* Contributions */</p>
<hr />
<div>[[Category:ECE497 |Contributions]]<br />
{{YoderHead}}<br />
<br />
== Fall 2013 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:amesen | Eric Ames]]<br />
| [[Special:Contributions/amesen | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/Guiltygate/beaglebone-classwork classwork]<br />
|-<br />
| [[User:fendrirj | Robert Fendricks]]<br />
| [[Special:Contributions/fendrirj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/Fendrirj/ECE497 classwork]<br />
|-<br />
| [[User:elswicwj | Will Elswick]]<br />
| [[Special:Contributions/elswicwj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/elswicwj/ECE497.git classwork]<br />
|-<br />
| [[User:savrdada | David Savrda]]<br />
| [[Special:Contributions/savrdada| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/muglump/BeagleBoneHomework BeagleBoneRepo]<br />
| <br />
|-<br />
| [[User:skorinm | Matt Skorina]]<br />
| [[Special:Contributions/skorinm| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/skorinm/Homework Homework]<br />
|-<br />
| [[User:Yuxuan | Yuxuan Zeng]]<br />
| [[Special:Contributions/zeng| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/yuxuanzeng classwork]<br />
|-<br />
| [[User:Mcdonamp | Mike McDonald]]<br />
| [[Special:Contributions/mcdonamp| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/mcdonamp/497Homework 497Homework]<br />
|-<br />
| [[User:Kowalsif | Ian Kowalski]]<br />
| [[Special:Contributions/kowalsif| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/kowalsif/Beagle BeagleCode]<br />
|-<br />
| [[User:daniel.hou | Junxuan Hou]]<br />
| [[Special:Contributions/hou| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/houj/Homework.git Classwork]<br />
|-<br />
| [[User:Andrewca | Chris Andrews]]<br />
| [[Special:Contributions/Andrewca| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Rockybulwinkle | Chris Hopwood]]<br />
| [[Special:Contributions/Rockybulwinkle| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/rockybulwinkle/beaglebone/ Classwork]<br />
|-<br />
| [[User:FreeTymeKiyan | Yang Liu]]<br />
| [[Special:Contributions/FreeTymeKiyan | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/FreeTymeKiyan/EmbeddedLinux.git FreeTymeKiyan]<br />
|-<br />
| [[User:Cooperdl | David Cooper]]<br />
| [[Special:Contributions/Cooperdl | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/cooperdl/Classwork Classwork]<br />
|-<br />
| [[User:Alvareap | Alex Alvarez]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/alvareap/classwork classwork ]<br />
|-<br />
| [[User:Alvareap | Zhen Wei]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/weizhen1883/homework.git HomeWork]<br />
|-<br />
|-<br />
| [[User:Manuel | Manuel Stephan]]<br />
| [[Special:Contributions/Manuel | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/manuelstephan/homework Homework]<br />
|-<br />
|-<br />
| [[User:Parasby| Ben Paras]]<br />
| [[Special:Contributions/Parasby | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/parasby2014/ECE497---Embedded-Linux ECE497HW]<br />
|-<br />
|-<br />
| [[User:Axiixc| James Savage]]<br />
| [[Special:Contributions/Axiixc | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/axiixc/ece497 axiixc/ece497]<br />
|-<br />
|-<br />
| [[User:Tpurviance| Taylor Purviance]]<br />
| [[Special:Contributions/Tpurviance | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/tpurviance/E32bL Homework]<br />
|-<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:atniptw | Tom Atnip]]<br />
| [[Special:Contributions/atniptw|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/atniptw/ atniptw]<br />
|-<br />
| [[User:jessebrannon | Jesse Brannon]]<br />
| [[Special:Contributions/Jessebrannon|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/brannojs/ brannojs]<br />
|-<br />
| [[User:Xinyu1991 | Xinyu Cheng]]<br />
| [[Special:Contributions/Xinyu1991|contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/xinyu1991/ Xinyu Cheng]<br />
|-<br />
| [[User:correlbn | Bryan Correll]]<br />
| [[Special:Contributions/correlbn|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]<br />
|-<br />
| [[User:draneaw | Alex Drane]]<br />
| [[Special:Contributions/draneaw|contrib]]<br />
| [[ECE497: Remote Web Cam Viewer Final Project| Remote Web Cam Viewer]]<br />
| [https://github.com/draneaw/ Draneaw]<br />
|-<br />
| [[User:duganje | Josh Dugan]]<br />
| [[Special:Contributions/duganje|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/duganje/ duganje]<br />
|-<br />
| [[User:Geislekj | Kevin Geisler]]<br />
| [[Special:Contributions/geislekj|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/geislekj/ geislekj]<br />
| <br />
|-<br />
| [[User:chris.good | Christopher A Good]]<br />
| [[Special:Contributions/Chris.good|contrib]]<br />
| [[ECE497 Project RoverGUI | RoverGUI]]<br />
| [https://github.com/goodca/ goodca]<br />
| <br />
|-<br />
| [[User:hansenrl | Ross Hansen]]<br />
| [[Special:Contributions/hansenrl|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/hansenrl/ Hansenrl]<br />
| <br />
|-<br />
| [[User:jungeml | Michael Junge]]<br />
| [[Special:Contributions/jungeml|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/jungeml/ Jungeml]<br />
|-<br />
| [[User:larmorgs | Greg Larmore]]<br />
| [[Special:Contributions/larmorgs|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/larmorgs Greg Larmore]<br />
|-<br />
| [[User:Lobdeljt | John Lobdell]]<br />
| <br />
| [[ECE 497 lobdeljt Project | My Beagle Project]]<br />
| [https://github.com/jtlobdell jtlobdell]<br />
|-<br />
| [[User:Lix | Xia Li]]<br />
| [[Special:Contributions/Lix|contrib]]<br />
| [[ECE497 Project: Kinect | Kinect]]<br />
| [https://github.com/1984xiali/ xiali]<br />
|-<br />
| [[User:Millerap | Andrew Miller]]<br />
| [[Special:Contributions/Millerap|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/millerap millerap]<br />
|-<br />
| [[User:mmoravec | Matthew Moravec]]<br />
| [[Special:Contributions/mmoravec|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/mmoravec/ mmoravec]<br />
|-<br />
| [[User:ngop | Peter Ngo]]<br />
| [[Special:Contributions/ngop|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/ngop/ ngop]<br />
|-<br />
| [[User:Popenhjc | James Popenhagen]]<br />
| [[Special:Contributions/Popenhjc|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/popenhjc/ popenhjc]<br />
|-<br />
| [[User:Richarsm | Sean Richardson]]<br />
| [[Special:Contributions/Richarsm|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/seanrich Sean Richardson]<br />
|-<br />
| [[User:shinnsm|Stephen Shinn]]<br />
| [[Special:Contributions/shinnsm|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/shinnsm shinnsm]<br />
|-<br />
| [[User:Whiteer | Elias White]]<br />
| <br />
| [[ECE497 SLAM via ROS | My Beagle Project]]<br />
| [https://github.com/whiteer whiteer]<br />
|-<br />
| [[User:ruff | Ruffin White]]<br />
| [[Special:Contributions/ruff|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/ruffsl/ ruffsl]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Astroricks | Yue Zhang]]<br />
| [[Special:Contributions/Astroricks | contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Yuming | Yuming Cao]]<br />
# [[Special:Contributions/Yifei | Yifei Li]]<br />
# [[Special:Contributions/Harrisgw | Greg Harrison]]<br />
# [[Special:Contributions/mac | Jack Ma]]<br />
# [[Special:Contributions/Gemini91 | Guanqun Wang]]<br />
# [[Special:Contributions/Yanj | Mona Yan]]<br />
# [[Special:Contributions/Yoder | Mark A. Yoder]]<br />
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]<br />
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]<br />
# [[Special:Contributions/Zitnikdj | David Zitnik]]<br />
# [[Special:Contributions/Zitnikdj | Alex Drane]]<br />
# [[Special:Contributions/jessebrannon | Jesse Brannon]]<br />
# [[Special:Contributions/larmorgs | Greg Larmore]]<br />
# [[Special:Contributions/jungeml | Michael Junge]]<br />
# [[Special:Contributions/millerap | Andrew Miller]]<br />
# [[Special:Contributions/correlbn | Bryan Correll]]<br />
<br />
=== Project Status ===<br />
<br />
# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]<br />
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]<br />
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]<br />
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]<br />
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]<br />
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]<br />
<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Contributions_and_Project_Status&diff=291380EBC Contributions and Project Status2013-10-10T18:30:25Z<p>Tpurviance: /* Project Status */</p>
<hr />
<div>[[Category:ECE497 |Contributions]]<br />
{{YoderHead}}<br />
<br />
== Fall 2013 ==<br />
<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Parasby | Taylor Purviance]]<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:amesen | Eric Ames]]<br />
| [[Special:Contributions/amesen | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/Guiltygate/beaglebone-classwork classwork]<br />
|-<br />
| [[User:fendrirj | Robert Fendricks]]<br />
| [[Special:Contributions/fendrirj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/Fendrirj/ECE497 classwork]<br />
|-<br />
| [[User:elswicwj | Will Elswick]]<br />
| [[Special:Contributions/elswicwj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/elswicwj/ECE497.git classwork]<br />
|-<br />
| [[User:savrdada | David Savrda]]<br />
| [[Special:Contributions/savrdada| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/muglump/BeagleBoneHomework BeagleBoneRepo]<br />
| <br />
|-<br />
| [[User:skorinm | Matt Skorina]]<br />
| [[Special:Contributions/skorinm| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/skorinm/Homework Homework]<br />
|-<br />
| [[User:Yuxuan | Yuxuan Zeng]]<br />
| [[Special:Contributions/zeng| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/yuxuanzeng classwork]<br />
|-<br />
| [[User:Mcdonamp | Mike McDonald]]<br />
| [[Special:Contributions/mcdonamp| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/mcdonamp/497Homework 497Homework]<br />
|-<br />
| [[User:Kowalsif | Ian Kowalski]]<br />
| [[Special:Contributions/kowalsif| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/kowalsif/Beagle BeagleCode]<br />
|-<br />
| [[User:daniel.hou | Junxuan Hou]]<br />
| [[Special:Contributions/hou| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/houj/Homework.git Classwork]<br />
|-<br />
| [[User:Andrewca | Chris Andrews]]<br />
| [[Special:Contributions/Andrewca| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Rockybulwinkle | Chris Hopwood]]<br />
| [[Special:Contributions/Rockybulwinkle| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/rockybulwinkle/beaglebone/ Classwork]<br />
|-<br />
| [[User:FreeTymeKiyan | Yang Liu]]<br />
| [[Special:Contributions/FreeTymeKiyan | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/FreeTymeKiyan/EmbeddedLinux.git FreeTymeKiyan]<br />
|-<br />
| [[User:Cooperdl | David Cooper]]<br />
| [[Special:Contributions/Cooperdl | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/cooperdl/Classwork Classwork]<br />
|-<br />
| [[User:Alvareap | Alex Alvarez]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/alvareap/classwork classwork ]<br />
|-<br />
| [[User:Alvareap | Zhen Wei]]<br />
| [[Special:Contributions/Alvareap | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/weizhen1883/homework.git HomeWork]<br />
|-<br />
|-<br />
| [[User:Manuel | Manuel Stephan]]<br />
| [[Special:Contributions/Manuel | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/manuelstephan/homework Homework]<br />
|-<br />
|-<br />
| [[User:Parasby| Ben Paras]]<br />
| [[Special:Contributions/Parasby | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/parasby2014/ECE497---Embedded-Linux ECE497HW]<br />
|-<br />
|-<br />
| [[User:Axiixc| James Savage]]<br />
| [[Special:Contributions/Axiixc | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/axiixc/ece497 axiixc/ece497]<br />
|-<br />
|-<br />
| [[User:Tpurviance| Taylor Purviance]]<br />
| [[Special:Contributions/Tpurviance | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| [https://github.com/tpurviance/E32bL Homework]<br />
|-<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:atniptw | Tom Atnip]]<br />
| [[Special:Contributions/atniptw|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/atniptw/ atniptw]<br />
|-<br />
| [[User:jessebrannon | Jesse Brannon]]<br />
| [[Special:Contributions/Jessebrannon|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/brannojs/ brannojs]<br />
|-<br />
| [[User:Xinyu1991 | Xinyu Cheng]]<br />
| [[Special:Contributions/Xinyu1991|contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/xinyu1991/ Xinyu Cheng]<br />
|-<br />
| [[User:correlbn | Bryan Correll]]<br />
| [[Special:Contributions/correlbn|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]<br />
|-<br />
| [[User:draneaw | Alex Drane]]<br />
| [[Special:Contributions/draneaw|contrib]]<br />
| [[ECE497: Remote Web Cam Viewer Final Project| Remote Web Cam Viewer]]<br />
| [https://github.com/draneaw/ Draneaw]<br />
|-<br />
| [[User:duganje | Josh Dugan]]<br />
| [[Special:Contributions/duganje|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/duganje/ duganje]<br />
|-<br />
| [[User:Geislekj | Kevin Geisler]]<br />
| [[Special:Contributions/geislekj|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/geislekj/ geislekj]<br />
| <br />
|-<br />
| [[User:chris.good | Christopher A Good]]<br />
| [[Special:Contributions/Chris.good|contrib]]<br />
| [[ECE497 Project RoverGUI | RoverGUI]]<br />
| [https://github.com/goodca/ goodca]<br />
| <br />
|-<br />
| [[User:hansenrl | Ross Hansen]]<br />
| [[Special:Contributions/hansenrl|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/hansenrl/ Hansenrl]<br />
| <br />
|-<br />
| [[User:jungeml | Michael Junge]]<br />
| [[Special:Contributions/jungeml|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/jungeml/ Jungeml]<br />
|-<br />
| [[User:larmorgs | Greg Larmore]]<br />
| [[Special:Contributions/larmorgs|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/larmorgs Greg Larmore]<br />
|-<br />
| [[User:Lobdeljt | John Lobdell]]<br />
| <br />
| [[ECE 497 lobdeljt Project | My Beagle Project]]<br />
| [https://github.com/jtlobdell jtlobdell]<br />
|-<br />
| [[User:Lix | Xia Li]]<br />
| [[Special:Contributions/Lix|contrib]]<br />
| [[ECE497 Project: Kinect | Kinect]]<br />
| [https://github.com/1984xiali/ xiali]<br />
|-<br />
| [[User:Millerap | Andrew Miller]]<br />
| [[Special:Contributions/Millerap|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/millerap millerap]<br />
|-<br />
| [[User:mmoravec | Matthew Moravec]]<br />
| [[Special:Contributions/mmoravec|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/mmoravec/ mmoravec]<br />
|-<br />
| [[User:ngop | Peter Ngo]]<br />
| [[Special:Contributions/ngop|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/ngop/ ngop]<br />
|-<br />
| [[User:Popenhjc | James Popenhagen]]<br />
| [[Special:Contributions/Popenhjc|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/popenhjc/ popenhjc]<br />
|-<br />
| [[User:Richarsm | Sean Richardson]]<br />
| [[Special:Contributions/Richarsm|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/seanrich Sean Richardson]<br />
|-<br />
| [[User:shinnsm|Stephen Shinn]]<br />
| [[Special:Contributions/shinnsm|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/shinnsm shinnsm]<br />
|-<br />
| [[User:Whiteer | Elias White]]<br />
| <br />
| [[ECE497 SLAM via ROS | My Beagle Project]]<br />
| [https://github.com/whiteer whiteer]<br />
|-<br />
| [[User:ruff | Ruffin White]]<br />
| [[Special:Contributions/ruff|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/ruffsl/ ruffsl]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Astroricks | Yue Zhang]]<br />
| [[Special:Contributions/Astroricks | contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Yuming | Yuming Cao]]<br />
# [[Special:Contributions/Yifei | Yifei Li]]<br />
# [[Special:Contributions/Harrisgw | Greg Harrison]]<br />
# [[Special:Contributions/mac | Jack Ma]]<br />
# [[Special:Contributions/Gemini91 | Guanqun Wang]]<br />
# [[Special:Contributions/Yanj | Mona Yan]]<br />
# [[Special:Contributions/Yoder | Mark A. Yoder]]<br />
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]<br />
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]<br />
# [[Special:Contributions/Zitnikdj | David Zitnik]]<br />
# [[Special:Contributions/Zitnikdj | Alex Drane]]<br />
# [[Special:Contributions/jessebrannon | Jesse Brannon]]<br />
# [[Special:Contributions/larmorgs | Greg Larmore]]<br />
# [[Special:Contributions/jungeml | Michael Junge]]<br />
# [[Special:Contributions/millerap | Andrew Miller]]<br />
# [[Special:Contributions/correlbn | Bryan Correll]]<br />
<br />
=== Project Status ===<br />
<br />
# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]<br />
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]<br />
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]<br />
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]<br />
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]<br />
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]<br />
<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=User:Tpurviance&diff=285392User:Tpurviance2013-09-10T18:35:53Z<p>Tpurviance: </p>
<hr />
<div>Computer Science major at Rose-Hulman Institute of Technology.<br />
<br />
== Handy Links ==<br />
* [https://docs.google.com/document/d/1SJL2_0Fc8yXHZZ3AVWREOHfK7jfidzBHG-lVuYfif9k/edit Course Calendar]<br />
* [http://192.168.7.2 Connect To Beagle Board]<br />
* [https://groups.google.com/forum/#!forum/beagleboard-ece497 Class Google Group]<br />
<br />
[[Category:ECE497 |U]]</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Editing_a_Wiki&diff=284270EBC Editing a Wiki2013-09-06T17:55:01Z<p>Tpurviance: /* Fall 2013 */</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
<br />
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.<br />
<br />
You can get help here: [[Help:Contents]].<br />
<br />
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].<br />
<br />
== Fall 2013 ==<br />
<br />
{|<br />
|-<br />
| [[user:amesen | Eric Ames]]<br />
| 13-June-2013<br />
|-<br />
| [[user:fendrirj | Robert Fendricks]]<br />
| 5-September-2013<br />
|-<br />
| [[user:elswicwj | Will Elswick]]<br />
| 5-September-2013<br />
|-<br />
| [[user:savrdada | David Savrda]]<br />
| 5-September-2013<br />
|-<br />
| [[user:skorinm | Matt Skorina]]<br />
| 6-September-2013<br />
|-<br />
| [[user:Parasby | Ben Paras]]<br />
| 6-September-2013<br />
|-<br />
| [[user:Yuxuan | Yuxuan Zeng]]<br />
| 5-September-2013<br />
|-<br />
| [[user:Mcdonamp | Mike McDonald]]<br />
| 5-September-2013<br />
|-<br />
| [[user:Kowalsif | Ian Kowalski]]<br />
| 5-September-2013<br />
|-<br />
| [[user:daniel.hou | Junxuan Hou]]<br />
| 5-September-2013<br />
|-<br />
| [[user:Andrewca | Chris Andrews]]<br />
| 5-September-2013<br />
|-<br />
| [[user:Rockybulwinkle | Chris Hopwood]]<br />
| 6-September-2013<br />
|-<br />
| [[user:Tpurviance | Taylor Purviance]]<br />
| 6-September-2013<br />
|-<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
{|<br />
|-<br />
| [[user:Yoder | Mark A. Yoder]]<br />
| 18-July-2012<br />
|-<br />
| [[user:atniptw | Tom Atnip]]<br />
| 20-July-2012<br />
|-<br />
| [[user:Xinyu1991 | Xinyu Cheng]]<br />
| 31-August-2012<br />
|-<br />
| [[user:bssachin45 | B S Sachin]]<br />
| 25-July-2012<br />
|-<br />
| [[user:ruff | Ruffin White]]<br />
| 16-August-2012<br />
|-<br />
| [[user:Popenhjc | James Popenhagen]]<br />
| 30-August-2012<br />
|-<br />
| [[user:mmoravec | Matthew Moravec]]<br />
| 30-August-2012<br />
|-<br />
| [[user:ngop | Peter Ngo]]<br />
| 30-August-2012<br />
|-<br />
| [[user:duganje | Josh Dugan]]<br />
| 30-August-2012<br />
|-<br />
| [[user:hansenrl | Ross Hansen]]<br />
| 30-August-2012<br />
|-<br />
| [[user:jungeml | Michael Junge]]<br />
| 05-September-2012<br />
|- <br />
| [[User:shinnsm|Stephen Shinn]]<br />
| 30-August-2012<br />
|-<br />
| [[User:draneaw|Alex Drane]]<br />
| 30-August-2012<br />
|-<br />
| [[User:larmorgs|Greg Larmore]]<br />
| 31-August-2012<br />
|-<br />
| [[User:jessebrannon|Jesse Brannon]]<br />
| 31-August-2012<br />
|-<br />
| [[User:lix|Xia Li]]<br />
| 31-August-2012<br />
|-<br />
| [[User:whiteer|Elias White]]<br />
| 31-August-2012<br />
|-<br />
| [[User:Astroricks|Yue Zhang]]<br />
| 31-August-2012<br />
|-<br />
| [[User:millerap|Andrew Miller]]<br />
| 31-August-2012<br />
|-<br />
| [[user:Geislekj | Kevin Geisler]]<br />
| 1-September-2012<br />
|-<br />
| [[user:chris.good | Christopher A Good]]<br />
| 3-September-2012<br />
|-<br />
| [[user:Lobdeljt | John Lobdell]]<br />
| 5-November-2012<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
{|<br />
|-<br />
| [[user:Yoder | Mark A. Yoder]]<br />
| 21-Nov-2011<br />
|-<br />
| [[user:Yuming | Yuming Cao]]<br />
| 21-Nov-2011<br />
|-<br />
| [[user:Yuhasmj | Michael Yuhas]]<br />
| 21-Nov-2011<br />
|-<br />
| [[user:Yifei | Yifei Li]]<br />
| 22-Nov-2011<br />
|-<br />
| [[user:Ziyi Zhang | Ziyi Zhang]]<br />
| 24-Nov-2011<br />
|-<br />
|[[user: mac | Jack Ma]]<br />
| 28-Nov-2011<br />
|-<br />
| [[user:Zitnikdj | David Zitnik]]<br />
| 25-Nov-2011<br />
|-<br />
| [[user:Harrisgw | Greg Harrison]]<br />
| 26-Nov-2011<br />
|-<br />
| [[user:Yanj | Mona J Yan]]<br />
| 27-Nov-2011<br />
|-<br />
| [[user:Gemini91 | Guanqun Wang]]<br />
| 28-Nov-2011<br />
|-<br />
| [[user:vsn1985 | Narayanan VS]]<br />
| 28-Nov-2011<br />
|}<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=User:Tpurviance&diff=284264User:Tpurviance2013-09-06T17:29:40Z<p>Tpurviance: /* Handy Links */</p>
<hr />
<div>Computer Science major at Rose-Hulman Institute of Technology.<br />
<br />
== Handy Links ==<br />
* [https://docs.google.com/document/d/1SJL2_0Fc8yXHZZ3AVWREOHfK7jfidzBHG-lVuYfif9k/edit Course Calendar]<br />
* [http://192.168.7.2 Connect To Beagle Board]<br />
* [https://groups.google.com/forum/#!forum/beagleboard-ece497 Class Google Group]<br />
<br />
[[Category:ECE497]]</div>Tpurviancehttps://elinux.org/index.php?title=User:Tpurviance&diff=284258User:Tpurviance2013-09-06T17:28:13Z<p>Tpurviance: </p>
<hr />
<div>Computer Science major at Rose-Hulman Institute of Technology.<br />
<br />
== Handy Links ==<br />
* [https://docs.google.com/document/d/1SJL2_0Fc8yXHZZ3AVWREOHfK7jfidzBHG-lVuYfif9k/edit Course Calendar]<br />
* [192.168.7.2 Connect To Beagle Board]<br />
* [https://groups.google.com/forum/#!forum/beagleboard-ece497 Class Google Group]<br />
<br />
[[Category:ECE497]]</div>Tpurviancehttps://elinux.org/index.php?title=User:Tpurviance&diff=284252User:Tpurviance2013-09-06T17:23:19Z<p>Tpurviance: </p>
<hr />
<div>Computer Science major at Rose-Hulman Institute of Technology.<br />
<br />
[[Category:ECE497]]</div>Tpurviancehttps://elinux.org/index.php?title=EBC_Contributions_and_Project_Status&diff=284228EBC Contributions and Project Status2013-09-06T16:55:55Z<p>Tpurviance: /* Contributions */</p>
<hr />
<div>[[Category:ECE497 |Contributions]]<br />
{{YoderHead}}<br />
<br />
== Fall 2013 ==<br />
<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Parasby | Ben Paras]]<br />
# [[Special:Contributions/Parasby | Taylor Purviance]]<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:amesen | Eric Ames]]<br />
| [[Special:Contributions/amesen | contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:fendrirj | Robert Fendricks]]<br />
| [[Special:Contributions/fendrirj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:elswicwj | Will Elswick]]<br />
| [[Special:Contributions/elswicwj| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:savrdada | David Savrda]]<br />
| [[Special:Contributions/savrdada| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:skorinm | Matt Skorina]]<br />
| [[Special:Contributions/skorinm| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Yuxuan | Yuxuan Zeng]]<br />
| [[Special:Contributions/zeng| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Mcdonamp | Mike McDonald]]<br />
| [[Special:Contributions/mcdonamp| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Kowalsif | Ian Kowalski]]<br />
| [[Special:Contributions/kowalsif| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:daniel.hou | Junxuan Hou]]<br />
| [[Special:Contributions/hou| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Andrewca | Chris Andrews]]<br />
| [[Special:Contributions/Andrewca| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|-<br />
| [[User:Rockybulwinkle | Chris Hopwood]]<br />
| [[Special:Contributions/Rockybulwinkle| contrib]]<br />
| [[ECE497 Project Template | TBD]]<br />
| TBD<br />
|}<br />
<br />
== Fall 2012 ==<br />
<br />
<br />
=== Project Status ===<br />
<br />
Please edit this page and add your project to this list.<br />
Please make the list alphabetical by family name.<br />
<br />
Take a look at what you and others have contributed.<br />
<br />
{|<br />
|- <br />
! Name<br />
! Contributions<br />
! Project<br />
! git repository<br />
|-<br />
| [[User:atniptw | Tom Atnip]]<br />
| [[Special:Contributions/atniptw|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/atniptw/ atniptw]<br />
|-<br />
| [[User:jessebrannon | Jesse Brannon]]<br />
| [[Special:Contributions/Jessebrannon|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/brannojs/ brannojs]<br />
|-<br />
| [[User:Xinyu1991 | Xinyu Cheng]]<br />
| [[Special:Contributions/Xinyu1991|contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/xinyu1991/ Xinyu Cheng]<br />
|-<br />
| [[User:correlbn | Bryan Correll]]<br />
| [[Special:Contributions/correlbn|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/correlbn/My-Beagle-Project/ Correlbn]<br />
|-<br />
| [[User:draneaw | Alex Drane]]<br />
| [[Special:Contributions/draneaw|contrib]]<br />
| [[ECE497: Remote Web Cam Viewer Final Project| Remote Web Cam Viewer]]<br />
| [https://github.com/draneaw/ Draneaw]<br />
|-<br />
| [[User:duganje | Josh Dugan]]<br />
| [[Special:Contributions/duganje|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/duganje/ duganje]<br />
|-<br />
| [[User:Geislekj | Kevin Geisler]]<br />
| [[Special:Contributions/geislekj|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/geislekj/ geislekj]<br />
| <br />
|-<br />
| [[User:chris.good | Christopher A Good]]<br />
| [[Special:Contributions/Chris.good|contrib]]<br />
| [[ECE497 Project RoverGUI | RoverGUI]]<br />
| [https://github.com/goodca/ goodca]<br />
| <br />
|-<br />
| [[User:hansenrl | Ross Hansen]]<br />
| [[Special:Contributions/hansenrl|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/hansenrl/ Hansenrl]<br />
| <br />
|-<br />
| [[User:jungeml | Michael Junge]]<br />
| [[Special:Contributions/jungeml|contrib]]<br />
| [[ECE497 Project Rover | Rover]]<br />
| [https://github.com/jungeml/ Jungeml]<br />
|-<br />
| [[User:larmorgs | Greg Larmore]]<br />
| [[Special:Contributions/larmorgs|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/larmorgs Greg Larmore]<br />
|-<br />
| [[User:Lobdeljt | John Lobdell]]<br />
| <br />
| [[ECE 497 lobdeljt Project | My Beagle Project]]<br />
| [https://github.com/jtlobdell jtlobdell]<br />
|-<br />
| [[User:Lix | Xia Li]]<br />
| [[Special:Contributions/Lix|contrib]]<br />
| [[ECE497 Project: Kinect | Kinect]]<br />
| [https://github.com/1984xiali/ xiali]<br />
|-<br />
| [[User:Millerap | Andrew Miller]]<br />
| [[Special:Contributions/Millerap|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/millerap millerap]<br />
|-<br />
| [[User:mmoravec | Matthew Moravec]]<br />
| [[Special:Contributions/mmoravec|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/mmoravec/ mmoravec]<br />
|-<br />
| [[User:ngop | Peter Ngo]]<br />
| [[Special:Contributions/ngop|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/ngop/ ngop]<br />
|-<br />
| [[User:Popenhjc | James Popenhagen]]<br />
| [[Special:Contributions/Popenhjc|contrib]]<br />
| [[BeagleBone PRU | BeagleBone PRU]]<br />
| [https://github.com/popenhjc/ popenhjc]<br />
|-<br />
| [[User:Richarsm | Sean Richardson]]<br />
| [[Special:Contributions/Richarsm|contrib]]<br />
| [[ECE497 SPI Project | SPI Project]]<br />
| [https://github.com/seanrich Sean Richardson]<br />
|-<br />
| [[User:shinnsm|Stephen Shinn]]<br />
| [[Special:Contributions/shinnsm|contrib]]<br />
| [[ECE497 Project: XBee|XBee]]<br />
| [https://github.com/shinnsm shinnsm]<br />
|-<br />
| [[User:Whiteer | Elias White]]<br />
| <br />
| [[ECE497 SLAM via ROS | My Beagle Project]]<br />
| [https://github.com/whiteer whiteer]<br />
|-<br />
| [[User:ruff | Ruffin White]]<br />
| [[Special:Contributions/ruff|contrib]]<br />
| [[ECE497 Beagle VNS | Beagle VNS]]<br />
| [https://github.com/ruffsl/ ruffsl]<br />
|-<br />
| [[User:Yoder | Mark A. Yoder]]<br />
| [[Special:Contributions/Yoder | contrib]]<br />
| [[ECE497 Project Template | My Beagle Project]]<br />
| [https://github.com/MarkAYoder MarkAYoder]<br />
|-<br />
| [[User:Astroricks | Yue Zhang]]<br />
| [[Special:Contributions/Astroricks | contrib]]<br />
| [[ECE497_Project:_Kinect | Kinect]]<br />
| [https://github.com/Astroricks/Beagle-Project Yue Zhang]<br />
|}<br />
<br />
== Winter 2011-2012 ==<br />
<br />
=== Contributions ===<br />
<br />
# [[Special:Contributions/Yuming | Yuming Cao]]<br />
# [[Special:Contributions/Yifei | Yifei Li]]<br />
# [[Special:Contributions/Harrisgw | Greg Harrison]]<br />
# [[Special:Contributions/mac | Jack Ma]]<br />
# [[Special:Contributions/Gemini91 | Guanqun Wang]]<br />
# [[Special:Contributions/Yanj | Mona Yan]]<br />
# [[Special:Contributions/Yoder | Mark A. Yoder]]<br />
# [[Special:Contributions/Yuhasmj | Michael Yuhas]]<br />
# [[Special:Contributions/Ziyi Zhang | Ziyi Zhang]]<br />
# [[Special:Contributions/Zitnikdj | David Zitnik]]<br />
# [[Special:Contributions/Zitnikdj | Alex Drane]]<br />
# [[Special:Contributions/jessebrannon | Jesse Brannon]]<br />
# [[Special:Contributions/larmorgs | Greg Larmore]]<br />
# [[Special:Contributions/jungeml | Michael Junge]]<br />
# [[Special:Contributions/millerap | Andrew Miller]]<br />
# [[Special:Contributions/correlbn | Bryan Correll]]<br />
<br />
=== Project Status ===<br />
<br />
# [[User:Yoder | Mark A. Yoder]], [[ECE497 Project Template | My Beagle Project]]<br />
# [[user:Yanj|Mona Yan]] and [[user:Harrisgw| Greg Harrison]], [[PS EYE QT PROJECT | Playstation Eye Audio with Qt]]<br />
# [[user:Caogecym | Yuming Cao]] and [[user:Ziyi Zhang | Ziyi Zhang]], [[Node.js Weather Station]]<br />
# [[user:Yifei| Yifei Li]] and [[user:Gemini91| Guanqun Wang]], [[ Kinect Project | Play games using Kinect on Beagleboard]]<br />
# [[user:Yuhasmj| Michael J. Yuhas]] and [[user:mac | Jack Ma]], [[ Multiple Partitions via U-boot | Multiple Partitions via U-boot ]]<br />
# [[user:Zitnikdj| David Zitnik]], [[ ECE497 Project: Twitter Java Application | Twitter Java Application ]]<br />
<br />
<br />
{{YoderFoot}}</div>Tpurviancehttps://elinux.org/index.php?title=ECE497_Signup&diff=247124ECE497 Signup2013-04-29T18:24:06Z<p>Tpurviance: Added myself to the list of those interested</p>
<hr />
<div>[[Category:ECE497]]<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| style="color:green; background-color:#ffffcc;" cellpadding="10" cellspacing="0" border="1"<br />
! Name<br />
! Major<br />
! Year<br />
! Have you had an OS class? Which one(s)?<br />
! Have you had an embedded class? Which one(s)?<br />
! Linux experience<br />
<br />
0 = What's Linux<br />
<br />
5 = Used it in OS<br />
<br />
10 = Written Drivers<br />
! Open Source Experience<br />
|-<br />
| Mark A. Yoder<br />
| ECE<br />
| Faculty<br />
| Yes<br />
| Yes<br />
| 9<br />
| Much<br />
|- <br />
| Ian F. Kowalski<br />
| Computer Engineer<br />
| jr (senior at start of next year)<br />
| yes, operating systems<br />
| yes, embedded design<br />
| 5<br />
|minimal<br />
|- <br />
| Will Elswick<br />
| Computer Engineer<br />
| Junior (senior next year)<br />
| Yes, CSSE332<br />
| Yes, ECE331<br />
| 5<br />
| Minimal<br />
|- <br />
| Matt Skorina<br />
| Electrical Engineer<br />
| Junior<br />
| No<br />
| ECE230<br />
| 6<br />
| Some<br />
|- <br />
| Eric Ames <br />
| Computer Engineer<br />
| Junior (going to senior)<br />
| Yes, CSSE332<br />
| No<br />
| 6<br />
| Moderate<br />
|- <br />
| David Savrda<br />
| Computer Science and Software Engineer<br />
| Junior (going to senior)<br />
| Yes, CSSE332<br />
| No<br />
| 6<br />
| Some<br />
|- <br />
| Robert Fendricks<br />
| Computer Engineering<br />
| Junior (Going to be a Senior)<br />
| Yes, CSSE332<br />
| Yes, ECE331<br />
| 6<br />
| Minimal<br />
|- <br />
| James Savage<br />
| Computer Science / Software Engineering<br />
| Junior (Going to be a Senior)<br />
| Yes, CSSE332<br />
| No<br />
| 7<br />
| Moderate<br />
|-<br />
| Taylor Purviance<br />
| Computer Science <br />
| Junior (Going to be a Senior)<br />
| Yes, CSSE332<br />
| No<br />
| 7<br />
| Moderate<br />
|-<br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
|<br />
|}</div>Tpurviance