I updated 2_wire_LCD for PF5.5.
Curcuit are 2type(4bit mode and 8bit mode).
Driver for 4bit mode is Char_LCD(2wire_4bit)_0.1.
Driver for 8bit mode is Char_LCD(2wire_8bit)_0.1.
The instructions in PropForth.htm Section 5 are all that is necessary and sufficient to for an experienced user; however, and inexperienced user might have a couple questions. So I just wrote down my stream of consciousness investigation. If anyone want to take a look and give comments please do. Extra points if you are a teacher and suggest modification to make it more suitable for your class.
The name is Linux PropForth, but it probably could be Linux Spin and still be correct.
This uses simpleIDE, and just makes the provided instructions more braino-proof. The intent is that if one does exactly as written, one will get the exact result every time, and it would be easier to support. This may come in handy, as there are at least three groups that express intent to start robotics programs using PropForth & Little Robot
The goal is that end result is the same or very close to what the majority of prop users will be using, so it will be easier for the new users to ask questions and get answers form the prop community at large. If they use PropForth, stick with SPIN or move on to C does not matter, as long as they can get going.
Comment and suggestions are welcome.
If the instructions seems to simplistic to an advanced user, please bear in mind that theses are gear toward kids, and their parents (who may have no particular interest in Linux, the prop, electronics, or computers in general, beyond seeing the kid smile when the bot finally moves).
We started discussing the direction for the LittleRobot demo. We think the proof of concept shows it works. Now we might try to develop an application to show off the remote programing over internet. This is National Robotic Week, if we start now, we might have something ready for 2014. So the current direction may be some sort of a demo or application suitable for a Nation Robotics Week event.
Of course the first idea was a LittleRobots(tm) version of the Tank Battle game, with simply a laser and photoreceptor on each bot. This option perhaps sends the wrong message by focusing on destruction. But its hard to beat fun, obvious, and blasting your enemy's tanks with a laser. Any alternative to that would have to be carefully crafted to hope for any success.
Sal suggests reviewing ECON 159: GAME THEORY at OYC.YALE.EDU http://oyc.yale.edu/economics/econ-159
This is my task starting this week.
Any more recommendations?
We may try something that focuses on cooperation, as the First Robotics events often do. The task should be suitable for one to 100 participants (or more?), with perhaps 10 participants (the number in one school class or workshop) as a likely number in a round.
Would anyone interested in participating in something like this? Comments, questions, ancedotes and suggestions are welcome.
Distance is;
Step-distance[mm] = (tire_diameter[mm] X Pi)/(360[degree)/step_angle)
tire_diameter:37mm
step_angle:1
When tire rotate 1-rotation, PropRover move 116mm.
Actually, moved 115mm.
#33 is word"main".
Line69 in StepMotor_0.6.3
\ 1 wconstant step_debug <--- Uncomment
Executed word"test", StepMotor_log.txt.
position from 0 to 49: Acceraration term
position from 50 to 670: Constant speed term
position from 680 to 720: De-acceraration term
Total-steps are 720.
Tire rotate 1-rotation, because this is halfstep.
Could you take all your published code (and docs) and make one archive? You have so much material, its is spread through all the propforth threads, I can't keep it organized. But I think we are going to need it when the classes start going.
Even if it for a previous release, just make a note which is the most recent you were working with. Even if it is not final or not completely working, just mark it so, it would help other folks to have your work as a starting point.
You have so much material, it could be very handy to have it in one archive (perhaps caskaz2130410.zip?) that folks could download with your complete collection.
Could you take all your published code (and docs) and make one archive? You have so much material, its is spread through all the propforth threads, I can't keep it organized. But I think we are going to need it when the classes start going.
Even if it for a previous release, just make a note which is the most recent you were working with. Even if it is not final or not completely working, just mark it so, it would help other folks to have your work as a starting point.
You have so much material, it could be very handy to have it in one archive (perhaps caskaz2130410.zip?) that folks could download with your complete collection.
I have checked item I had wrote.
sd_viewer touchscreen LCD_with_vram eeprom(24LC1024) rtc(ds1337,ds3231) character_LCD(1-Wire,2-Wire,3-Wire) RadioControlClock Dynamic_Drive_7SEG MCP3204 8X8_matrixLED POV max3421E Pulse_monitor Wii_nunchck 1_wire_device Delta_Robot 4-legs-robot(KMR-P4) Tester_P10
There are some items I cannot understand(comment is very few).
Some are meaningless.
Some are not complete.
Some have bugs.
So, I re-write codes and make archive.
I have checked item I had wrote.
sd_viewer touchscreen LCD_with_vram eeprom(24LC1024) rtc(ds1337,ds3231) character_LCD(1-Wire,2-Wire,3-Wire) RadioControlClock Dynamic_Drive_7SEG MCP3204 8X8_matrixLED POV max3421E Pulse_monitor Wii_nunchck 1_wire_device Delta_Robot 4-legs-robot(KMR-P4) Tester_P10
There are some items I cannot understand(comment is very few).
Some are meaningless.
Some are not complete.
Some have bugs.
So, I re-write codes and make archive.
I have checked item I had wrote.
sd_viewer touchscreen LCD_with_vram eeprom(24LC1024) rtc(ds1337,ds3231) character_LCD(1-Wire,2-Wire,3-Wire) RadioControlClock Dynamic_Drive_7SEG MCP3204 8X8_matrixLED POV max3421E Pulse_monitor Wii_nunchck 1_wire_device Delta_Robot 4-legs-robot(KMR-P4) Tester_P10
There are some items I cannot understand(comment is very few).
Some are meaningless.
Some are not complete.
Some have bugs.
So, I re-write codes and make archive.
if i may suggest....
just make the archive, as is, no updates. al we want is that it contains Everything.
if someone has an interest, let the questions drive rewrite, comments update, completion.
we don't want to interupt you current work
you have many fans, perhaps the discussion will grow, and the input will be helpful
Discussed how to troubleshoot the HC05 and HC06 bluetooth modules. My notes, which worked fine last time, were not successsful yesterday. The suspicion is that the default baud rate could be different on each part, if they come from different manufacturers; also the HC05 and HC06 look identical, so I could have mixed them up (even though I ordered only HC05's last time) or the broker could have mixed them up. Or maybe I didn't follow the directions.
We're considering a multiple bot demo for the little robot project. Still in the braino-storming phase, but with an eye towards swarming behavior.
I'm looking at context highlighting, after seeing simple IDE and gedit. I'm considering a unique extension (*.4th ?) and reworking the provided FORTH context, since most of it doesn't make sense in propforth. Sal doesn't use context highlighting, so we can do whatever we like at this point. Does anyhave something set up that we might try out as a "standard"?
But there is problem when execuring word"demo_IN".
bit5-bit0 inside PortA/B/C sometimes become to "0"bit though each bit connect to 5V.
bit7 and bit6 is ok.
8255's data-bit have noise when I check data-bit by oscilloscope.
It don't change them though I put on capacitors to 8255's power-line and to level-shifter's Vcca/Vccb.
It might occur by 8255's problem because this parts is junk.
Hi Sapieha.
Thanks to test 8255.
You have 8255 too?
I found out bug in word"data_In".
I didn't change data-port to input when reading data.
Noise on data-bits has gone after modified word"data_In".
I also check 220-ohm instead of level-shifter.
It works finely.
Voltage on Propeller's port is about 3.6V because current is very few.
Voltage is clipped by inner diode.
Hi Sapieha.
Thanks to test 8255.
You have 8255 too?
I found out bug in word"data_In".
I didn't change data-port to input when reading data.
Noise on data-bits has gone after modified word"data_In".
I also check 220-ohm instead of level-shifter.
It works finely.
Voltage on Propeller's port is about 3.6V because current is very few.
Voltage is clipped by inner diode.
Sal is working on another kernel that adds flow control, and does not need the fl word to buffer text in another cog.
Currently, the propforth kernels use the fl word to buffer text when the input stream is longer than the 64 byte input buffer. The fl word finds an unused cog, and that uses the available cog memory to buffer the input stream, and send the stream througgh the interpreter.
The need for "fl buffering" arose from problems with existing flow control implementations. None of the existing flow control solution work reliably, since there are many inconsistent and conflicting flow control options. The"other side", the application to which proforth is trying to communicate, may or may not use a particular flow control. For example, teraterm would not function reliably, or some other application would break when tera term was made to work. Since the external application flow contorol implementation is out of the scope of propforth, Sal decided buffering was the most direct way to ensure the communication would "always just work".
Sal's new flow control kernel is designed to communicate with applications where we control both sides of the flow control implementation. For example, the android app GREEN, and the Go language program GoTerm, or your custom app. When both sides of the communication can use the same flow control, we won't need to use the fl word, and we won't need to worry about the speed or throughput. The communication will just go and the flow control will automatically handle it.
When ready, Sal will post an update release. This next release might also include a gerneic logging example. Sal's had loggin running for a couple years now, he just has to dig out the code and make it generic. We just allocate a "big enough" space on the media (usually the whole thing), and append to the file. One cog can read the file when another is writing the file, so we can export the data to a PC while the application is still running and logging.
I'm starting the pilot session for the LittleRobot(tm) project. We're going to take a bunch of kids of varying ages and introduce them in groups to the LittleRobot. The pilot program is short, till the end of the spring session. If they are intereested or show some progress, we may try one kit per student, and an run for a full session next fall.
A larger project which extends beyond the scope of propforth is underway. We are looking at designing an event that involves many bots in a cooperative event. We're starting with the online Yale course ECON 159 Game Theory to aid in designing the event. The event will allow similar bots (low cost differential steering) to participate in a cooperative task. The target deadline is to present the event for National Robotic Week 2014.
Hi.
I made curcuit by using supersonic transducer(transmitter & receiver).
Prop0 Cog6 ok
distance
phsa=158910 341 mm
phsa=158909 341 mm
phsa=158905 341 mm
phsa=158905 341 mm
phsa=158907 341 mm
phsa=158903 341 mm
phsa=158906 341 mm
phsa=158907 341 mm
phsa=158908 341 mm
phsa=158908 341 mm
phsa=158905 341 mm
phsa=158909 341 mm
I checked signal on comperator's non-inverting terminal by oscillocope.
Red: P0-out 40kHz(200usec) range:2V
Yellow:comperator's non-inverting terminal range:1V time:500usec
First small signal is vibration from transmitter to receiver through board.
Secomd signal is reflection against wall.
Sal is working on his new kernel with flow control serial; for communicating with another device for example an application running on a PC. The need is for handling huge amounts of data in both direction with no buffer overrun and no fl command. (Recall that fl is "fastload" in which an unused cog uses it cog memory to buffer and interpret the datastream.) The buffering method has been very effective in most cases such as loading source code, now the case of huge data justifies a new approach.This flow control method requires specific software on the
The test is to run transfer overnight and send and recieve a gigbyte of data. So far there have been no issues detected.
The target application is to send lots of small instruction and monitor the data coming back. Sal is using the J language on the PC. The prop has several activities going on, each on a separate cog. Sal had attempted this using an ARM chip and C language, but the tasks were taking varying time and setting up time slicing correctly was "a nightmare". With propforth is was much easier to get the time sorted out. Sal is doing a complex XY table with lots of nifty acceleration and dynamic voltage adjustment. He's pushing the motors to their limit by cranking up the volts for max acceleration, but cranking it back down so they don't burn up. It sounds kind of cool. He's sending huge vectors of complex data, and send back huge vectors of results. One cog does the vector analysis, the next does another part, and so on until the last cog send the monitoring data back. It uses minimal assembler as only a couple parts needed any optimization.
Sal is using the J language on the PC side, which "is not for the faint of heart". The PC J applications is doing simulation: using these number should yield these results. He says J is great if you think like a mathematician, but his peers and staff that think "procedurally" could not get it. So, Sal is asking what language folks are using on the PC side these days, I said aside from C folks seem to be using python. [If you have better insight please post]. I pointed him to Sarah Mount at Wolverhampton and her material for python/CSP, maybe this will be in our future.
Some folks may feel this "simulation and verification" approach is overkill. Sal has found that this make automated testing of everything a snap. While some folks say automated testing is too hard or expensive, Sal tells me that NOT having simulation and automated testing is much harder. I always felt this would be the case, and this is the first clinical evidence (for me) that confirms it.
Next release should have something for the serial flow control and PC controlling the prop.
Braino has been working on the pilot run of the LittleRobot project, developing the curriculum. We had most of the class do "Hello word" an "blinky LED". Two forth graders were able to make the Quickstart LEDs do the Cylon-style scan. Next clase they are to teach this to their peers. We are still having issues getting the kids set up with school-provided Mac laptops for terminals, turns out that all have their own laptops so we going to ask them to just bring their personal XP laptops fom home. We also have two (non-technical) teachers, they were able to learn the propforth materials without their heads exploding (yet) so we think we are successful so far.
We don't know if we will get any of the kids to an actual moving robot by the end of the term on June 3. We may release the kits to them to use of summer, this carries a different set of risks and payoffs.
Comments
Curcuit are 2type(4bit mode and 8bit mode).
Driver for 4bit mode is Char_LCD(2wire_4bit)_0.1.
Driver for 8bit mode is Char_LCD(2wire_8bit)_0.1.
http://youtu.be/V3UYdgRwwCQ
Congratulations!! It is ALIVE!!!!
http://code.google.com/p/propforth/wiki/LogicAnalyzerLAC
The instructions in PropForth.htm Section 5 are all that is necessary and sufficient to for an experienced user; however, and inexperienced user might have a couple questions. So I just wrote down my stream of consciousness investigation. If anyone want to take a look and give comments please do. Extra points if you are a teacher and suggest modification to make it more suitable for your class.
http://code.google.com/p/propforth/wiki/LinuxPropforth
The name is Linux PropForth, but it probably could be Linux Spin and still be correct.
This uses simpleIDE, and just makes the provided instructions more braino-proof. The intent is that if one does exactly as written, one will get the exact result every time, and it would be easier to support. This may come in handy, as there are at least three groups that express intent to start robotics programs using PropForth & Little Robot
The goal is that end result is the same or very close to what the majority of prop users will be using, so it will be easier for the new users to ask questions and get answers form the prop community at large. If they use PropForth, stick with SPIN or move on to C does not matter, as long as they can get going.
Comment and suggestions are welcome.
If the instructions seems to simplistic to an advanced user, please bear in mind that theses are gear toward kids, and their parents (who may have no particular interest in Linux, the prop, electronics, or computers in general, beyond seeing the kid smile when the bot finally moves).
We started discussing the direction for the LittleRobot demo. We think the proof of concept shows it works. Now we might try to develop an application to show off the remote programing over internet. This is National Robotic Week, if we start now, we might have something ready for 2014. So the current direction may be some sort of a demo or application suitable for a Nation Robotics Week event.
Of course the first idea was a LittleRobots(tm) version of the Tank Battle game, with simply a laser and photoreceptor on each bot. This option perhaps sends the wrong message by focusing on destruction. But its hard to beat fun, obvious, and blasting your enemy's tanks with a laser. Any alternative to that would have to be carefully crafted to hope for any success.
Sal suggests reviewing ECON 159: GAME THEORY at OYC.YALE.EDU
http://oyc.yale.edu/economics/econ-159
This is my task starting this week.
Any more recommendations?
We may try something that focuses on cooperation, as the First Robotics events often do. The task should be suitable for one to 100 participants (or more?), with perhaps 10 participants (the number in one school class or workshop) as a likely number in a round.
Would anyone interested in participating in something like this? Comments, questions, ancedotes and suggestions are welcome.
Not convert A/D-value to distance.
There is Nipponbashi in Osaka.
There are parts-shop in Nipponbashi.
But less than Akihabara in Tokyo.
I often buy electoronics parts in Nipponbashi.
I try to make PropRover.
Youtube below is only moving foward by word"main1".
http://youtu.be/CI7OICz5IC4
Distance is;
Step-distance[mm] = (tire_diameter[mm] X Pi)/(360[degree)/step_angle)
tire_diameter:37mm
step_angle:1
When tire rotate 1-rotation, PropRover move 116mm.
Actually, moved 115mm.
#33 is word"main".
Line69 in StepMotor_0.6.3
\ 1 wconstant step_debug <--- Uncomment
Executed word"test", StepMotor_log.txt.
position from 0 to 49: Acceraration term
position from 50 to 670: Constant speed term
position from 680 to 720: De-acceraration term
Total-steps are 720.
Tire rotate 1-rotation, because this is halfstep.
Could you take all your published code (and docs) and make one archive? You have so much material, its is spread through all the propforth threads, I can't keep it organized. But I think we are going to need it when the classes start going.
Even if it for a previous release, just make a note which is the most recent you were working with. Even if it is not final or not completely working, just mark it so, it would help other folks to have your work as a starting point.
You have so much material, it could be very handy to have it in one archive (perhaps caskaz2130410.zip?) that folks could download with your complete collection.
Thanks!
Thanks for that request --
Hi caskaz --- I'm second for that request
THANKS
I have checked item I had wrote.
sd_viewer touchscreen LCD_with_vram eeprom(24LC1024) rtc(ds1337,ds3231) character_LCD(1-Wire,2-Wire,3-Wire) RadioControlClock Dynamic_Drive_7SEG MCP3204 8X8_matrixLED POV max3421E Pulse_monitor Wii_nunchck 1_wire_device Delta_Robot 4-legs-robot(KMR-P4) Tester_P10
There are some items I cannot understand(comment is very few).
Some are meaningless.
Some are not complete.
Some have bugs.
So, I re-write codes and make archive.
Massimo
Very much THANKS
if i may suggest....
just make the archive, as is, no updates. al we want is that it contains Everything.
if someone has an interest, let the questions drive rewrite, comments update, completion.
we don't want to interupt you current work
you have many fans, perhaps the discussion will grow, and the input will be helpful
I uploaded archive-files as you advice.
These cannot load on PF5.5.
Modification need.
C --> hC
I put these up as a single download
http://code.google.com/p/propforth/downloads/detail?name=caskaz-PF-collection_20130410.zip
If you make corrections or addtions, we can post a new one and depracate the old one
I plan to start a wiki page with a section for each experiment.
Thanks Caskaz!
Also, if anybody has questions or updates on any given entry, we can update the wiki page.
Discussed how to troubleshoot the HC05 and HC06 bluetooth modules. My notes, which worked fine last time, were not successsful yesterday. The suspicion is that the default baud rate could be different on each part, if they come from different manufacturers; also the HC05 and HC06 look identical, so I could have mixed them up (even though I ordered only HC05's last time) or the broker could have mixed them up. Or maybe I didn't follow the directions.
We're considering a multiple bot demo for the little robot project. Still in the braino-storming phase, but with an eye towards swarming behavior.
I'm looking at context highlighting, after seeing simple IDE and gedit. I'm considering a unique extension (*.4th ?) and reworking the provided FORTH context, since most of it doesn't make sense in propforth. Sal doesn't use context highlighting, so we can do whatever we like at this point. Does anyhave something set up that we might try out as a "standard"?
Do you remember 8255?
I write driver(only mode0) for 8255 because I found out it in my junk-box.
Bit-out to PortA/B/C work finely. Word"demo_OUT"
But Bit-in from PortA/B/C don't work. Word"demo_IN"
I think there are mistakes in code or level-shifter don't work well when input-direction(prop<--8255).
But there is problem when execuring word"demo_IN".
bit5-bit0 inside PortA/B/C sometimes become to "0"bit though each bit connect to 5V.
bit7 and bit6 is ok.
8255's data-bit have noise when I check data-bit by oscilloscope.
It don't change them though I put on capacitors to 8255's power-line and to level-shifter's Vcca/Vccb.
It might occur by 8255's problem because this parts is junk.
I use 220R resistors between Prop 1 and never have problems.
Thanks to test 8255.
You have 8255 too?
I found out bug in word"data_In".
I didn't change data-port to input when reading data.
Noise on data-bits has gone after modified word"data_In".
I also check 220-ohm instead of level-shifter.
It works finely.
Voltage on Propeller's port is about 3.6V because current is very few.
Voltage is clipped by inner diode.
Using resister is very simple.
I have build and use with prop 1 PCB with 2 8055 IC's some Years ago
Sal is working on another kernel that adds flow control, and does not need the fl word to buffer text in another cog.
Currently, the propforth kernels use the fl word to buffer text when the input stream is longer than the 64 byte input buffer. The fl word finds an unused cog, and that uses the available cog memory to buffer the input stream, and send the stream througgh the interpreter.
The need for "fl buffering" arose from problems with existing flow control implementations. None of the existing flow control solution work reliably, since there are many inconsistent and conflicting flow control options. The"other side", the application to which proforth is trying to communicate, may or may not use a particular flow control. For example, teraterm would not function reliably, or some other application would break when tera term was made to work. Since the external application flow contorol implementation is out of the scope of propforth, Sal decided buffering was the most direct way to ensure the communication would "always just work".
Sal's new flow control kernel is designed to communicate with applications where we control both sides of the flow control implementation. For example, the android app GREEN, and the Go language program GoTerm, or your custom app. When both sides of the communication can use the same flow control, we won't need to use the fl word, and we won't need to worry about the speed or throughput. The communication will just go and the flow control will automatically handle it.
When ready, Sal will post an update release. This next release might also include a gerneic logging example. Sal's had loggin running for a couple years now, he just has to dig out the code and make it generic. We just allocate a "big enough" space on the media (usually the whole thing), and append to the file. One cog can read the file when another is writing the file, so we can export the data to a PC while the application is still running and logging.
I'm starting the pilot session for the LittleRobot(tm) project. We're going to take a bunch of kids of varying ages and introduce them in groups to the LittleRobot. The pilot program is short, till the end of the spring session. If they are intereested or show some progress, we may try one kit per student, and an run for a full session next fall.
A larger project which extends beyond the scope of propforth is underway. We are looking at designing an event that involves many bots in a cooperative event. We're starting with the online Yale course ECON 159 Game Theory to aid in designing the event. The event will allow similar bots (low cost differential steering) to participate in a cooperative task. The target deadline is to present the event for National Robotic Week 2014.
I made curcuit by using supersonic transducer(transmitter & receiver).
I checked signal on comperator's non-inverting terminal by oscillocope.
Red: P0-out 40kHz(200usec) range:2V
Yellow:comperator's non-inverting terminal range:1V time:500usec
First small signal is vibration from transmitter to receiver through board.
Secomd signal is reflection against wall.
This code don't process time-out.
I copied Gareth's idea.
http://forums.parallax.com/showthread.php/146093-Persistence-Of-Vision-POV-%28using-Rom-Bitmap%29
Gareth, Thank you for cool idea.
Updated POV_I.
http://youtu.be/QZzzgP11BwI
Shape of 'h'(inside string'Forth') is strange.
Sometimes it seems LEDs don't turn on.
Maybe there is wrong on code or hardware.
I have no idea.
Sal is working on his new kernel with flow control serial; for communicating with another device for example an application running on a PC. The need is for handling huge amounts of data in both direction with no buffer overrun and no fl command. (Recall that fl is "fastload" in which an unused cog uses it cog memory to buffer and interpret the datastream.) The buffering method has been very effective in most cases such as loading source code, now the case of huge data justifies a new approach.This flow control method requires specific software on the
The test is to run transfer overnight and send and recieve a gigbyte of data. So far there have been no issues detected.
The target application is to send lots of small instruction and monitor the data coming back. Sal is using the J language on the PC. The prop has several activities going on, each on a separate cog. Sal had attempted this using an ARM chip and C language, but the tasks were taking varying time and setting up time slicing correctly was "a nightmare". With propforth is was much easier to get the time sorted out. Sal is doing a complex XY table with lots of nifty acceleration and dynamic voltage adjustment. He's pushing the motors to their limit by cranking up the volts for max acceleration, but cranking it back down so they don't burn up. It sounds kind of cool. He's sending huge vectors of complex data, and send back huge vectors of results. One cog does the vector analysis, the next does another part, and so on until the last cog send the monitoring data back. It uses minimal assembler as only a couple parts needed any optimization.
Sal is using the J language on the PC side, which "is not for the faint of heart". The PC J applications is doing simulation: using these number should yield these results. He says J is great if you think like a mathematician, but his peers and staff that think "procedurally" could not get it. So, Sal is asking what language folks are using on the PC side these days, I said aside from C folks seem to be using python. [If you have better insight please post]. I pointed him to Sarah Mount at Wolverhampton and her material for python/CSP, maybe this will be in our future.
Some folks may feel this "simulation and verification" approach is overkill. Sal has found that this make automated testing of everything a snap. While some folks say automated testing is too hard or expensive, Sal tells me that NOT having simulation and automated testing is much harder. I always felt this would be the case, and this is the first clinical evidence (for me) that confirms it.
Next release should have something for the serial flow control and PC controlling the prop.
Braino has been working on the pilot run of the LittleRobot project, developing the curriculum. We had most of the class do "Hello word" an "blinky LED". Two forth graders were able to make the Quickstart LEDs do the Cylon-style scan. Next clase they are to teach this to their peers. We are still having issues getting the kids set up with school-provided Mac laptops for terminals, turns out that all have their own laptops so we going to ask them to just bring their personal XP laptops fom home. We also have two (non-technical) teachers, they were able to learn the propforth materials without their heads exploding (yet) so we think we are successful so far.
We don't know if we will get any of the kids to an actual moving robot by the end of the term on June 3. We may release the kits to them to use of summer, this carries a different set of risks and payoffs.