Sal likes your code. He said he could understand it in the time it takes to read it.
Acceleration: Sal mentioned he is not satified with the way he did acceleration, it loses accurratcy when there are a lot of small turns. Thoughts or comments?
Just had the first opportunity to really read through what you've been doing. As you know, I also have experience working with kids around this age and understand closely what you're going through! Certain kids will understand very well, and it'll be rewarding to see that occur.
Simplify, simplify and simplify again. And dare I suggest that the programming language in 4th grade doesn't matter. What matters is that it's super easy to use, that they can enter very basic commands "GO F, 20 steps" using whatever simple syntax you can make available. The syntax rules must be minimal and directions clear. Make one successful student help another one, too. I imagine you're already taking these steps from the above.
You are commended for sharing. Don't underestimate the impact you are having on these kids because they are quietly identifying their future interests.
Way to go, Doug. I'm replying to your e-mail now and Lauren will figure out how to help with the latest request.
Here is clarification on calculating the calibration numbers for wheel radius and body width. Sal just wrote the code, I have to come up with better variable names.
bot.f :
263 wconstant _distance_cal \ wheel diamter * pi or wheel raius * 2 * pi, in mm
\ _distance_cal is the circumference of the wheel. Sal's wheels are 41.85 radius. Either he has thick rubber band treads or my printer is out of calibration
6052 wconstant _right_cal \ wheel base radius * wheel radius * pi.
\ _right_cal is the circumference of the circle whose diamter is the wheelbase times the wheel radius; in mm
\ Sal's chassis is 46.03 *2 = 92.06 mm wide.
The acrilic wheels are 73mm diameter, so wheel radius is 36.5
229 wconstant _distance_cal \ for acrylic laser cut wheels from Propeller powered
The 4x6 inch wide pink foam blocks with wheels are 118.75 mm wide so
The body radius (wheel base/2) = 59.73
body_radius * wheel_radius * pi = _right_cal
59.75 * 36.5 * pi = 6851
6851 wconstant _right_cal \ for 4x6 foam chassic
The 6x8 inch wide pink foam blocks with wheels are 165 mm wide so
The body radius (wheel base/2) = 82.5
body_radius * wheel_radius * pi = _right_cal
82.5 * 36.5 * pi = 9469
Friday, I found out that one of the kids is actually a THIRD grader. AND this is the one that is furtherest along.
First Robotics advised me that the youngest that can be expected to be successful are high school juniors and seniors;
First Lego League advised that the youngest that can be expected to be successful are seventh and eighth graders (so I tried a group of sixth graders and they succeded).
This time I asked for sixth and seventh graders (I didn't want to push my luck). Turns out that by not paying attention to the actual ages, I just assumed they were old enough to succede, and they have. The third and fourth graders are in the class most often (perhaps thay have not learn how to escape to the playgorund) and have shown the most progress.
Contacted a local High School. The Tech teacher has some time now that school is out. The have had a roboitcs program for at least a decade, but only mechanical and electrical, no real microcontroller programming. (!)
First thing he noticed was the materials are poorly organized and not suitable for direct consumption by student (go figure).
I told him his role would be to get me feed back on what to change to make it exactly what he has in mind (I currently have no clue what he might possible want).
I wonder if he will take this risk? In exchange for reading the material, and making a few comments, they get the exact materials they have been lacking (for years) for free. He's still unsure if the price is too high. He really has no reason to trust me or belive me, all he's seen is a block of foam with some wheels on it; and a bunch of gibberish on my tablet, which I claim is the robot operating.
I'll proofread for typos and such when I get a chance and provide feedback, if you'd like.
YES please!
What is your target audience for these? General adult population, high school kids, 4th graders (please don't say 4th graders! )
OK, this is going to seem wacky to folks that haven't read any of my previous posts.
I THINK I am targeting anyone in the FIRST FOUR HOURS (*) of exploration. This includes elementary school kids (because it might have worked with 3rd and 4th graders) up to Master's Students (because it worked with the Media teacher) up to old geezers (because it worked with the photographer who is my age). This was all in the same class. The fourth graders WILL NEED parents help, they can't read an comprehend like engineers. The materials are intended to get ANYONE up and running quickly.
(*) The elementary school kids took 6 weeks to get through it, Vic took about 2 hours. TIMING is not built into the materials, we have to play that part by ear.
Post Mortum for the LittleRobot pilot session spring 2013
The LittleRobot pilot was orginally intended to be a full school year session, running from September 2012 to June 2013. Due to the usual factors, most of the schedule was covercome by events. The session finally started in April 2013, and ended as planned June 2013.
The plan was to teach kids to be engineers. This was changed to "provide a critical event that may inspire further interest". The method used was described to me as the Montessori method, let them play by removing the boring parts.
Ten kits were obtained. We did not determine the class size before hand, we figured we could have one to three students per kit. The 1 student per kit student did better, the three students per kit comleted less of the material The three student groups tended to goof around with each other rather than work together, the one students got direct 1 to 1 mentoring from the instructor and did little goofing around with me eye-balling them the whole time.
The school agreed to provide space, and teachers. The arrangement was that the consultant would initially be on site for the beginning, to get the teascer started, them all interaction would be over the internet, email, video conference, google hang out etc. Unfortunately, the individual hired was intimidated by the rough cut of the material, and bailed out. The session was left with no teacher, and the consultant was on-site for each meeting. The regular school staff that helped out could not be reliied on to "own" the class.
Of the twelve or so kids that passed through the class:
Three showed up every meeting, three times a week. The rest missed at least one session per week.
* Two kits were constructed and tested, passed working, before the last day of class.
* Two kits were constructed and tested, passed working, on the lst day of class.
* Two kits were constructed and tested, but did not make it passed trouble shooting.
* Four kits did not complete construction, due to lack of mentorship, lost of broken parts, or incorrect sconstruction.
So of ten kits, four are working, four are still in peices, and two are in between.
We discovered that at least two of the kids were "special needs"; that is they had a suppot person to tend them one on one throughout the regualr school day. The support person was NOT present at the LittleRobot session. We determined that if the kid need support during the regualr day, the support better bne present for the special session after school. This was a difficult lesson, but now we have hard data to support this.
Windows, Linux, and Sansung android (Galaxy, Nexus) were successful in supporting the software tools and environment, including the bluetooth. Apple OSX was able to run the terminal emulator (CoolTerm) with much difficulty, and iOS (iPhone, iPad which every kid had) absolutely will NOT work with the blue tooth connection. The one HTC android ALMOST worked, except for the return key. Blackberry also did not support any blue tooth terminal that we could find.
The finding is that given one to one attention at the proper time, third, four, and fifth graders could successfully built the robot and get it programmed. Specify Windows Netbook with Bluetooth (dongle) or Sansung Android.
The desision is to continue this program as an official supported ciriculum.
Plan is to take what we have learned, revist the kits, and fully train the teachers (using the 4 hour workshop version) for next fall. After building the kits, the kids will persue programming. The plan is to start with auto calibration, and move to something like simple autonomous navigation or obsticale detection and collision avoidance.
Do different next session:
1) train the teachers to build the bot before the regular class
2) eliminate all parts that require prefabrication.
3) ensure the kids all have a non iOS blue tooth device. Make them find and bring bluetooth dongle if needed.
4) have the kids bring in a wind-up alarm clock, either broken or from the thrift shop.
5) ensure the computers are present, setup, and working before class starts. We went two weeks with only my laptop.
6) ensure there is a teacher present at all times.
7) if a key element (teacher, laptops, power, internet, parts) is missing, class is canceled until restored.
8) school provides a storage box and storage for each kit. Keeping all the parts in one big box does not work nicely.
9) budget for 20% spares for loss or breakage. This might be partially solved by #8
#4 is because at least one (probably all) the kids had never turned a screw with a screwdriver.
Instruction for the broken alarm clock activity would be:
* find a screw- unscrew it; screw it back in.
* find a second screw, unscrew both, screw them both back in to their original spot.
* continue taking off one more part, and putting it back together, until you get stuck or run our of parts.
Taking apart a broken clock, and finding it worked after I put it back together, got me started.
Over the weekend I loaded PropForth and NickL's robot control language onto my own version of the LittleRobot
The lack of documentation on the robot control language was holding me back a bit. I plan to reverse engineer the Forth to understand what is going on, but are there any examples of usage? I was poking around the code repository and didn't see any.
We conducted a LittleRobot workshop at Chicago Public Library's new Maker Lab at the Harold Washington Center. This was the first time we tried it as a four hour workshop.
The folks were surprised at the depth and "hands on" aspect of the program. They all said they enjoyed it. Youngest was 7 and 9 year old boys with Dad, oldest was retired elementary school teach, she wanted to "catch up with these robots". Half were male, half were female.
All participants loaded PC software, downloaded propforth, burned the kernel to EEprom, did hello world, and Blinky LED. All got the motors to turns, and mounted on the chassis.
Then we ran out of time. Turns out waiting for ALL participants to complete each goal means the slowest holds back the rest. They got the the SR04 and the HC06 connected, but we didn't get the drivers installed. NEXT time, when the FIRST person gets the activity complete, we'll wait 5 minutes, then move on. Folks will complete unfinished activities during troubleshooting, and participants will demonstrate proficiency by helping peers.
We're trying the schedule a follow up session (at now extra cost) so folks can complete the build. 0% complete is not such a useful datapoint, it only says we have poor time management.
Up to now Ive only used PropForth with my CS-101 problems, so I have a few questions on what I think are PropForth built-ins.
In this program I see both the use of if then, and if thens. But I havent seen if thens, how does it differ from if then? I looked in a few FORTH books but havent found anything. Although it is only used within begin 0 until loops, so Im guessing its related.
Is delms a built-in to delay for the milliseconds on the stack?
Are the words pinin, pinout, pinlo, and pinhi built-ins for pin control? If so their functions are pretty obvious.
Are the words cogstop, cogreset, and cogx built-ins for cog control? If so I assume cogstop stops a cog, but cogreset and cogx are confusing to me. I think cogx tells a cog to run a word.
Also why c" rc_lwheel" instead of an execution token to the word?
Little robot control language questions.
There are two versions of NickLordis robot language at https://code.google.com/p/propforth/downloads/list. They are NickLordiRobotControlLanguage-LittleRobot20130523-PfrcLitbot_2.txt and NickLordiRobotControlLanguage20130520.txt, which one is the best one to use?
Why the definition of the (PFRCLR ) word. It does nothing, nor is it referenced elsewhere.
The WTO word seems unused and its function is unclear to me. I think it changes the address a constant points to, but Im not sure what it is for.
There are a number of unused constants (wcirc, steps, rdiam, tdiam), what was intended by them?
Why forward and backward step counts instead of signed numbers? What if both values are set?
Why forward and backward velocities? Doesnt the forward or backwards step count where the direction information is stored?
What are ldly, rdly, and ci used for?
Why the rc_ prefix on several words?
I understand the intent of rc_rwheel and rc_lwheel, but what does rc_steps do? A header comment would have been helpful here. It is referenced by the Vstart word and an earlier comment mentions that ci is related to velocity.
What is the significance of the () in S()?
What does TC do?
Comments for ftst, btst, and rtst would be helpful.
In usage do I call START and then other commands?
Thanks for looking at this. PM me with your email (gmail if you have it) and I'll add you to the edit permissions list. Its faster and easier than waiting for me to retype stuff.
• In this program I see both the use of if then, and if thens. But I haven’t seen if thens, how does it differ from if then? I looked in a few FORTH books but haven’t found anything. Although it is only used within begin 0 until loops, so I’m guessing it’s related.
thens resolves any unresolved ifs
• Is delms a built-in to delay for the milliseconds on the stack?
1000 delms
is a delay for 1000 milliseconds, so yes.
• Are the words pinin, pinout, pinlo, and pinhi built-ins for pin control? If so their functions are pretty obvious.
Yes, these are in the propforth.htm manual which will get anyone up to speed , but unfortunately only 5% of people read. We are working on a comic book format the should make it easier for more folks to read (if the comic book is interesting of its own merit) in any case its fun to work with writers and artists.
• Are the words cogstop, cogreset, and cogx built-ins for cog control? If so I assume cogstop stops a cog, but cogreset and cogx are confusing to me. I think cogx tells a cog to run a word.
Pretty much, these are also in the manual.
• Also why c" rc_lwheel" instead of an execution token to the word?
Must ask Nick directly, I didn't try it yet. Too busy with the workshops.
Little robot control language questions.
• There are two versions of NickLordi’s robot language at https://code.google.com/p/propforth/downloads/list. They are NickLordiRobotControlLanguage-LittleRobot20130523-PfrcLitbot_2.txt and NickLordiRobotControlLanguage20130520.txt, which one is the best one to use?
I would guess that the newest one would be best, but I haven't tried them, and Nick did not say to remove the old one. I think both of these are waiting for (somebody like you to) review and comment.
• Why the definition of the (PFRCLR ) word. It does nothing, nor is it referenced elsewhere.
• The WTO word seems unused and it’s function is unclear to me. I think it changes the address a constant points to, but I’m not sure what it is for.
• There are a number of unused constants (wcirc, steps, rdiam, tdiam), what was intended by them?
• Why forward and backward velocities? Doesn’t the forward or backwards step count where the direction information is stored?
• What are ldly, rdly, and ci used for?[
• What is the significance of the () in S()?
• What does TC do?
Don't know. Perhaps start a thread on Nick's RCL and maybe some folks will pipe in.
• Why forward and backward step counts instead of signed numbers? What if both values are set?
I didn't do this yet, but I think we can find our way around the room and return to our starting point this way. There's a bunch a ways to do it of course, but this way seems to come up a lot, so it might be a well know technique.
• Why the rc_ prefix on several words?
The prefixes are arbitrary, and are used to mark something. Sal uses underscopes to show that something is used internally, and doesn't make sense on its own; or use in the assembler, and don't make sense at the system level; or are support for a given driver, etc. Nick appears to use rc_ to denote it is part of robot control.
• I understand the intent of rc_rwheel and rc_lwheel, but what does rc_steps do? A header comment would have been helpful here. It is referenced by the Vstart word and an earlier comment mentions that ci is related to velocity.
as opposed to any other use of steps. This is just a guess.
• Comments for ftst, btst, and rtst would be helpful.
Good point. My guess it these are something like forward test and backward test. Some folks just don't like to type, and we end up with too short labels until we rewrite it oursleves.
• In usage do I call START and then other commands?
Typically we have to initialize the drivers and launch them on their individual cogs, then issue commands to the drivers. START may do this, or may do something more complex, like run a script of commands. Again, you are the first to try this, it would be best to ask Nick directly.
Suggestion is start a separate thread for RCL, and save your notes on a wiki page and allow folks to read and make comments.
Someone contacted me for help! For the first time, one of the participants from a LittleRobot session sent me an email asking how to get something running!
So far there were two sessions of about ten participants each. There were 20-25 direct participants (if you count the folks that started then dropped, and the replacements); and about 25-50 total, if we include the kids parents (who, by signing up their kids, agreed to help them with the materials). One participant has contacted me less than a week after the session with a question.
This doesn't really tell us anything aside from response rate at this point, but its nice to get the first data point.
Prof, thanks for the answers you gave. I think I did look at the PropForth manual, but I didn't retain it. I'll skim it again. I think you already added me during my first round of FORTH in case I wanted to add any of my gforth to PropForth notes there. But I'm sorry to say I never got around to it.
I'll start a separate thread on the Robot Command Language.
These comments are directed to some of Martin_H's questions.
My main objective in developing the LittleRobot control language was to minimize the typing needed on an android device used to control the robot. The rc commands require values for speed, inches traveled, degrees turned, or seconds. The first table uses four arrays to store and access these values by entering 0 - 9. The second version using only a speed array. The user enters the actual valus of inches, degrees or seconds.
I make it a practice of including a dictionary marker word, in this case (PFRCLR), at the beginning of forth programs.
WTO is a utility which the user can use to change wconstant values without recompiling the program, ie, < new value> WTO <name>.
ldly, dly, ci are system variables. Changing ldly & rdly (1 - 100 ) sets the speed (high - low). This is done using the DLY command.
SPD is used to set the current speed index which is reuired by the G-commands.
I use () (eg, S() ) to indicate that the command accesses an array.
TC (test controller) is a word which accepts 2 indices allowing the user to see how different combinations of right & wheel speeds &
directions affect the robot' motion. Negative numbers mean the wheels will go backwards.
START must be used first to activate the robot.
The driver pc_steps is unnecessary. Wheel velocities can be calculated directly from ldly and rdly.
I will make some changes in the program and add more descriptive details.
NickL, thanks for the reply and the details. I switched to the latest version of your robot control language and got it working on Saturday. On Sunday I was able to couple it with the stock servo library. There's was a cog conflict between the two libraries, but I was able to resolve that. I finished work on the pen holder on Sunday night, so I'm almost finished with my first use of FORTH in a robotics project. Further details on the project will be posted when it's complete, but it wouldn't have been possible without PropForth and your robot control language.
WTO is a utility which the user can use to change wconstant values without recompiling the program, ie, < new value> WTO <name>.
Yes, the fact that changing a constant doesn't change the words that use it is annoying during calibration to say the least. I kept my source on the PC and pasted the constant and the words that referenced it into the terminal. But that's me thinking like a C programmer.
Post mortum of LittleRobot workshop session 1: We tried LittleRobot as a four hour workshop session at Chicago Public Library Harold Washington Center's new Maker Space. The thought was that loading the software on the PC takes about the time as the download, and there are only three items to download. Assembling the bot takes about ten minutes. So the bulk of the time would be devoted to explanation and experiments.
The session overran the scheduled time. We specified that the participants must bring their own PC and pre-download the software. The library required that we allow use of library equipment. Unfortunately, the library internet security does not allow software to be installed on the library equipment. This cost significant time to address. Later, we discovered the library limits session time, and automatically erases any saved work. Since the timeout was less than the session time, the delays were doubled.
In addition to technical difficulties with the library infrastructure, we found problems with parts in the kit. Previously, we used rubber bands as treads for the wheels, but these tended to slip off. As an alternative, we selected bands cut from bicycle inner tube (per OBC's suggestion). Unfortunately, I selected poorly. Once on, the inner tube works great; but getting them on was the problem. The folks could not stretch the inner tube sufficiently, then hold it from slipping off while the other side is put on. About half the inner tube bands broke or did not make it on the wheels. While we had fun playing with the wheels, it was another major delay.
We had slight delay from users themselves. An older participant did not have reading glasses, and had trouble putting the wires in the correct locations. The dad with elementary school kids and the mom with two middle school kids had to spend extra effort wrangling the kids, but this expected and had minimal impact.
No one completed the assembly at the original session. Of ten participants, zero completed the bot, and only one sent and email asking for help after the session.
With the lessons learned, we offered a follow up session.
The dad with two kids responded no, conflict with prior plans. Three adults repsonded yes and attended. The remainder did not respond or attend.
All three participants were able install the firmware and troubleshoot the assembly, and all three bots we shown to function wirelessly. We discovered that netbooks, which we previously recommended, did not supply enough juice to turn both stepper motors at the same time. Netbook users will have to do stepper trouble shooting sharing a larger laptop, or do it over blue tooth and run the bot from batteries. Only one one participant brought the recommended Ni-MH batteries, but we were able to share to demonstrate all the bots wireless operation.
Overall, we had a 30% completion rate for the original session; and 100% completion for the follow up session. At the follow up, we received good feedback on adjustments to the materials.
Thanks for writing up your experience. Running such an event is a real challenge, and the library's policies didn't help. The LittleRobot project is pretty ambitious to do in a single session. I've built several robots from kits with my son and I think Herbie the mousebot was the only one we completed in a single session.
Ok, it seems like this is still evolving so I might change the title to In Progress again.
The goal is to do the build in LESS than three hours, to leave the last hour for trouble shooting and explorations.
So I guess I should try to fit it in two hours, and let it run past.
Ideas to stream-line the process:
* In advance of the session
a) participants should download the PC software (proptool, teraterm, propforth)
b) participants should install the software (proptool, teraterm)
c) participants should extract the software (propforth)
d) participants should at least try to load the propforth.spin kernel to the quickstart board
Currently, about half do (a), so far none has done (d) in advance. We need to look at changing the instructions so more folks can make it closer to (d).
I've already started pre-configuring the HC06 blue tooth module before each session. The steps are a little touchy the first time through, but after you do one, it take only about four minute to do each additional module. I need to re-arrange the instructions so the HC06 configuration instructions are on a sub page.
* during the session
1) don't wait for every participant to finish every activity. After the PRIMARY activity is demonstrated, (hello word, blinky LED, stepper moving, SR04 measuring, HC06 talking) allow 5 minutes for investigation. Ask to save the remaining activities till play time.
2) save trouble shooting till play tine at the end of the session. This worked well in the follow up session.
Comments
Sal likes your code. He said he could understand it in the time it takes to read it.
Acceleration: Sal mentioned he is not satified with the way he did acceleration, it loses accurratcy when there are a lot of small turns. Thoughts or comments?
http://code.google.com/p/propforth/downloads/detail?name=LittleRobot.scad
These are the bot in the video from post 17
Just had the first opportunity to really read through what you've been doing. As you know, I also have experience working with kids around this age and understand closely what you're going through! Certain kids will understand very well, and it'll be rewarding to see that occur.
Simplify, simplify and simplify again. And dare I suggest that the programming language in 4th grade doesn't matter. What matters is that it's super easy to use, that they can enter very basic commands "GO F, 20 steps" using whatever simple syntax you can make available. The syntax rules must be minimal and directions clear. Make one successful student help another one, too. I imagine you're already taking these steps from the above.
You are commended for sharing. Don't underestimate the impact you are having on these kids because they are quietly identifying their future interests.
Way to go, Doug. I'm replying to your e-mail now and Lauren will figure out how to help with the latest request.
Ken Gracey
Here is clarification on calculating the calibration numbers for wheel radius and body width. Sal just wrote the code, I have to come up with better variable names.
bot.f :
The acrilic wheels are 73mm diameter, so wheel radius is 36.5
The 4x6 inch wide pink foam blocks with wheels are 118.75 mm wide so
The body radius (wheel base/2) = 59.73
body_radius * wheel_radius * pi = _right_cal
59.75 * 36.5 * pi = 6851
The 6x8 inch wide pink foam blocks with wheels are 165 mm wide so
The body radius (wheel base/2) = 82.5
body_radius * wheel_radius * pi = _right_cal
82.5 * 36.5 * pi = 9469
First Robotics advised me that the youngest that can be expected to be successful are high school juniors and seniors;
First Lego League advised that the youngest that can be expected to be successful are seventh and eighth graders (so I tried a group of sixth graders and they succeded).
This time I asked for sixth and seventh graders (I didn't want to push my luck). Turns out that by not paying attention to the actual ages, I just assumed they were old enough to succede, and they have. The third and fourth graders are in the class most often (perhaps thay have not learn how to escape to the playgorund) and have shown the most progress.
First thing he noticed was the materials are poorly organized and not suitable for direct consumption by student (go figure).
I told him his role would be to get me feed back on what to change to make it exactly what he has in mind (I currently have no clue what he might possible want).
I wonder if he will take this risk? In exchange for reading the material, and making a few comments, they get the exact materials they have been lacking (for years) for free. He's still unsure if the price is too high. He really has no reason to trust me or belive me, all he's seen is a block of foam with some wheels on it; and a bunch of gibberish on my tablet, which I claim is the robot operating.
So it begins...
http://code.google.com/p/propforth/wiki/GettingStartedLittleRobot
What is your target audience for these? General adult population, high school kids, 4th graders (please don't say 4th graders!
EDIT: Saw your invitation to kibitz in the other thread.
YES please!
OK, this is going to seem wacky to folks that haven't read any of my previous posts.
I THINK I am targeting anyone in the FIRST FOUR HOURS (*) of exploration. This includes elementary school kids (because it might have worked with 3rd and 4th graders) up to Master's Students (because it worked with the Media teacher) up to old geezers (because it worked with the photographer who is my age). This was all in the same class. The fourth graders WILL NEED parents help, they can't read an comprehend like engineers. The materials are intended to get ANYONE up and running quickly.
(*) The elementary school kids took 6 weeks to get through it, Vic took about 2 hours. TIMING is not built into the materials, we have to play that part by ear.
Nutty, but it might work.
The LittleRobot pilot was orginally intended to be a full school year session, running from September 2012 to June 2013. Due to the usual factors, most of the schedule was covercome by events. The session finally started in April 2013, and ended as planned June 2013.
The plan was to teach kids to be engineers. This was changed to "provide a critical event that may inspire further interest". The method used was described to me as the Montessori method, let them play by removing the boring parts.
Ten kits were obtained. We did not determine the class size before hand, we figured we could have one to three students per kit. The 1 student per kit student did better, the three students per kit comleted less of the material The three student groups tended to goof around with each other rather than work together, the one students got direct 1 to 1 mentoring from the instructor and did little goofing around with me eye-balling them the whole time.
The school agreed to provide space, and teachers. The arrangement was that the consultant would initially be on site for the beginning, to get the teascer started, them all interaction would be over the internet, email, video conference, google hang out etc. Unfortunately, the individual hired was intimidated by the rough cut of the material, and bailed out. The session was left with no teacher, and the consultant was on-site for each meeting. The regular school staff that helped out could not be reliied on to "own" the class.
Of the twelve or so kids that passed through the class:
Three showed up every meeting, three times a week. The rest missed at least one session per week.
* Two kits were constructed and tested, passed working, before the last day of class.
* Two kits were constructed and tested, passed working, on the lst day of class.
* Two kits were constructed and tested, but did not make it passed trouble shooting.
* Four kits did not complete construction, due to lack of mentorship, lost of broken parts, or incorrect sconstruction.
So of ten kits, four are working, four are still in peices, and two are in between.
We discovered that at least two of the kids were "special needs"; that is they had a suppot person to tend them one on one throughout the regualr school day. The support person was NOT present at the LittleRobot session. We determined that if the kid need support during the regualr day, the support better bne present for the special session after school. This was a difficult lesson, but now we have hard data to support this.
Windows, Linux, and Sansung android (Galaxy, Nexus) were successful in supporting the software tools and environment, including the bluetooth. Apple OSX was able to run the terminal emulator (CoolTerm) with much difficulty, and iOS (iPhone, iPad which every kid had) absolutely will NOT work with the blue tooth connection. The one HTC android ALMOST worked, except for the return key. Blackberry also did not support any blue tooth terminal that we could find.
The finding is that given one to one attention at the proper time, third, four, and fifth graders could successfully built the robot and get it programmed. Specify Windows Netbook with Bluetooth (dongle) or Sansung Android.
The desision is to continue this program as an official supported ciriculum.
Plan is to take what we have learned, revist the kits, and fully train the teachers (using the 4 hour workshop version) for next fall. After building the kits, the kids will persue programming. The plan is to start with auto calibration, and move to something like simple autonomous navigation or obsticale detection and collision avoidance.
1) train the teachers to build the bot before the regular class
2) eliminate all parts that require prefabrication.
3) ensure the kids all have a non iOS blue tooth device. Make them find and bring bluetooth dongle if needed.
4) have the kids bring in a wind-up alarm clock, either broken or from the thrift shop.
5) ensure the computers are present, setup, and working before class starts. We went two weeks with only my laptop.
6) ensure there is a teacher present at all times.
7) if a key element (teacher, laptops, power, internet, parts) is missing, class is canceled until restored.
8) school provides a storage box and storage for each kit. Keeping all the parts in one big box does not work nicely.
9) budget for 20% spares for loss or breakage. This might be partially solved by #8
#4 is because at least one (probably all) the kids had never turned a screw with a screwdriver.
Instruction for the broken alarm clock activity would be:
* find a screw- unscrew it; screw it back in.
* find a second screw, unscrew both, screw them both back in to their original spot.
* continue taking off one more part, and putting it back together, until you get stuck or run our of parts.
Taking apart a broken clock, and finding it worked after I put it back together, got me started.
The lack of documentation on the robot control language was holding me back a bit. I plan to reverse engineer the Forth to understand what is going on, but are there any examples of usage? I was poking around the code repository and didn't see any.
Please ask questions, and we will build the documentation according to your questions.
Also, if you reverse engineer instead of asking questions, please post your findings. Lots of folks are in the same boat as us.
The folks were surprised at the depth and "hands on" aspect of the program. They all said they enjoyed it. Youngest was 7 and 9 year old boys with Dad, oldest was retired elementary school teach, she wanted to "catch up with these robots". Half were male, half were female.
All participants loaded PC software, downloaded propforth, burned the kernel to EEprom, did hello world, and Blinky LED. All got the motors to turns, and mounted on the chassis.
Then we ran out of time. Turns out waiting for ALL participants to complete each goal means the slowest holds back the rest. They got the the SR04 and the HC06 connected, but we didn't get the drivers installed. NEXT time, when the FIRST person gets the activity complete, we'll wait 5 minutes, then move on. Folks will complete unfinished activities during troubleshooting, and participants will demonstrate proficiency by helping peers.
We're trying the schedule a follow up session (at now extra cost) so folks can complete the build. 0% complete is not such a useful datapoint, it only says we have poor time management.
Up to now Ive only used PropForth with my CS-101 problems, so I have a few questions on what I think are PropForth built-ins.
In this program I see both the use of if then, and if thens. But I havent seen if thens, how does it differ from if then? I looked in a few FORTH books but havent found anything. Although it is only used within begin 0 until loops, so Im guessing its related.
Is delms a built-in to delay for the milliseconds on the stack?
Are the words pinin, pinout, pinlo, and pinhi built-ins for pin control? If so their functions are pretty obvious.
Are the words cogstop, cogreset, and cogx built-ins for cog control? If so I assume cogstop stops a cog, but cogreset and cogx are confusing to me. I think cogx tells a cog to run a word.
Also why c" rc_lwheel" instead of an execution token to the word?
Little robot control language questions.
There are two versions of NickLordis robot language at https://code.google.com/p/propforth/downloads/list. They are NickLordiRobotControlLanguage-LittleRobot20130523-PfrcLitbot_2.txt and NickLordiRobotControlLanguage20130520.txt, which one is the best one to use?
Why the definition of the (PFRCLR ) word. It does nothing, nor is it referenced elsewhere.
The WTO word seems unused and its function is unclear to me. I think it changes the address a constant points to, but Im not sure what it is for.
There are a number of unused constants (wcirc, steps, rdiam, tdiam), what was intended by them?
Why forward and backward step counts instead of signed numbers? What if both values are set?
Why forward and backward velocities? Doesnt the forward or backwards step count where the direction information is stored?
What are ldly, rdly, and ci used for?
Why the rc_ prefix on several words?
I understand the intent of rc_rwheel and rc_lwheel, but what does rc_steps do? A header comment would have been helpful here. It is referenced by the Vstart word and an earlier comment mentions that ci is related to velocity.
What is the significance of the () in S()?
What does TC do?
Comments for ftst, btst, and rtst would be helpful.
In usage do I call START and then other commands?
thens resolves any unresolved ifs
1000 delms
is a delay for 1000 milliseconds, so yes.
Yes, these are in the propforth.htm manual which will get anyone up to speed , but unfortunately only 5% of people read. We are working on a comic book format the should make it easier for more folks to read (if the comic book is interesting of its own merit) in any case its fun to work with writers and artists.
Pretty much, these are also in the manual.
Must ask Nick directly, I didn't try it yet. Too busy with the workshops.
I would guess that the newest one would be best, but I haven't tried them, and Nick did not say to remove the old one. I think both of these are waiting for (somebody like you to) review and comment.
Don't know. Perhaps start a thread on Nick's RCL and maybe some folks will pipe in.
I didn't do this yet, but I think we can find our way around the room and return to our starting point this way. There's a bunch a ways to do it of course, but this way seems to come up a lot, so it might be a well know technique.
The prefixes are arbitrary, and are used to mark something. Sal uses underscopes to show that something is used internally, and doesn't make sense on its own; or use in the assembler, and don't make sense at the system level; or are support for a given driver, etc. Nick appears to use rc_ to denote it is part of robot control.
as opposed to any other use of steps. This is just a guess.
Good point. My guess it these are something like forward test and backward test. Some folks just don't like to type, and we end up with too short labels until we rewrite it oursleves.
Typically we have to initialize the drivers and launch them on their individual cogs, then issue commands to the drivers. START may do this, or may do something more complex, like run a script of commands. Again, you are the first to try this, it would be best to ask Nick directly.
Suggestion is start a separate thread for RCL, and save your notes on a wiki page and allow folks to read and make comments.
So far there were two sessions of about ten participants each. There were 20-25 direct participants (if you count the folks that started then dropped, and the replacements); and about 25-50 total, if we include the kids parents (who, by signing up their kids, agreed to help them with the materials). One participant has contacted me less than a week after the session with a question.
This doesn't really tell us anything aside from response rate at this point, but its nice to get the first data point.
I'll start a separate thread on the Robot Command Language.
My main objective in developing the LittleRobot control language was to minimize the typing needed on an android device used to control the robot. The rc commands require values for speed, inches traveled, degrees turned, or seconds. The first table uses four arrays to store and access these values by entering 0 - 9. The second version using only a speed array. The user enters the actual valus of inches, degrees or seconds.
I make it a practice of including a dictionary marker word, in this case (PFRCLR), at the beginning of forth programs.
WTO is a utility which the user can use to change wconstant values without recompiling the program, ie, < new value> WTO <name>.
ldly, dly, ci are system variables. Changing ldly & rdly (1 - 100 ) sets the speed (high - low). This is done using the DLY command.
SPD is used to set the current speed index which is reuired by the G-commands.
I use () (eg, S() ) to indicate that the command accesses an array.
TC (test controller) is a word which accepts 2 indices allowing the user to see how different combinations of right & wheel speeds &
directions affect the robot' motion. Negative numbers mean the wheels will go backwards.
START must be used first to activate the robot.
The driver pc_steps is unnecessary. Wheel velocities can be calculated directly from ldly and rdly.
I will make some changes in the program and add more descriptive details.
NickL
Since I'm a novice FORTH programmer would you elaborate on how this is helpful?
Yes, the fact that changing a constant doesn't change the words that use it is annoying during calibration to say the least. I kept my source on the PC and pasted the constant and the words that referenced it into the terminal. But that's me thinking like a C programmer.
Thanks, that makes it more understandable.
The session overran the scheduled time. We specified that the participants must bring their own PC and pre-download the software. The library required that we allow use of library equipment. Unfortunately, the library internet security does not allow software to be installed on the library equipment. This cost significant time to address. Later, we discovered the library limits session time, and automatically erases any saved work. Since the timeout was less than the session time, the delays were doubled.
In addition to technical difficulties with the library infrastructure, we found problems with parts in the kit. Previously, we used rubber bands as treads for the wheels, but these tended to slip off. As an alternative, we selected bands cut from bicycle inner tube (per OBC's suggestion). Unfortunately, I selected poorly. Once on, the inner tube works great; but getting them on was the problem. The folks could not stretch the inner tube sufficiently, then hold it from slipping off while the other side is put on. About half the inner tube bands broke or did not make it on the wheels. While we had fun playing with the wheels, it was another major delay.
We had slight delay from users themselves. An older participant did not have reading glasses, and had trouble putting the wires in the correct locations. The dad with elementary school kids and the mom with two middle school kids had to spend extra effort wrangling the kids, but this expected and had minimal impact.
No one completed the assembly at the original session. Of ten participants, zero completed the bot, and only one sent and email asking for help after the session.
With the lessons learned, we offered a follow up session.
The dad with two kids responded no, conflict with prior plans. Three adults repsonded yes and attended. The remainder did not respond or attend.
All three participants were able install the firmware and troubleshoot the assembly, and all three bots we shown to function wirelessly. We discovered that netbooks, which we previously recommended, did not supply enough juice to turn both stepper motors at the same time. Netbook users will have to do stepper trouble shooting sharing a larger laptop, or do it over blue tooth and run the bot from batteries. Only one one participant brought the recommended Ni-MH batteries, but we were able to share to demonstrate all the bots wireless operation.
Overall, we had a 30% completion rate for the original session; and 100% completion for the follow up session. At the follow up, we received good feedback on adjustments to the materials.
The goal is to do the build in LESS than three hours, to leave the last hour for trouble shooting and explorations.
So I guess I should try to fit it in two hours, and let it run past.
Ideas to stream-line the process:
* In advance of the session
a) participants should download the PC software (proptool, teraterm, propforth)
b) participants should install the software (proptool, teraterm)
c) participants should extract the software (propforth)
d) participants should at least try to load the propforth.spin kernel to the quickstart board
Currently, about half do (a), so far none has done (d) in advance. We need to look at changing the instructions so more folks can make it closer to (d).
I've already started pre-configuring the HC06 blue tooth module before each session. The steps are a little touchy the first time through, but after you do one, it take only about four minute to do each additional module. I need to re-arrange the instructions so the HC06 configuration instructions are on a sub page.
* during the session
1) don't wait for every participant to finish every activity. After the PRIMARY activity is demonstrated, (hello word, blinky LED, stepper moving, SR04 measuring, HC06 talking) allow 5 minutes for investigation. Ask to save the remaining activities till play time.
2) save trouble shooting till play tine at the end of the session. This worked well in the follow up session.
-