Good point. I forgot that PropForth doesn't have a few bytes of dictionary space to spare. And also it doesn't support the DOES> word. Maybe Sal will implement it some day so mere mortals can write their own words.
Good point. I forgot that PropForth doesn't have a few bytes of dictionary space to spare. And also it doesn't support the DOES> word. Maybe Sal will implement it some day so mere mortals can write their own words.
This so propforth has the maximum space for user to implement their own words for their own applications. Remember, this is a micro controller with 32k, not a workstation with 8Gig.
Prop0 Cog6 ok
free
15124 bytes free - 176 cog longs free
Prop0 Cog6 ok
At present, propforth has 15,124 bytes free in the hub, and 176 longs in the cogs. This is the full development kernel, a final application can omit the development support and have more resources available.
Duane reported an issue in the software floating point extension, it would not recognize the explicit number base prefixes. Originally this was per requirement; the software float was considered too slow and scaled integer more appropriate, so float was only used from the command line (with the current base) when working out the fixed point integer scaling. Sal has added explicit number base support to the math extensions, as a new requirement for v5.3. Thanks Duane!
We found something interesting in the test automation:
The automatic testing has been failing on my test rig, at the spinneret HTTP tests. We suspect that it may be due the single core single thread 1.6 Ghz CPU on the workstation (if this relic can still be called a workstation), since it does not fail on Sal's quad core workstation. The automation in Go runs lots of threads simultaneously. The suspicion is the underpowered workstation is causing a timing issue. Analysis is in progress.
At present, propforth has 15,124 bytes free in the hub, and 176 longs in the cogs. This is the full development kernel, a final application can omit the development support and have more resources available.
Something doesn't sound right. That's about the same amount of hub space that pfth has free, and it implements all 133 ANS core words, plus something like 35 core ext words, plus a few dozen other ANS words, plus a few Prop words. And pfth is still using 32-bit values for it's word header and word pointers. I may change that to 16-bit pointers at some point, which will probably free up 6 or 7 Kbytes.
Something doesn't sound right. That's about the same amount of hub space that pfth has free, and it implements all 133 ANS core words, plus something like 35 core ext words, plus a few dozen other ANS words, plus a few Prop words. And pfth is still using 32-bit values for it's word header and word pointers. I may change that to 16-bit pointers at some point, which will probably free up 6 or 7 Kbytes.
If it helps, propforth core kernel has 336 words (per propforth.htm) and the devkernel add 105 words. The EEPROM file system adds 25 words to either of those, and the SD support adds another 92 words. So there might be more words implemented in propforth, although whether these extra words add any value is still undetermined.
Also, the common interfaces for I/O, the interfaces for synchronous serial, romless slaves, and support for paged assembler, etc, may have taken inordinate resources. These seemed like a good idea at the time, but had to be integrated into the kernel.
Perhaps you are a brilliant programmer, and pfth has a bright future. Or, your C compiler is efficient and it has a bright future. Or I counted wrong, and have a less than bright future. Or some combination of these.
The item of real importance is can you do what you want to do and are you having fun doing it? If the person that has the most fun wins, then I certainly feel like a winner. If you feel the same, then the world is good.
This is not true. Such statements can only come from a misunderstanding of programming language semantics and compiler implementations.
If constants and variables don't reside in memory someplace, then yes, I totally missed something. This would not be the first time. I will thoroughly clean my brain with Christmas spirits and be ready for proper instruction after the Holiday. I will also order a fresh supply of spirits for additional cleaning at New Year's in case we find I have further misunderstanding.
Merry Christmas, and don't drive if you drive like me!
The LITERAL word can be used to insert constants into Forth words. It compiles the value on the TOS into a literal value. I'm not sure if this is any more efficient than using a constant variable, but it's another way of doing it that can't easily be changed later on.
Somebody did translate tv.spin and graphics.spin to Propforth?
TV is not on the to-do list, its pretty involved and did not seem like a priority at the time. I think it needs tweaks to the kernel otherwise it uses up all the space.
Go for it, Sal might have some insights if you take this on. This might be a good example for creating a custom kernel (which is on the list for documentation but not planned until after the v5.3 public release).
Today we finally debugged my testing errors. Turns out my prop Schmart Board had a marginal solder connection between QFP44 pin 14 (prop I/O p13) and the trace on the board. My test rig is a Schmart board, a breadboard with a bare 44 pin prop chip & some wires and capacitors, and a spinneret board.
(per mygo\V5.3\kernels\doc \ MultiPropReferenceSystemHardware.txt)
These are fastened to a scrap of wood with cable ties. Turns out that knocking this off the work bench onto the floor several times over the course of a year caused the weak connection to fail. Go figure. Reheating the connection and adding a dab of solder seems to have fixed it.
Anyway, this was the final test for the cut over from the old code (5.0 to generate 5.3) to the new code (5.3 to generate 5.3). So it looks like 5.3 has finally passed all tests. Now we just have to deal with the documentation.
Testing is going well. I have run the test suite several times successfully. The kerenel and automation are proving to be vey stable. Occasional errors are detected, but are not reproduceable or repeatable. Its starting to look like the erors are the result of external factors.
* throw: all goroutines are asleep - deadlock!
This is a bug in the go support. Not enough to diagnose. It only happened once, and restarting the windows CMD window fixed it.
* *************ERROR****** TEST/scripts/SnetFsrdSDHTTP.txt::2013-01-04 12:21:10.25 -0600 CST Connecting to ip addr [192.168.0.129:8080] - [dial tcp 192.168.0.129:8080: No connection could be made because the target machine actively refused it.]
This is a problem connecting to the HTTP server on the spinneret. The spinneret is running, but the automation can't connect to it. Re-running the test fixes it. This could be caused by timing, power supply, router, other network issues.
* once the protoboard (main fixture of the automation) would not respond.
This could be due to something happening in the load process, power supply drop out, static glitch, bumping a poor connection, etc. Re-running the automation (which involves re loading the EEPROM image) fixes it.
Most of the errors over the past couple weeks have been associated with the spinneret. The plan is to break out the spinneret, and get closer control over what is going on at each step. Also, we are considering a more solid hardware rig for the testbed: a specific board, correctly designed and assembled, might be get better results than pieces stuck to a scrap of wood held together with cable ties and duct tape. (As the wise mane once said, "If duct tape don't fix it, it might be broke").
The differences between my and Sal's hardware testbeds:
Sal has all the parts mounted on protoboard, with all connections soldered, and short connections to the spinneret. Braino has at least one unsoldered connection on each conductor between boards.
Sal has a dedicated power supply that is specifically size for the test bed; Braino has a single wall wart powering the whole rig
Since these errors only appear on my rig, and not on Sal's, we are going to call these intermittent due to hardware (until proven otherwise), and move forward .
For those following at home, I'm going to run the MakeCurrentRelease.bat script, and run the automation again using those outputs. No changes will be made to the test hardware, so you can duplicate the tests with your same hardware from last cycle.
I think I've got the power supply issues squared away. Now, I only have to finish final testing. There's a couple details of the release process we are ironing out. There may be at least one more step in the process of generating a new release from a successful build.
The questions have to do with the GO language functions that support build automation, and the final script that generates the final version of "current release". This is a two second step, so it might take a week to figure out.
But, Now is the best time to get it sorted out....
We've determined we are only seeing non-kernel issues. These are either releated to the hardware, or are documentation related.
The "GettingStarted.txt" files included in each kernel's sub directory have paths and file names that need to be tweaked. Instead of "PropforthDevKernel.spin" the file will be named "DevKernel.spin". This allows the final kernels to have the same name as the text file used to create it, with out having paragraph sized file names. The "Propforth" with be in the directory name, and all the spin files can be assumed to be propforth. The documentation will be straightened out this week, hopefully we will have an release candidate RC4 by the end of this week.
There was one items that previously was classified as "per design" which we were able to reclassify as an item requiring action. We have long known that moving from one release to another can result in the need to re-initialize the filesystem, the boot.f scripts, and other items. That is, when the new kernel is loaded, it appears to hang because the old files are now "corrupt" in that they don't fit the new kernel, and the kernel got sent off to never-land. Now, we will bring the version string out to a file in the filesystem. If the version strings do not match, the kernel will give a message and gracefully return to the command prompt. Only the boot script needs to change, no kernel code modification is required.
We determined that all the functional issues have been with the hardware configuration, and usually related to power supply. The power issues are always in conjunction with the spinneret, as doing Ethernet actions can draw a bunch of power very quickly. We think the remaining hardware issues indicate that something in the hardware is too complex. We are going to further divide the hardware test bed and the associated scripts. The simple propforth kernel is a development environment optimized for speed and smallest memory foot print. Additional support can be developed in forth, and the high level forth can be optimized in assembler for speed and small footprint, and combined into the kernel. In addition to the simple dev kernel, there are four basic type of propforth kernel:
prop (propforth dev kernel)
prop + eeprom
prop + sd
Prop + multiprop
prop + IP
* prop dev kernel - the default propforth command line development environment. This will run on any prop chip capable of receiving and exacting a valid spin file.
* prop + eeprom : This is any standard prop board able to load and execute spin code. It covers all known boards EXCEPT the demo board, which only has 32K EEPROM. Propforth will still load and function, only th EEPROM file system won't have the upper 32K (of 64K) for files.
* prop + sd : this is any prop system with an SD added. It will also work on the demoboard when an appropriate SD slot is added.
* Prop + multiprop : This is any prop system, with a bare propchip added per MultiPropReferenceSystemHardware.txt.
* prop + IP : This is spinneret or equivalent. The spinneret with a bare prop chip added will be sufficient to run the entire suite
Each kernel will be able to build (using the make.bat script) all the other kernels. The Test.bat scripts will be provided, so any user can run the tests appropriate to their hardware. Not everyone will have a barre prop chip or SD or spinneret, we will have an option to run tests for just the hardware available. This should open custom kernels to more folks.
We also noticed that the configuration for the multiprop material is not in the configuration area of the scripts. This will be moved to the configuration are, so that all configurable items will be in a single location.
The changes to the test bed hardware and configuration item location will trigger one more release after v5.3 with no functional changes to the kernels. All code since v5.0 should still be compatible with no changes to the forth code, and most code from any previous should remain compatible with trivial changes.
Sal is working on the Android interface to propforth for the little robot experiment. Android can be finicky to set up, it is not trivial task for beginners. On the other hand, running java on a webpage is easy. Sal is exploring "editing java webpages" or "java app on android" as a simple way to get the android interface.
Too busy, didn't get the next release candidate generated, hopefully next week or the following. Noticed that the current release is 5.03 (intended to mean that it is part of 5.0 and before 5.1) and that the release we are working on is 5.3 (intended to mean that its after 5.2). But 5.03 and 5.3 could also mean the same thing (derp!). So, the next public release will be 5.4; and the release that includes tweaks to the hardware descriptions should be 5.5.
Sal is working on the interface for the Little Robot demo. The request is for a GUI that runs on a smart phone. Sal is experimenting with an android app that will talk over Bluetooth to the HC-05 Bluetooth serial cable replacement. The app will send text commands (i.e. forth words) to the prop, the forth words will execute on the prop and send be text (i.e. HTML pages). Th smart phone will display the HTML, which can include text, calls to functions that may reside on the phone, and buttons that may send more text (forth code) to the prop.
Today we discussed using HTML to display stuff on the smart phone, and JavaScript to execute stuff on the phone. It turns out that w could use any browser to display the HTML and run the JavaScript, if we have a method to get from the browser to the Bluetooth. And it turns out that we can easily talk from the browser to the smart phone Bluetooth with Go programs. It now looks like an device capable of displaying HTML and executing JavaScript should be able to serve as an interface for the propforth environment and resulting applications.
This might be handy in the area of industrial controls. In any control system, the biggest expense after the control system itself is the user interface, as it usually requires custom implementation of display, keyboard, mouse, general GUI, and all the support that goes with it. Sal might have a method where ANY browser capable device can serve as the GUI, with little or no custom work beyond the control application itself. But, there's zillion ways to try this, the challenge is finding one that is simple and elegant enough to be useful.
Our use case will focus on:
* use a browser as GUI
* execute commands on the target (prop application)
* display results on the GUI (android app/browser)
* modify high level forth on the target (prop)
* modify scripts on the GUI (android app/browser)
We think we can get what we want using HTML and JavaScript, and this may allow any smartphone, tablet, or PC to serve as a generic user interface.
We also talked about maintaining data and code on the prop systems. In propforth, a file is simply a sequence of blocks on the storage media. An old file may be modified, or a new version may be saved. The newest version is the only version visible, the old version still exist, but cannot be directly accessed. We are looking at using an idea from the old VMS file system. Each file will also have a version number associated with it. Each time a file was modified, a new file with a new version number was saved. Normally, we only see the most recent file, but if needed we can choose any previous version by specifying the version number. We would end up with a zillion old version numbers, but we would never see them unless we need to, and on an SD card we would never run out of space in most cases. If needed, the most recent version of each file could be copied to a new SD, and continue from there, allowing the previous SD to be recycled.
The following code is a PropForth version of the PID controller which I plan to include in a PropForth robot control language.
I have not been able to test it yet, but present it here for comment. It is an example where the word TO (using constants as
values) can be effective.
NickL
{
EXPERIMENTAL - Defining a Generic PID Controller
Reference: Digital PID Controllers Dr. Varodon Taochindi 6/2011 www.controlsystemslab.com
PID equation: u(k) = u(k-1) + k1*e(k) + k2*e(k-1) + k3*e(k-2)
where k1 = kp+ki+kd k2 = -kp-2kd k3 = kd ki = kp/Ti kd = kp*Td
Both Ti & Td are defined in terms of sample numbers.
ucorr = u(k) - u(k-1) = Kp*(K1*e0+K2*e1+K3*e2) where Kp = kp*scale
K1Ti = Ti(1+TD)+1 K2 = -(1+2Td) K3 = Td.}
TO is a word which can change the value of a constant, thus, allowing constants to function as
variables. For example: 45 constant try try . 45 165 TO try try . 165
}
: TO ' 4+ L! ;
\ pid parameters
variable e0 \ e(k)
variable e1 \ e(k-1)
variable e2 \ e(k-2)
\ These constants are intended to be used as "values", i.e., their values can be
\ altered, using TO, prior to running the controller.
1 constant Ti
8 constant Td
10 constant K1 \ p: 1
-17 constant K2 \ p: -1
125 constant Kp \ kp*scale
1000 constant scale \ scales Kp
125 constant dt \ millisec sampling time - 8 samples/sec
100 constant uref \ target value of measured parameter (umeas)
: initERR \ ( -- ) sets e0, e1, & e2 to 0
0 e0 L! 0 e1 L! 0 e2 L! ;
\ The following 3 words simpify calulating K1 & K2, eg, cK1pid TO K1.
: cK1pid \ ( -- n1 ) leaves calculated K1 for a pid controller on the stack.
Td 1+ Ti * 1+ ;
: cK1pd \ ( -- n1) leaves calculated K1 for a pd controller on the stack. Set Ti to 1.
Td 1+ ;
: cK2 \ ( -- n1) leaves calculated K2 for a pid\pd controller on the stack.
Td 2* 1+ negate ;
: PID \ ( n1 -- n2 ) n1 is umeas and n2 is ucorr.
e1 L@ e2 L! e0 L@ e1 L!
uref swap - dup e0 L! K1 Ti */
e1 L@ K2 * + e2 L@ Td * + Kp scale */ ;
I didn't realize PID could be so short! It looks almost simple, and a lot less scary than Dr Taochindi's equation 1.
If Sal is back from traveling in time for tomorrow's meeting, I'll run it by him.
I also have to get used to changing constants with TO. It looks like a handy way to do it.
Thanks for your contribution, its very cool as usual.
I hope you don't mind that I start a wiki page for this, there some folks that don't participate on the forums that I want to have look at it. Of course you can edit or change the change as you want.
Attached find two files which define a PropForth Robot Control Language. The first file is the core rcl forth program specifically for the Stingray. The second file is an extension which defines words for user control and an approach to autonomous control.
We have a delay due to hardware: Sal knocked his test rig off the bench a few times too many, it stopped responding. It was only a temporary hack to get by, but ended up carrying us through several full development cycles.
We've brought on a couple more folks to help with user testing, and making sure the user experience is fun. We have discovered that right now the docs in particular are not so fun. This is because we have a conflict: On the one hand, PropForth MUST be a complete system as the primary target is the full-on embedded systems engineer. On the other hand, it must also be simple enough for new and casual users to get up and running and having fun quickly enough so they don't die of boredom before they get enough information to start playing.
In reality, 90% of users will never use anything beyond the simple forth command line on a quickstart. We are now structuring the package to have primarily:
* the GettingStarted instructions
* the PropForthDevKErnel.spin file
* the PropForth.htm technical reference
The rest of the material (extensions, build and test automation, instructions for generating new kernel, assembler optimization, multiprop configurations, Go channel interfaces, etc) will all be present, but out of the way. If someone is interested it will be there, (its still included) but will be such that is won't trip up newcomers.
This is our current goal. Hopefully we make these changes as we scrub the issues lists before release.
Cool bot! I like the way the servo body is also the leg and the foot.
I can't figure what multi-drop servo means. Is it the same as RS-485 multi-drop serial link? That is, is it the same three wires to all servos (power, ground, and control) and each servo has an ID, and instead of a pulse, they recieve an ID code and a position code?
PhantomX AX Quadruped Mark II is far exellent than KMR-P4.
For $949 it better be pretty darn excellent!
I'm working on a cheaper design, that uses micro servos and drinking straws (like the ones from McDonalds) for the frame. If I get to the point where it can support its own weight, I will try it with the quickstart.
Have you tried Nglordi's robot control language yet?
Comments
This so propforth has the maximum space for user to implement their own words for their own applications. Remember, this is a micro controller with 32k, not a workstation with 8Gig.
At present, propforth has 15,124 bytes free in the hub, and 176 longs in the cogs. This is the full development kernel, a final application can omit the development support and have more resources available.
Duane reported an issue in the software floating point extension, it would not recognize the explicit number base prefixes. Originally this was per requirement; the software float was considered too slow and scaled integer more appropriate, so float was only used from the command line (with the current base) when working out the fixed point integer scaling. Sal has added explicit number base support to the math extensions, as a new requirement for v5.3. Thanks Duane!
We found something interesting in the test automation:
The automatic testing has been failing on my test rig, at the spinneret HTTP tests. We suspect that it may be due the single core single thread 1.6 Ghz CPU on the workstation (if this relic can still be called a workstation), since it does not fail on Sal's quad core workstation. The automation in Go runs lots of threads simultaneously. The suspicion is the underpowered workstation is causing a timing issue. Analysis is in progress.
If it helps, propforth core kernel has 336 words (per propforth.htm) and the devkernel add 105 words. The EEPROM file system adds 25 words to either of those, and the SD support adds another 92 words. So there might be more words implemented in propforth, although whether these extra words add any value is still undetermined.
Also, the common interfaces for I/O, the interfaces for synchronous serial, romless slaves, and support for paged assembler, etc, may have taken inordinate resources. These seemed like a good idea at the time, but had to be integrated into the kernel.
Perhaps you are a brilliant programmer, and pfth has a bright future. Or, your C compiler is efficient and it has a bright future. Or I counted wrong, and have a less than bright future. Or some combination of these.
The item of real importance is can you do what you want to do and are you having fun doing it? If the person that has the most fun wins, then I certainly feel like a winner. If you feel the same, then the world is good.
Any way I'll have to skip that debate till after Christmas as communications at my current location are very intermitent.
Merry Christmas Braino and all who have tried to help this poor soul get to grips with Forth.
If constants and variables don't reside in memory someplace, then yes, I totally missed something. This would not be the first time. I will thoroughly clean my brain with Christmas spirits and be ready for proper instruction after the Holiday. I will also order a fresh supply of spirits for additional cleaning at New Year's in case we find I have further misunderstanding.
Merry Christmas, and don't drive if you drive like me!
Somebody did translate tv.spin and graphics.spin to Propforth?
TV is not on the to-do list, its pretty involved and did not seem like a priority at the time. I think it needs tweaks to the kernel otherwise it uses up all the space.
Go for it, Sal might have some insights if you take this on. This might be a good example for creating a custom kernel (which is on the list for documentation but not planned until after the v5.3 public release).
Today we finally debugged my testing errors. Turns out my prop Schmart Board had a marginal solder connection between QFP44 pin 14 (prop I/O p13) and the trace on the board. My test rig is a Schmart board, a breadboard with a bare 44 pin prop chip & some wires and capacitors, and a spinneret board.
(per mygo\V5.3\kernels\doc \ MultiPropReferenceSystemHardware.txt)
These are fastened to a scrap of wood with cable ties. Turns out that knocking this off the work bench onto the floor several times over the course of a year caused the weak connection to fail. Go figure. Reheating the connection and adding a dab of solder seems to have fixed it.
Anyway, this was the final test for the cut over from the old code (5.0 to generate 5.3) to the new code (5.3 to generate 5.3). So it looks like 5.3 has finally passed all tests. Now we just have to deal with the documentation.
Great to know 5.3 requires "only" documents.. :-)
Massimo
Testing is going well. I have run the test suite several times successfully. The kerenel and automation are proving to be vey stable. Occasional errors are detected, but are not reproduceable or repeatable. Its starting to look like the erors are the result of external factors.
- * throw: all goroutines are asleep - deadlock!
This is a bug in the go support. Not enough to diagnose. It only happened once, and restarting the windows CMD window fixed it.- * *************ERROR****** TEST/scripts/SnetFsrdSDHTTP.txt::2013-01-04 12:21:10.25 -0600 CST Connecting to ip addr [192.168.0.129:8080] - [dial tcp 192.168.0.129:8080: No connection could be made because the target machine actively refused it.]
This is a problem connecting to the HTTP server on the spinneret. The spinneret is running, but the automation can't connect to it. Re-running the test fixes it. This could be caused by timing, power supply, router, other network issues.- * once the protoboard (main fixture of the automation) would not respond.
This could be due to something happening in the load process, power supply drop out, static glitch, bumping a poor connection, etc. Re-running the automation (which involves re loading the EEPROM image) fixes it.Most of the errors over the past couple weeks have been associated with the spinneret. The plan is to break out the spinneret, and get closer control over what is going on at each step. Also, we are considering a more solid hardware rig for the testbed: a specific board, correctly designed and assembled, might be get better results than pieces stuck to a scrap of wood held together with cable ties and duct tape. (As the wise mane once said, "If duct tape don't fix it, it might be broke").
The differences between my and Sal's hardware testbeds:
Since these errors only appear on my rig, and not on Sal's, we are going to call these intermittent due to hardware (until proven otherwise), and move forward .
For those following at home, I'm going to run the MakeCurrentRelease.bat script, and run the automation again using those outputs. No changes will be made to the test hardware, so you can duplicate the tests with your same hardware from last cycle.
I wrote driver for 160X64GraphicLCD(DMF-51026NY-LY).
I think I've got the power supply issues squared away. Now, I only have to finish final testing. There's a couple details of the release process we are ironing out. There may be at least one more step in the process of generating a new release from a successful build.
The questions have to do with the GO language functions that support build automation, and the final script that generates the final version of "current release". This is a two second step, so it might take a week to figure out.
But, Now is the best time to get it sorted out....
We've determined we are only seeing non-kernel issues. These are either releated to the hardware, or are documentation related.
The "GettingStarted.txt" files included in each kernel's sub directory have paths and file names that need to be tweaked. Instead of "PropforthDevKernel.spin" the file will be named "DevKernel.spin". This allows the final kernels to have the same name as the text file used to create it, with out having paragraph sized file names. The "Propforth" with be in the directory name, and all the spin files can be assumed to be propforth. The documentation will be straightened out this week, hopefully we will have an release candidate RC4 by the end of this week.
There was one items that previously was classified as "per design" which we were able to reclassify as an item requiring action. We have long known that moving from one release to another can result in the need to re-initialize the filesystem, the boot.f scripts, and other items. That is, when the new kernel is loaded, it appears to hang because the old files are now "corrupt" in that they don't fit the new kernel, and the kernel got sent off to never-land. Now, we will bring the version string out to a file in the filesystem. If the version strings do not match, the kernel will give a message and gracefully return to the command prompt. Only the boot script needs to change, no kernel code modification is required.
We determined that all the functional issues have been with the hardware configuration, and usually related to power supply. The power issues are always in conjunction with the spinneret, as doing Ethernet actions can draw a bunch of power very quickly. We think the remaining hardware issues indicate that something in the hardware is too complex. We are going to further divide the hardware test bed and the associated scripts. The simple propforth kernel is a development environment optimized for speed and smallest memory foot print. Additional support can be developed in forth, and the high level forth can be optimized in assembler for speed and small footprint, and combined into the kernel. In addition to the simple dev kernel, there are four basic type of propforth kernel:
* prop dev kernel - the default propforth command line development environment. This will run on any prop chip capable of receiving and exacting a valid spin file.
* prop + eeprom : This is any standard prop board able to load and execute spin code. It covers all known boards EXCEPT the demo board, which only has 32K EEPROM. Propforth will still load and function, only th EEPROM file system won't have the upper 32K (of 64K) for files.
* prop + sd : this is any prop system with an SD added. It will also work on the demoboard when an appropriate SD slot is added.
* Prop + multiprop : This is any prop system, with a bare propchip added per MultiPropReferenceSystemHardware.txt.
* prop + IP : This is spinneret or equivalent. The spinneret with a bare prop chip added will be sufficient to run the entire suite
Each kernel will be able to build (using the make.bat script) all the other kernels. The Test.bat scripts will be provided, so any user can run the tests appropriate to their hardware. Not everyone will have a barre prop chip or SD or spinneret, we will have an option to run tests for just the hardware available. This should open custom kernels to more folks.
We also noticed that the configuration for the multiprop material is not in the configuration area of the scripts. This will be moved to the configuration are, so that all configurable items will be in a single location.
The changes to the test bed hardware and configuration item location will trigger one more release after v5.3 with no functional changes to the kernels. All code since v5.0 should still be compatible with no changes to the forth code, and most code from any previous should remain compatible with trivial changes.
Sal is working on the Android interface to propforth for the little robot experiment. Android can be finicky to set up, it is not trivial task for beginners. On the other hand, running java on a webpage is easy. Sal is exploring "editing java webpages" or "java app on android" as a simple way to get the android interface.
Too busy, didn't get the next release candidate generated, hopefully next week or the following. Noticed that the current release is 5.03 (intended to mean that it is part of 5.0 and before 5.1) and that the release we are working on is 5.3 (intended to mean that its after 5.2). But 5.03 and 5.3 could also mean the same thing (derp!). So, the next public release will be 5.4; and the release that includes tweaks to the hardware descriptions should be 5.5.
Sal is working on the interface for the Little Robot demo. The request is for a GUI that runs on a smart phone. Sal is experimenting with an android app that will talk over Bluetooth to the HC-05 Bluetooth serial cable replacement. The app will send text commands (i.e. forth words) to the prop, the forth words will execute on the prop and send be text (i.e. HTML pages). Th smart phone will display the HTML, which can include text, calls to functions that may reside on the phone, and buttons that may send more text (forth code) to the prop.
Today we discussed using HTML to display stuff on the smart phone, and JavaScript to execute stuff on the phone. It turns out that w could use any browser to display the HTML and run the JavaScript, if we have a method to get from the browser to the Bluetooth. And it turns out that we can easily talk from the browser to the smart phone Bluetooth with Go programs. It now looks like an device capable of displaying HTML and executing JavaScript should be able to serve as an interface for the propforth environment and resulting applications.
This might be handy in the area of industrial controls. In any control system, the biggest expense after the control system itself is the user interface, as it usually requires custom implementation of display, keyboard, mouse, general GUI, and all the support that goes with it. Sal might have a method where ANY browser capable device can serve as the GUI, with little or no custom work beyond the control application itself. But, there's zillion ways to try this, the challenge is finding one that is simple and elegant enough to be useful.
Our use case will focus on:
* use a browser as GUI
* execute commands on the target (prop application)
* display results on the GUI (android app/browser)
* modify high level forth on the target (prop)
* modify scripts on the GUI (android app/browser)
We think we can get what we want using HTML and JavaScript, and this may allow any smartphone, tablet, or PC to serve as a generic user interface.
We also talked about maintaining data and code on the prop systems. In propforth, a file is simply a sequence of blocks on the storage media. An old file may be modified, or a new version may be saved. The newest version is the only version visible, the old version still exist, but cannot be directly accessed. We are looking at using an idea from the old VMS file system. Each file will also have a version number associated with it. Each time a file was modified, a new file with a new version number was saved. Normally, we only see the most recent file, but if needed we can choose any previous version by specifying the version number. We would end up with a zillion old version numbers, but we would never see them unless we need to, and on an SD card we would never run out of space in most cases. If needed, the most recent version of each file could be copied to a new SD, and continue from there, allowing the previous SD to be recycled.
NickL
I have not been able to test it yet, but present it here for comment. It is an example where the word TO (using constants as
values) can be effective.
NickL
{ EXPERIMENTAL - Defining a Generic PID Controller Reference: Digital PID Controllers Dr. Varodon Taochindi 6/2011 www.controlsystemslab.com PID equation: u(k) = u(k-1) + k1*e(k) + k2*e(k-1) + k3*e(k-2) where k1 = kp+ki+kd k2 = -kp-2kd k3 = kd ki = kp/Ti kd = kp*Td Both Ti & Td are defined in terms of sample numbers. ucorr = u(k) - u(k-1) = Kp*(K1*e0+K2*e1+K3*e2) where Kp = kp*scale K1Ti = Ti(1+TD)+1 K2 = -(1+2Td) K3 = Td.} TO is a word which can change the value of a constant, thus, allowing constants to function as variables. For example: 45 constant try try . 45 165 TO try try . 165 } : TO ' 4+ L! ; \ pid parameters variable e0 \ e(k) variable e1 \ e(k-1) variable e2 \ e(k-2) \ These constants are intended to be used as "values", i.e., their values can be \ altered, using TO, prior to running the controller. 1 constant Ti 8 constant Td 10 constant K1 \ p: 1 -17 constant K2 \ p: -1 125 constant Kp \ kp*scale 1000 constant scale \ scales Kp 125 constant dt \ millisec sampling time - 8 samples/sec 100 constant uref \ target value of measured parameter (umeas) : initERR \ ( -- ) sets e0, e1, & e2 to 0 0 e0 L! 0 e1 L! 0 e2 L! ; \ The following 3 words simpify calulating K1 & K2, eg, cK1pid TO K1. : cK1pid \ ( -- n1 ) leaves calculated K1 for a pid controller on the stack. Td 1+ Ti * 1+ ; : cK1pd \ ( -- n1) leaves calculated K1 for a pd controller on the stack. Set Ti to 1. Td 1+ ; : cK2 \ ( -- n1) leaves calculated K2 for a pid\pd controller on the stack. Td 2* 1+ negate ; : PID \ ( n1 -- n2 ) n1 is umeas and n2 is ucorr. e1 L@ e2 L! e0 L@ e1 L! uref swap - dup e0 L! K1 Ti */ e1 L@ K2 * + e2 L@ Td * + Kp scale */ ;If Sal is back from traveling in time for tomorrow's meeting, I'll run it by him.
I also have to get used to changing constants with TO. It looks like a handy way to do it.
Thanks for your contribution, its very cool as usual.
I hope you don't mind that I start a wiki page for this, there some folks that don't participate on the forums that I want to have look at it. Of course you can edit or change the change as you want.
NickL
We have a delay due to hardware: Sal knocked his test rig off the bench a few times too many, it stopped responding. It was only a temporary hack to get by, but ended up carrying us through several full development cycles.
We've brought on a couple more folks to help with user testing, and making sure the user experience is fun. We have discovered that right now the docs in particular are not so fun. This is because we have a conflict: On the one hand, PropForth MUST be a complete system as the primary target is the full-on embedded systems engineer. On the other hand, it must also be simple enough for new and casual users to get up and running and having fun quickly enough so they don't die of boredom before they get enough information to start playing.
In reality, 90% of users will never use anything beyond the simple forth command line on a quickstart. We are now structuring the package to have primarily:
* the GettingStarted instructions
* the PropForthDevKErnel.spin file
* the PropForth.htm technical reference
The rest of the material (extensions, build and test automation, instructions for generating new kernel, assembler optimization, multiprop configurations, Go channel interfaces, etc) will all be present, but out of the way. If someone is interested it will be there, (its still included) but will be such that is won't trip up newcomers.
This is our current goal. Hopefully we make these changes as we scrub the issues lists before release.
Totally cool, Nick!
We may have a class of school kids to try using this shortly. More as it develops....
http://kondo-robot.com/product/MultiLeged.html
I replaced Renesas-board to propeller.
Servos are multi-drop-type.
A little bit moved.
Communication: HalfDuplex
Startbit:1bit Data:8bit Parity:Even Stopbit:1bit speed 115000bps
Level-shift-module(3.3V <--> 5V):[Using ＦＸＭＡ１０８]
This cannot connect pullup/pulldown resistor.
http://akizukidenshi.com/catalog/g/gM-04522/
Not yet walking.
http://youtu.be/75d5thAOWw8
Cool bot! I like the way the servo body is also the leg and the foot.
I can't figure what multi-drop servo means. Is it the same as RS-485 multi-drop serial link? That is, is it the same three wires to all servos (power, ground, and control) and each servo has an ID, and instead of a pulse, they recieve an ID code and a position code?
Your idea is correct.
Please refer about multi-drop servo;
http://www.trossenrobotics.com/p/PhantomX-AX-12-Quadruped.aspx
This robot use also multi-drop servos(AX-12A).
PhantomX AX Quadruped Mark II is far exellent than KMR-P4.
For $949 it better be pretty darn excellent!
I'm working on a cheaper design, that uses micro servos and drinking straws (like the ones from McDonalds) for the frame. If I get to the point where it can support its own weight, I will try it with the quickstart.
Have you tried Nglordi's robot control language yet?
Bareboneskit $219.5
AX-12A(6pack) $224.5 X 2
Total: $668.5 + cables + postage($70)
If I buy this, maybe about $760.
I use level-shift module(Using ＦＸＭＡ１０８) on KMR-P4.
I think this can't use on AX-12A.
Not yet check Nglordi's robot control language.
A littele bit moved.
But not yet walking.
http://youtu.be/igx-mBD5qq0
Very cool! Do those servos report there current position?