I'm one of the authors (I contributed 2 chapters on my "dancebot" project- here's what I used my 8 cogs for:
1: capture full-frame rate video from an ntsc camera into hub by identifying h-sync and v-syncs
2: apply computer vision to identify the location of a fiducial marker
3: measure an analog gyroscope with minimal lag
4: measure an i2c accelerometer and fuse it's value with the gyroscope using a kalman filter
5: measure 2 quadrature encoders and track acceleration/velocity/position
6: use a fuzzy logic based pid-controller to balance and steer the robot
7: drive 2 motors- updating speed/direction 200 times/sec
8: ViewPort conduit: full-duplex 2Mbps connection to PC for real-time graphs of variables, datalogging, debugging, etc...
I didn't commercialize the DanceBot, but ViewPort has been used by teachers, hobbyists and engineers on many interesting projects- see some examples here: http://hannoware.com/viewport/applications.php
ViewPort led to the "Parallax PropScope"- which uses all 8 cogs to provide hobbyists/students/engineers with a very powerful oscilloscope/function generator/logic analyzer. 5 cogs run PASM at full speed to let you look at a signal at 40 nanosecond resolution BEFORE a trigger has occurred. Another cog outputs waveforms which you can edit with the click of your mouse- also at 40nsec resolution. A sixth cog manages the ac/dc coupling, voltage ranges, etc- while the seventh handles i2c communication on the PropScope and the 8th uses the conduit to send data to/from the PC where they're graphed.
And finally, this led to 12Blocks- a super easy language my 5 year old daughter used to compete with her TBot at the RoboCup nationals- doing multiple things at the same time: moving servos, moving the robot, pwming leds...
Hanno
I will very shortly get back to you as to what we can do with ANN and the prop.
... apply the standard ANN algorithms, such as Perceptron, Backpropagation, etc using the Prop.
... large amounts of memory is the application of ANN in statistics problems and similar applications.
I am looking forward to this. Leon's examples are too far over my head so I have not been able to get stated. I would prefer to start with the simplest items, make demos that experimenters can follow, and build from there.
I have in mind two options for applications that need lots of memory. The easiest option (for me at least) is to work from an SD card and divide the data into 32k/2k "chunks" on multiple props/cogs. A second alternative could be to send to data to another processor better suited to handling larger blocks of external RAM. This could be a prop with external RAM or any other processor, even off-load data to a fast PC for crunching; but this is not my department and is much further down the road.
Back to the simple examples, I would like to end up with language and hardware independant descriptions of the algorithms and their demos, and then have prop specific examples (from the various contributors) in spin, forth, C etc.
Have you started a resource for for capturing this work? My team uses Google Code to post material publicly, and Google Doc to maintain material internally.
I have found that contributing factors to progress and success are limited scope and record of results. Would limiting scope from "use of the prop" down to "ANN on the prop" be appropriate? Just a thought.
Several people have been advising me to get this book. I tend to have too many plates spinning on too many poles to keep them all from falling, but this is definitely on the list once the infrastructure work on propforth is complete. 12blocks and Viewport are also in my queue. I need fewer bosses and more minions.
I have in mind two options for applications that need lots of memory. The easiest option (for me at least) is to work from an SD card and divide the data into 32k/2k "chunks" on multiple props/cogs. A second alternative could be to send to data to another processor better suited to handling larger blocks of external RAM. This could be a prop with external RAM or any other processor, even off-load data to a fast PC for crunching; but this is not my department and is much further down the road.
I'm taking a look at a different approach, by sending information to a supporting computer it's possible to access many TeraBytes of storage space using internal hard drives, RAM, external hard drives, XDSC cards, and USB Flash drives.
I will very shortly get back to you as to what we can do with ANN and the prop. As a small example, Hanno completed the balancing robot. When I taught ANN, we designed a balancing broom project, using a then primitive IC that had come out. So there is similarity. Some basic algorithms, like the Perceptron, do not require that much memory, others do. What I would like to do is apply the standard ANN algorithms, such as Perceptron, Backpropagation, etc using the Prop. Where you will a requirement for large amounts of memory is the application of ANN in statistics problems and similar applications. Long live the Prop!
I also look forward to seeing your Propeller ANN version programs for the Perceptron and others that fit into Prop memory and run on SPIN.
I'm a big believer that AI/machine learning is hardware limited- so should be done only on the fastest machines- ideally clusters of GPUs. However, as an educational tool I would love to see more things done on the Prop- with no OS or layers of complexity to get in the way of people's understanding.
Check out ViewPort if you want to couple the Prop to the PC for debugging or even during run-time, the high speed conduit effectively "joins" hub ram with your pc's- to let you easily analyze data or fine-tune your program. I recently added features to let you graph arrays and upload binary files from your PC to hub- with crc checking and chunking to load more data than can fit into RAM.
Hanno
I'm a big believer that AI/machine learning is hardware limited- so should be done only on the fastest machines- ideally clusters of GPUs. However, as an educational tool I would love to see more things done on the Prop- with no OS or layers of complexity to get in the way of people's understanding.
This is my opinion too. I need to do something simple as on the prop to I get my head around it before trying anything on complex hardware. A simple example that can easily find its way into the hands of a large volume of experimenters may yield results down the road.
As Leon points out, several other pieces of hardware exist that would be more suitable for a final application, but until such an applications exists, the prop is far superior for getting the basic experiments in the hands of lots of users. In particular me, since I have a prop, and don't have many of the other chips that are out there.
Comments
Here's a whole book of examples that push the Propeller to it's limits- 500 pages worth:
http://www.amazon.com/Programming-Customizing-Multicore-Propeller-Parallax/dp/0071664505
I'm one of the authors (I contributed 2 chapters on my "dancebot" project- here's what I used my 8 cogs for:
1: capture full-frame rate video from an ntsc camera into hub by identifying h-sync and v-syncs
2: apply computer vision to identify the location of a fiducial marker
3: measure an analog gyroscope with minimal lag
4: measure an i2c accelerometer and fuse it's value with the gyroscope using a kalman filter
5: measure 2 quadrature encoders and track acceleration/velocity/position
6: use a fuzzy logic based pid-controller to balance and steer the robot
7: drive 2 motors- updating speed/direction 200 times/sec
8: ViewPort conduit: full-duplex 2Mbps connection to PC for real-time graphs of variables, datalogging, debugging, etc...
I didn't commercialize the DanceBot, but ViewPort has been used by teachers, hobbyists and engineers on many interesting projects- see some examples here: http://hannoware.com/viewport/applications.php
ViewPort led to the "Parallax PropScope"- which uses all 8 cogs to provide hobbyists/students/engineers with a very powerful oscilloscope/function generator/logic analyzer. 5 cogs run PASM at full speed to let you look at a signal at 40 nanosecond resolution BEFORE a trigger has occurred. Another cog outputs waveforms which you can edit with the click of your mouse- also at 40nsec resolution. A sixth cog manages the ac/dc coupling, voltage ranges, etc- while the seventh handles i2c communication on the PropScope and the 8th uses the conduit to send data to/from the PC where they're graphed.
And finally, this led to 12Blocks- a super easy language my 5 year old daughter used to compete with her TBot at the RoboCup nationals- doing multiple things at the same time: moving servos, moving the robot, pwming leds...
Hanno
I am looking forward to this. Leon's examples are too far over my head so I have not been able to get stated. I would prefer to start with the simplest items, make demos that experimenters can follow, and build from there.
I have in mind two options for applications that need lots of memory. The easiest option (for me at least) is to work from an SD card and divide the data into 32k/2k "chunks" on multiple props/cogs. A second alternative could be to send to data to another processor better suited to handling larger blocks of external RAM. This could be a prop with external RAM or any other processor, even off-load data to a fast PC for crunching; but this is not my department and is much further down the road.
Back to the simple examples, I would like to end up with language and hardware independant descriptions of the algorithms and their demos, and then have prop specific examples (from the various contributors) in spin, forth, C etc.
Have you started a resource for for capturing this work? My team uses Google Code to post material publicly, and Google Doc to maintain material internally.
I have found that contributing factors to progress and success are limited scope and record of results. Would limiting scope from "use of the prop" down to "ANN on the prop" be appropriate? Just a thought.
Is anybody else gettting excited?
Several people have been advising me to get this book. I tend to have too many plates spinning on too many poles to keep them all from falling, but this is definitely on the list once the infrastructure work on propforth is complete. 12blocks and Viewport are also in my queue. I need fewer bosses and more minions.
I'm taking a look at a different approach, by sending information to a supporting computer it's possible to access many TeraBytes of storage space using internal hard drives, RAM, external hard drives, XDSC cards, and USB Flash drives.
Make sure to check out hierarchical markov models:
http://en.wikipedia.org/wiki/Hierarchical_hidden_Markov_model
People are doing fun stuff like this:
http://www.i-programmer.info/news/105-artificial-intelligence/2695-kinect-knows-what-you-are-doing.html
Check out ViewPort if you want to couple the Prop to the PC for debugging or even during run-time, the high speed conduit effectively "joins" hub ram with your pc's- to let you easily analyze data or fine-tune your program. I recently added features to let you graph arrays and upload binary files from your PC to hub- with crc checking and chunking to load more data than can fit into RAM.
Hanno
This is my opinion too. I need to do something simple as on the prop to I get my head around it before trying anything on complex hardware. A simple example that can easily find its way into the hands of a large volume of experimenters may yield results down the road.
As Leon points out, several other pieces of hardware exist that would be more suitable for a final application, but until such an applications exists, the prop is far superior for getting the basic experiments in the hands of lots of users. In particular me, since I have a prop, and don't have many of the other chips that are out there.