Thanks! Updated fastload wiki page with Dave's explanation. Sorry, I always though it buffered to cog ram; maybe it used to or maybe I never understood it properly.
There's no "unused" but there is a word "free" which indicates free hub ram and cog longs
Its not unusual to have to go through tech support; if you call Red Hat you don't talk to Linus Torvolds, and it you call microsoft you don't get Bill Gates and if you call Apple you don't get the dead guy. In our case, though, folks often talk directly to Sal. Usually via issues, about issues, and the conversation usually stops after the issue is resolved. I handle everything else as best I can.
Previous frame of POV-II was too light.
So, I re-made it.
I also replaced motor-power.
I use (only)5V of micrATX-PS, because previous was poor(current).
So, duty become low.
Now rotation is 800rpm.
It seems there is flicker yet, because image per 1second is 13.
I think minimum speed need 1440rpm(image per 1second is 24).
But this frame cause vibration exceeding 950rpm.
Needing more weight.
And also control for rotation speed.
: demo
\ Setup pwm
28 setDuty
c" pwm" 0 cogx
buffer d416 0 do dup 0 swap W! 2+ loop drop
begin rot_T d80 < until
c" PropForth5.5" disp_str_drum
c" dispDrum" 1 cogx
d13000 delms
1 cogreset
c" May the Forth be with you" disp_str_drum
c" dispDrum" 1 cogx
;
That's pretty cool! It looks a little dangerous too!
Needing more weight.
I thought the method was to make the rotor as light as possible, and very balanced, and it would reduce or eliminate vibration. How are you balancing the rotor? The jet engine guys say we just spin it in our fingers and feel where the heavy spot is.
I think this frame is safe at 800rpm.
Drum has LED-driver-board(30gram) on edge of circle refering #177 photo.
Other 2motors(30gram) on edge of circle are balancer.
Maybe centrifugal force is big, because a center of balance is not center.
I'm going to entrench frame on desk.
By the way, I think Nick had written PID-control.
Where is that pdf?
I need to use P or PI control on motor.
Hi.
I'm going to write PID-code.
Yet only P-control.
Target rpm is 500.
When Kp is big, there is overshoot.
When Kp is small, it don't reach at 500rpm.
LED-drum need PI-control.
I think it do'nt need D-control.
In case of balancing robot, it should need PID-control.
LittleRobot was presented to two local towns, both expressed interest in long term projects.
I managed to source wheels from a local guy. Eddy Wright of Wright Hobbies will supply me with CNC cut wheels in exchange for putting his bisuness card in the kit. Wright Hoobies gets common and hard to find key parts for the Chibots.org robot club here, so Eddy feels this is targeted advertising money well spent.
We added two university students to the team. They are tasked with translating the Propforth and LittleRobots material from geezer-speak to kid-speak.
I'm working on QSbot.f. This is a revised wiki page that includes a test diagnostic for each part as it is added to the bot during build. It also uses the QS LED pins to display the last SR04 distance measurement; this really demonstates how readings can be good or noisy, and gives insights for to take advantage of the noisy readings.
Sal is surprised at the response to LittleRobot, he knew there was a need but didn't think it was this big. He's also surprised at the slow speed of requests for new software. I don't anticipate requests for software until the "build" session has been refined and executed a few more times. Must prepare in case it takes off like Sal expects.
MORE ON 'fl' ISSUES: We still have not gotten to a reproducable error on fastload. Recall that Loopy had multiple errors, one of which was "too many characters for the buffer" and was solved by removing excessive white space. The other issue comes and goes. This issue is where we have to hit an additional CR to end the cog5 portion of the load. Sometimes the load ends properly, sometimes the load corrupts the filesystem.
Suspected Cause: fl requires 'cr' at the end of each line. WHEN PASTING FROM A WEB PAGE, the browser or something else may generate non printable character codes, or may omit some 'CR' due to wrapping, or both, or something else weirder. I believe I have almost isolated the issue, the same text pastes from a text editor but has errors from web page.
Diagnostic: Sal has developed a whole debugging and monitoring function built into the Goterm on PF6. Once I get the issue isolated, he has a tool that can try to identify the exact nature of the issue.
Solution: The temporary fix is to copy the example source code from the web page into a text editor; modify and copy paste from the editor rather than directly from the browser window. A permanent fix will be developed as we learn more.
Schedule: Sal will be traveling in August. End of September might see the beta for PF6 out for test. We'll send the beta to the regular team and the new volenteers. The automation will now run on any prop, and the parts that test custom hardware are not required. If we can simplify setting up the Go support on the PC side, it should open up the automation to more folks. As always, beta test volenteers are welcome.
RPM is constant 490 under P-control.
RPM is controled at 500 under PI-control.
But microATX-PS's 5Voutput sometimes shift up and down(5V->5.32V->5V->4.87V->5V).
Same as RPM.
This microATX-PS removed from junkPC.
Next, RPM shift a little around 500 under PID-control.
I don't understand PID well.
I will write codes again after studying PID.
That's a good idea. Did you notice any content change, or is the scope of changes limited to format clean up?
What can we do to move it from draft to release?
I removed the 1 second delay word as that doesn't seem to exist any longer.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you want to change it and remove PRELIMINARY from the text, just use Windows Office (if that will work) or download a free copy of Libre Office and install (has Linux, Windows, and Apple versions) and do whatever you want in that software... it also Exports to PDF, which is very handy for final versions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I moved a heck of a lot around so that it is easier for the eye to follow.
I already see that I forgot to change the total pages to 12, and there are NOT 13. >>> corrected below
And, there was some clarification of language that was entirely editorial on my part.
What this really, really needs is to have the whole format is a 2 or 3 column table as it would be much easier to have clean alignments. That should have been done in the beginning as going back and doing it is an awfully tedious pursuit. The same problem exists in the PropForth manual.
I suppose the whole file could be leveled in Linux with the excellent Unix utilities and then rebuilt to have good tables.... but it takes a bit of thought, a bit of research, and a bit of design.
FOR NOW, this will be a bit easier to use. Have done a bit more clean up ... see below.
ok, I posted it in the download section and left the preliminary in the title. I'll have the college kids read it and make more comments. And maybe figure out a way to post it as a wiki page.
Yes, I think it could use some good old peer review rather than just having me remove the preliminary and say 'done'. I can't be sure that all 12 pages are right... so much material.
I tried shifting everything into column tables today and so far that is a lot of tedious mousing around. I could take several 8 hour days of fooling around unless I figure an automated way to do it.
But once this is shifted into actually 3 columns: first for your / and //, the second for the name and ( stack info), and the third for the explanation --- editing would not mess up the columnar formatting... it would stay cleaner.
We closed issue 198 as PerDesign. Recall there were too many characters for the buffer. We also talked a little more about "memory map" and creating a table in memory. The way to do this in propforth is to define the table as something in the dictionary. To do this OUTSIDE of propforth, redefine the kernel and do whatever you want. A third option is briefly described in http://code.google.com/p/propforth/wiki/PropForthDictionaryStructure
We discussed issue 200. "Add37" gives no stack error. This is a really cool discussion. It boils down to the stack errors are not evaluated until an item is pushed on or popped off the stack, and the top of stack is buffered and is a special register that uses single byte assembler extensions. This is a design decision that has been present in all versions of propforth since spin forth, and has never been detected as an issue, because the "error condition" doesn't happen in a real world application, only in this very arbitrary test. A more reasonable test would be
: .add37 37 + . ;
which does yeild the stack underflow error, as it also pops the result off the stack. Its actually quite complex, and the kernel is doing exactly what is expected per the design. Sal is looking to see what he should do about it, if anything. Considering that this has been the design for five years, and noone has flagged it until now, a detailed expalnation may be all thts required. Sal want to be really careful before changing anything, as we need to understand fully why a change would be better.
Issue 202 - The android application GREEN is already self signed. Turns out we can just email it to ourself, and when we open the email on and android phone, it should just ask us if we want to install it. It does, but on my capivate glide, both the package installer and the verify and install options give a problem parsing package message. EDIT - turns out this was a DERP error. Green requires android 3.0 or higher, my captivate glide is android 2.3.6. Probably why I didn't do it when I installed on the Nexus 10!
Turns out it was totally simple to fix, all I had to do was wait until Samsung rolled out android 4.0.4 for the Galaxy family.
If you have an HC05 or HC06, or any way to establish a blue tooth serial terminal connection to your prop rig, you can install GREEN and have a user definable touch button interface.
1500 rpm? maybe be a little dangerous.
Autos and motorcycles go up to about 7000 rpm.
I have a router here than cuts at 20,000 rpm with carbine bits, and can quickly send you to the ER if you are not careful.
The higher the rpm, the more you should make sure everything is tight... motor mounts, shaft linkage, gears, belts, etc. And try wearing gogels. Safety First.
Updated PID_test.
Speed can't control well yet.
it seems that working accuracy of frame is not good.
it seems that upper side frame(slip-ring) is vibrating when rotating.
I think this vibration disturb smooth rotating.
We're working on refining the instructions. We have a couple of college kids translating from "greezer-speak" into "kid-speak". I'm not allowed to look at it until the draft is finished, but Doctore says its looking good so far. The next task is to entice people to actually read the instructions. The data says only 5% read the instructions, the goal is 95%. SO. First rule of thumb is no single part should be longer than five minutes. Inspired by Ikea assembly instructions, we are going to attempt to make a comic book. I've introduced the college kids to an illustrator. I always find comic books more interesting when there is an actual story; how can we make a story out of building the bot, without being totally boring? We might have to find a writer.
Sal is interested in the Hubsan x4 H107 quad copter, as are the kids. The LittleRobot upgrade path was originally planned to END with a copter. H107 may move closer to the front of the list.
We discussed Phil's PROPetual Motion thread. Sal did experiments a while back, and abandonded these due to the stability issues. Now it seems the requirements don't demand stability per se, we just want to talk to and control the bot. This may be part of upcoming work.
Talked to venture capitol people this week. Looks like we will NOT have a chance to see if success will spoil the LittleRobot just yet. What a relief! They were disappointed that the kit only builds one robot. Rather than a bunch of loose parts in a zip lock bag, they expect a finished product in a fancy box. They invited me to come back next year, should I resolve the "finished product vs kit" conflict.
It seems conversion is stable although I use breadboard.
I found mistake.
Please add 1word.
: a/d_VR
c" result d4095 6 a_1pin_sigma_delta_A/D" 0 cogx
cnt COG@ 100msec +
begin
result L@ . cr
100msec waitcnt
fkey? swap drop until
drop <-------------------------------- adding word
0 cogreset
;
The college kids finished the draft of instructions translated into "kid-speak". Doctore says its good, we have to determine if we want to try it out at the next LittleRobot workshop, and/or send it on to the illustrators and writers. We really need someone with actual experience creating comic books. Can someone put me in contact with Stan Lee?
The LittleRobot development is almost complete, we started considering upgrades. Any upgrade should demonstrate additional driver techniques.
* We started discussing bigger steppers and drivers, and ended looking at brushless DC airplane motor + ESC. Some may be equipped with feedback circuit, so we could count AC pulses and do some type of presion control.
* Slotted wheels and a phototransistor for quadrature detection were also discussed.
* Servos would also demonstrate PWM, we might try a spider bot.
* DC motor + servo might lead to HOG wheels, but I'm getting too far ahead of myself. HOG wheels is a direction I'd like to persue.
* The college kids are still excited about the $50 quadcopters. We may use the $29 10DOF IMU as a sensor upgrade.
The planning phase for the LittleRobot upgrades will take some time. Comments/suggestions?
Sal leaves on vactaion today, and September will be busy with non-prop activities. We won't be expecting PF6 until end of October.
We talked about the "1 cog chip" thread, and the "more than 8 cog" thread. We don't know of many applications that use all the resources of the prop efficiently. Lets says we have a sensor that we want to read every 10ms, and we have 30 sensors, and processiong is more complex than stuffing the reading into memory. Also a bunch of motors/accutators to control. PF6 will allow us to run all the "tasks" in the background, and call them as needed with any available resource. The data can then trigger additional processing, and the action propagates on its own. Its a very simple way to flow the data. No more worrying about running out of dedicated cogs, and it should eliminate overhead for multitaskers and load balancing. Its just tasks and free cogs, use what you need as you need it. I'm not sure if I have my head around it properly, but it sounds right from a high level. Is this idea ahead of its time or just crazy? Its been around since the Transputer. In any case its interesting.
I removed the 1 second delay word as that doesn't seem to exist any longer.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you want to change it and remove PRELIMINARY from the text, just use Windows Office (if that will work) or download a free copy of Libre Office and install (has Linux, Windows, and Apple versions) and do whatever you want in that software... it also Exports to PDF, which is very handy for final versions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I moved a heck of a lot around so that it is easier for the eye to follow.
I already see that I forgot to change the total pages to 12, and there are NOT 13. >>> corrected below
And, there was some clarification of language that was entirely editorial on my part.
What this really, really needs is to have the whole format is a 2 or 3 column table as it would be much easier to have clean alignments. That should have been done in the beginning as going back and doing it is an awfully tedious pursuit. The same problem exists in the PropForth manual.
I suppose the whole file could be leveled in Linux with the excellent Unix utilities and then rebuilt to have good tables.... but it takes a bit of thought, a bit of research, and a bit of design.
FOR NOW, this will be a bit easier to use.
Have done a bit more clean up ... see below.
Wow, Loopy!!
I just stumbled across this. What a great contribution. I need to print it out and read through it. Once it's a final, I might need to make laminated reference cards. I need tools like this for all my languages i find more and more slipping through my mind and ending up on the floor where it gets swept under the rug and such.
Prop0 Cog6 ok
Prop0 Cog6 ok
reboot <--- return key
<--- Pushing ESC ley
CON:Prop0 Cog5 RESET - last status: 0 ok <--- Here stops when pushing ESC ley
CON:Prop0 Cog6 RESET - last status: 146 UNKNOWN ERROR <-- Error code change everytime when leaving ESC key.
Is this abnormal?
Everything is normal, the problem is my crappy instructions.
Pushing the ESC key stops it from loading (and looking for) boot.f on the SD.
It also stops initialization of the SD driver. The message(s) just say that the SD is not talking, which is expected, since ESC stopped (some part of) the initialization.
It sounds like you have anew card that has not been initialized, is his correct?
SO, what you want to do is:
Get the card initiaized with the initialization script.
Make a boot.f that is blank or valid or not present
SO, let it boot normally (no ESC)
Run the initialization script. This only need to be done once in the life of the card, I think.
Let me know if this works, I will update the instructions. Are there any instructions already?
Sorry, SDcard didn't be formatted.
After formatted, eroor had gone.
ls
390 usrboot.f
491 .partion-sys/
130 .sdcardinfo
133 sdboot.f
Prop0 Cog6 ok
mountusr
Prop0 Cog6 ok
ls
65667 .partion-usr/
Prop0 Cog6 ok
mountsys
Prop0 Cog6 ok
ls
390 usrboot.f
491 .partion-sys/
130 .sdcardinfo
133 sdboot.f
Prop0 Cog6 ok
Directory inside SD-card is below?
system
usrboot.f
|---.partion-sys/ Nothing inside this directry
|---.sdcardinfo
|---sdboot.f
Comments
http://code.google.com/p/propforth/wiki/flfastload
There's no "unused" but there is a word "free" which indicates free hub ram and cog longs
Its not unusual to have to go through tech support; if you call Red Hat you don't talk to Linus Torvolds, and it you call microsoft you don't get Bill Gates and if you call Apple you don't get the dead guy. In our case, though, folks often talk directly to Sal. Usually via issues, about issues, and the conversation usually stops after the issue is resolved. I handle everything else as best I can.
Previous frame of POV-II was too light.
So, I re-made it.
I also replaced motor-power.
I use (only)5V of micrATX-PS, because previous was poor(current).
So, duty become low.
Now rotation is 800rpm.
It seems there is flicker yet, because image per 1second is 13.
I think minimum speed need 1440rpm(image per 1second is 24).
But this frame cause vibration exceeding 950rpm.
Needing more weight.
And also control for rotation speed.
: demo \ Setup pwm 28 setDuty c" pwm" 0 cogx buffer d416 0 do dup 0 swap W! 2+ loop drop begin rot_T d80 < until c" PropForth5.5" disp_str_drum c" dispDrum" 1 cogx d13000 delms 1 cogreset c" May the Forth be with you" disp_str_drum c" dispDrum" 1 cogx ;http://youtu.be/CLOLSj8tKFA
I thought the method was to make the rotor as light as possible, and very balanced, and it would reduce or eliminate vibration. How are you balancing the rotor? The jet engine guys say we just spin it in our fingers and feel where the heavy spot is.
I think this frame is safe at 800rpm.
Drum has LED-driver-board(30gram) on edge of circle refering #177 photo.
Other 2motors(30gram) on edge of circle are balancer.
Maybe centrifugal force is big, because a center of balance is not center.
I'm going to entrench frame on desk.
By the way, I think Nick had written PID-control.
Where is that pdf?
I need to use P or PI control on motor.
No PDF, its a wiki page.
http://code.google.com/p/propforth/wiki/PID
Would it better to include a PDF too? If one is created, we could post it, I'm a bit swamped at the moment.
I'm going to write PID-code.
Yet only P-control.
Target rpm is 500.
When Kp is big, there is overshoot.
When Kp is small, it don't reach at 500rpm.
LED-drum need PI-control.
I think it do'nt need D-control.
In case of balancing robot, it should need PID-control.
LittleRobot was presented to two local towns, both expressed interest in long term projects.
I managed to source wheels from a local guy. Eddy Wright of Wright Hobbies will supply me with CNC cut wheels in exchange for putting his bisuness card in the kit. Wright Hoobies gets common and hard to find key parts for the Chibots.org robot club here, so Eddy feels this is targeted advertising money well spent.
We added two university students to the team. They are tasked with translating the Propforth and LittleRobots material from geezer-speak to kid-speak.
I'm working on QSbot.f. This is a revised wiki page that includes a test diagnostic for each part as it is added to the bot during build. It also uses the QS LED pins to display the last SR04 distance measurement; this really demonstates how readings can be good or noisy, and gives insights for to take advantage of the noisy readings.
Sal is surprised at the response to LittleRobot, he knew there was a need but didn't think it was this big. He's also surprised at the slow speed of requests for new software. I don't anticipate requests for software until the "build" session has been refined and executed a few more times. Must prepare in case it takes off like Sal expects.
MORE ON 'fl' ISSUES: We still have not gotten to a reproducable error on fastload. Recall that Loopy had multiple errors, one of which was "too many characters for the buffer" and was solved by removing excessive white space. The other issue comes and goes. This issue is where we have to hit an additional CR to end the cog5 portion of the load. Sometimes the load ends properly, sometimes the load corrupts the filesystem.
Suspected Cause: fl requires 'cr' at the end of each line. WHEN PASTING FROM A WEB PAGE, the browser or something else may generate non printable character codes, or may omit some 'CR' due to wrapping, or both, or something else weirder. I believe I have almost isolated the issue, the same text pastes from a text editor but has errors from web page.
Diagnostic: Sal has developed a whole debugging and monitoring function built into the Goterm on PF6. Once I get the issue isolated, he has a tool that can try to identify the exact nature of the issue.
Solution: The temporary fix is to copy the example source code from the web page into a text editor; modify and copy paste from the editor rather than directly from the browser window. A permanent fix will be developed as we learn more.
Schedule: Sal will be traveling in August. End of September might see the beta for PF6 out for test. We'll send the beta to the regular team and the new volenteers. The automation will now run on any prop, and the parts that test custom hardware are not required. If we can simplify setting up the Go support on the PC side, it should open up the automation to more folks. As always, beta test volenteers are welcome.
Two alternatives... the pdf form that will prevent unintended changes and the LibreOffice file for those inspired to improve.
Updated PID_test.
RPM is constant 490 under P-control.
RPM is controled at 500 under PI-control.
But microATX-PS's 5Voutput sometimes shift up and down(5V->5.32V->5V->4.87V->5V).
Same as RPM.
This microATX-PS removed from junkPC.
Next, RPM shift a little around 500 under PID-control.
I don't understand PID well.
I will write codes again after studying PID.
That's a good idea. Did you notice any content change, or is the scope of changes limited to format clean up?
What can we do to move it from draft to release?
Thanks for tackling this. PID is going to on the "need" list soon, the kids are talking about quad copter control.
I removed the 1 second delay word as that doesn't seem to exist any longer.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you want to change it and remove PRELIMINARY from the text, just use Windows Office (if that will work) or download a free copy of Libre Office and install (has Linux, Windows, and Apple versions) and do whatever you want in that software... it also Exports to PDF, which is very handy for final versions.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I moved a heck of a lot around so that it is easier for the eye to follow.
I already see that I forgot to change the total pages to 12, and there are NOT 13. >>> corrected below
And, there was some clarification of language that was entirely editorial on my part.
What this really, really needs is to have the whole format is a 2 or 3 column table as it would be much easier to have clean alignments. That should have been done in the beginning as going back and doing it is an awfully tedious pursuit. The same problem exists in the PropForth manual.
I suppose the whole file could be leveled in Linux with the excellent Unix utilities and then rebuilt to have good tables.... but it takes a bit of thought, a bit of research, and a bit of design.
FOR NOW, this will be a bit easier to use.
Have done a bit more clean up ... see below.
ok, I posted it in the download section and left the preliminary in the title. I'll have the college kids read it and make more comments. And maybe figure out a way to post it as a wiki page.
I tried shifting everything into column tables today and so far that is a lot of tedious mousing around. I could take several 8 hour days of fooling around unless I figure an automated way to do it.
But once this is shifted into actually 3 columns: first for your / and //, the second for the name and ( stack info), and the third for the explanation --- editing would not mess up the columnar formatting... it would stay cleaner.
We closed issue 198 as PerDesign. Recall there were too many characters for the buffer. We also talked a little more about "memory map" and creating a table in memory. The way to do this in propforth is to define the table as something in the dictionary. To do this OUTSIDE of propforth, redefine the kernel and do whatever you want. A third option is briefly described in http://code.google.com/p/propforth/wiki/PropForthDictionaryStructure
We discussed issue 200. "Add37" gives no stack error. This is a really cool discussion. It boils down to the stack errors are not evaluated until an item is pushed on or popped off the stack, and the top of stack is buffered and is a special register that uses single byte assembler extensions. This is a design decision that has been present in all versions of propforth since spin forth, and has never been detected as an issue, because the "error condition" doesn't happen in a real world application, only in this very arbitrary test. A more reasonable test would be
: .add37 37 + . ;
which does yeild the stack underflow error, as it also pops the result off the stack. Its actually quite complex, and the kernel is doing exactly what is expected per the design. Sal is looking to see what he should do about it, if anything. Considering that this has been the design for five years, and noone has flagged it until now, a detailed expalnation may be all thts required. Sal want to be really careful before changing anything, as we need to understand fully why a change would be better.
Issue 202 - The android application GREEN is already self signed. Turns out we can just email it to ourself, and when we open the email on and android phone, it should just ask us if we want to install it. It does, but on my capivate glide, both the package installer and the verify and install options give a problem parsing package message. EDIT - turns out this was a DERP error. Green requires android 3.0 or higher, my captivate glide is android 2.3.6. Probably why I didn't do it when I installed on the Nexus 10!
http://code.google.com/p/propforth/wiki/AndroidGREEN
Turns out it was totally simple to fix, all I had to do was wait until Samsung rolled out android 4.0.4 for the Galaxy family.
If you have an HC05 or HC06, or any way to establish a blue tooth serial terminal connection to your prop rig, you can install GREEN and have a user definable touch button interface.
This might be kind of big.
Speed is 1200rpm.
1500rpm is a littele dangerous.
http://youtu.be/lkyIA-oiZHg
Dude, you're scaring me
1500 rpm? maybe be a little dangerous.
Autos and motorcycles go up to about 7000 rpm.
I have a router here than cuts at 20,000 rpm with carbine bits, and can quickly send you to the ER if you are not careful.
The higher the rpm, the more you should make sure everything is tight... motor mounts, shaft linkage, gears, belts, etc. And try wearing gogels. Safety First.
Speed can't control well yet.
it seems that working accuracy of frame is not good.
it seems that upper side frame(slip-ring) is vibrating when rotating.
I think this vibration disturb smooth rotating.
We're working on refining the instructions. We have a couple of college kids translating from "greezer-speak" into "kid-speak". I'm not allowed to look at it until the draft is finished, but Doctore says its looking good so far. The next task is to entice people to actually read the instructions. The data says only 5% read the instructions, the goal is 95%. SO. First rule of thumb is no single part should be longer than five minutes. Inspired by Ikea assembly instructions, we are going to attempt to make a comic book. I've introduced the college kids to an illustrator. I always find comic books more interesting when there is an actual story; how can we make a story out of building the bot, without being totally boring? We might have to find a writer.
Sal is interested in the Hubsan x4 H107 quad copter, as are the kids. The LittleRobot upgrade path was originally planned to END with a copter. H107 may move closer to the front of the list.
We discussed Phil's PROPetual Motion thread. Sal did experiments a while back, and abandonded these due to the stability issues. Now it seems the requirements don't demand stability per se, we just want to talk to and control the bot. This may be part of upcoming work.
Talked to venture capitol people this week. Looks like we will NOT have a chance to see if success will spoil the LittleRobot just yet. What a relief!
String moving speed(To Left and To Right) is variable.
http://youtu.be/_NKGd3qUdlo
I translated Single Pin Sigma Delta ADC Driver v1 to Propforth.
Really only translating.
http://forums.parallax.com/showthread.php/149185-DEMO-Single-Pin-Sigma-Delta-ADC-Driver-v1
It seems conversion is stable although I use breadboard.
I found mistake.
Please add 1word.
: a/d_VR c" result d4095 6 a_1pin_sigma_delta_A/D" 0 cogx cnt COG@ 100msec + begin result L@ . cr 100msec waitcnt fkey? swap drop until drop <-------------------------------- adding word 0 cogreset ;Thanks for doing this. I've been meaning to to try Sigma Delta since day 1.
http://youtu.be/H-OHdAXYfro
The college kids finished the draft of instructions translated into "kid-speak". Doctore says its good, we have to determine if we want to try it out at the next LittleRobot workshop, and/or send it on to the illustrators and writers. We really need someone with actual experience creating comic books. Can someone put me in contact with Stan Lee?
The LittleRobot development is almost complete, we started considering upgrades. Any upgrade should demonstrate additional driver techniques.
* We started discussing bigger steppers and drivers, and ended looking at brushless DC airplane motor + ESC. Some may be equipped with feedback circuit, so we could count AC pulses and do some type of presion control.
* Slotted wheels and a phototransistor for quadrature detection were also discussed.
* Servos would also demonstrate PWM, we might try a spider bot.
* DC motor + servo might lead to HOG wheels, but I'm getting too far ahead of myself. HOG wheels is a direction I'd like to persue.
* The college kids are still excited about the $50 quadcopters. We may use the $29 10DOF IMU as a sensor upgrade.
The planning phase for the LittleRobot upgrades will take some time. Comments/suggestions?
Sal leaves on vactaion today, and September will be busy with non-prop activities. We won't be expecting PF6 until end of October.
We talked about the "1 cog chip" thread, and the "more than 8 cog" thread. We don't know of many applications that use all the resources of the prop efficiently. Lets says we have a sensor that we want to read every 10ms, and we have 30 sensors, and processiong is more complex than stuffing the reading into memory. Also a bunch of motors/accutators to control. PF6 will allow us to run all the "tasks" in the background, and call them as needed with any available resource. The data can then trigger additional processing, and the action propagates on its own. Its a very simple way to flow the data. No more worrying about running out of dedicated cogs, and it should eliminate overhead for multitaskers and load balancing. Its just tasks and free cogs, use what you need as you need it. I'm not sure if I have my head around it properly, but it sounds right from a high level. Is this idea ahead of its time or just crazy? Its been around since the Transputer. In any case its interesting.
Wow, Loopy!!
I just stumbled across this. What a great contribution. I need to print it out and read through it. Once it's a final, I might need to make laminated reference cards. I need tools like this for all my languages i find more and more slipping through my mind and ending up on the floor where it gets swept under the rug and such.
THANK YOU!!
I try to install SDkernel.
But it can't.
I wrote V5.5/CurrentRelease/PropForthSD/SDkernel.spin by proptool
I changed cd/di/clk/do pin number to suite my protoboard.
Next I conected to TeraTerm.
Prop0 Cog6 ok Prop0 Cog6 ok reboot <--- return key <--- Pushing ESC ley CON:Prop0 Cog0 RESET - last status: 0 ok CON:Prop0 Cog1 RESET - last status: 0 ok CON:Prop0 Cog2 RESET - last status: 0 ok CON:Prop0 Cog3 RESET - last status: 0 ok CON:Prop0 Cog4 RESET - last status: 0 ok CON:Prop0 Cog5 RESET - last status: 0 ok <--- Here stops when pushing ESC ley CON:Prop0 Cog6 RESET - last status: 146 UNKNOWN ERROR <-- Error code change everytime when leaving ESC key. Prop0 Cog6 RESET - last status: 146 UNKNOWN ERROR Prop0 Cog6 ok (version) .cstr PropForth v5.5 2013Feb20 11:30 0Prop0 Cog6 okIs this abnormal?
Everything is normal, the problem is my crappy instructions.
Pushing the ESC key stops it from loading (and looking for) boot.f on the SD.
It also stops initialization of the SD driver. The message(s) just say that the SD is not talking, which is expected, since ESC stopped (some part of) the initialization.
It sounds like you have anew card that has not been initialized, is his correct?
SO, what you want to do is:
Get the card initiaized with the initialization script.
Make a boot.f that is blank or valid or not present
SO, let it boot normally (no ESC)
Run the initialization script. This only need to be done once in the life of the card, I think.
Let me know if this works, I will update the instructions. Are there any instructions already?
Sorry, SDcard didn't be formatted.
After formatted, eroor had gone.
Directory inside SD-card is below?
system
usrboot.f
|---.partion-sys/ Nothing inside this directry
|---.sdcardinfo
|---sdboot.f
user
.partion-usr/ Nothing inside this directry