Funny you should ask. I sort of forgot about that till just this morning...
Today's Call:
LITTLE ROBOT
Little Robot prototype 1 is done. Sal drew a design in OpenSCAD, and printed a chassis and wheels on his new Printrbot. He made a custom board, and did his tests. Now he is trimming it down.
Little Robot prototype 2 will be built around a Quickstart, we decided that at least initially, folks will want to reduce the things that can go wrong and opt for a pre-built board. The chassis will be a little shorter and wider, and end up more square instead of a rectangle longer in the direction of travel. It will use mini Bluetooth as power connection, so it can run off a wall or PC for testing. The battery pack will also use mini USB as the power connector, so there will be less chance of hooking up both the battery and the pc. The battery pack will be 4to 6 AA batteries, although I might try C or D batteries just to see what happens.
Currently Little Robot functions are measure, pivot and move; commands are in millimeters or 1/10 of degree.
3600 left causes 360 degree rotation counter clockwise,
3600 right causes 360 degree rotation clockwise,
1000 forward cause 1 meter forward
1000 backward cause 1 meter backward
d triggers a measurement cycle and returns the distance an obstacle.
Bluetooth works well within the same room; when its in a different room or on a different floor the connection gets iffy. It begins to show what looks like RS232 errors, but its proven to be noise.
ANDROID GUI
Sal has an Android app prototype GUI for controlling the Little Robot. Note that this is to run on a dumb old smart phone, NOT on the RPi, etc. So any Bluetooth equipped phone should be able to talk to you Little Robot rig.
3D PRINTING
Sal reports that leveling the printbed using paper and aluminum foils works great. He measured the thickness of both the foil and the paper, the paper is 4x thinker than the foil. he measure the clearance from the printhead to the bed with the paper, and makes a 1 inch square of foil, and folds it half to get the measured offset. Each corner has taken 1 or 2 shims. The glass print surface can be removed and replaced, and the bed does not need to be re-shimmed.
GA144
Sal advises that he has not ordered a GA144 yet, and will not until we get to that point in the project till we have a specific use for it. GA144 is NOT destinined to be a general computer, as the prop itself just barely makes it as a JupiterACE forth terminal. BUT we still see a big place for GA144 in the coming months: Being clockless, it runs based on data flow, up to 1.6 ns. So when we're not sending data, it draws no power. When we get to t point where we need a video processing algorithm implemented (IE an RPi + camera on our little robot with a prop controlling the motors and other sensors) the GA144 is the first choice.
PARALLELA
Sal is interested in the parallela, but does not see it in the propforth development path for the time being, so has not ordered one. I'm sign up for a 16 core unit, but I'm easily distracted.
PROPFORTH v5.3
Remember propforth 5.3? Its been "ready" since forever, we have been checking the last details before release. Turns out the errors on my test rig had something to do with banging it around when moving from one station to another. So we really, really, REALLY cannot find any more bugs. So we decided to do the final cut over from the old version source code to the new (generated from this version) source code. The result is identical from both, we haven't found a bug in months, we think it should be ready (and has been for quite sometime).
We will release the kernel and work the documentation separately. Sal will go through Propforth.htm in the download, that has many obvious changes. As for the rest of the material (wiki, etc) we're going to ask for users to drive the documentation update. Your questions will help determine what gets updated soonest.
I mentioned a request for words SEE, DECOMPILE, and DISASSEMBLE. Sal says he's pretty sure they are in there someplace, but might have gotten lost between versions 4 and 5 since they fell from use. But he's going to find the source, bring them up to 5.3, and organize an extensions package. Thanks to Loopy for mentioning this. Opened as issue 164
STEPPERS
Sal has an idea for driving a whole load of steppers and keeping them sync'd. Similar to the way we can drive a boat load of servos, Sal's experiment will check if there is a similar way to drive many steppers and keep them all sync'd. We don't know what we would do with 28(?) steppers, but if anybody can think of an application, we might try it out.
While we were on the subject, we decided that it might be fun to build an 24 servo spider for under $50. If anybody can find a source for servos under $2 US, please let me know. This would scare the neighbors nicely. So far the best I could find was $2.81
Hi.
I try MAX3421E again.
But Full Speed Device cannot read Descriptor at all same as last year.
MAX3421E's clock use 12MHz-Xtal.
SPI-Communication(a_send_command , a_byte_read) is assembler-word.
ELECOM-mouse seems to read Descriptors.
But 3-bottun mouse and KeyBoard don't read Report-Descriptor.
Hi.
I found up forth-word can't operate Full-Speed-device because of slowing.
It seems it need assemble-word.
BTW, Low-Speed-device operate by Forth-word.
I read usb-mouse's descriptors.
But I cannot read how to usb-mouse's value(X,Y,Button).
I read USB-HID specification. But I have no idea.
Please teach me how to read usb-mouse's value.
How descriptor do I send to max3421e?
Sal is up to version 2 of the Little Robot(tm) prototype mechanical design. Recall that this is a two wheel tail caster design. Its still over built, Sal will pare down the chassis on version 3. The design will be included in the PropForth V5.3 release, and include SCAD files suitable for 3D printing, or manufactue using scrap and simle tools.
Sal is still cutting over to the new code (generating v5.3 from the result of v5.3, rather than generating v5.3 from a previous version of code). He was delayed this week as it has proven too much fun to play with the Little Robot.
What would you pay for a Little Robot Chassis? You you even bother if you had to build it from plywood like erco? We are figuring out costs for the chassis. 3D printer time is down under 3 hours, time is the expense. If there were sufficient demand, these could be injection molded for under a buck, but for now, they will be individually generated. PropellerPowered may be considering carrying a kit of parts for the motor, sensor, and bluetooth, but we'll have to see if any orders come in. This may give us a hint as to whether molded chassis is viable. There are at least two schools talking about class - sized orders, but 24 units doesn't make a Raspberry Pi.
ITERATIVE MAPPING - the Little Robot demo looks like it will attempt iterative mapping. The bot will scan the environment, and make a map. Then travel to the least understood area, than fill in detail. Repeat until the bot can find its way back to origin.
USER INTERFACE - the demo looks like it will have successive development of the user interface. First pass will use the touch buttons on the quickstart. Second, same functions on the terminal. Third, terminal over Bluetooth. Fourth, smartphone android app. And so on.
Sal reminded me that the code itself is ready for release, as it has been for the last several months. He's taking his time with the cut over as he is planning the demo to be included with the release, and there is TONS of documentation to do. If anybody want to release to happen sooner, all we need is some help updating the docs.
ANYBODY INTERESTED IN an earlier release of v5.3 can volunteer to work the docs with us. Be warned the docs require us to be completely accurate in the fewest words, and not be boring. No one will thank you if you do it well, and everyone will jump all over you for the slightest mistake. This is may favorite part. Any takers?
NOTICE: The manual tests (the tutorials in the kernels directory) are NOT updated to match the automation. While the tutorials still demonstrate the correct usage of the kernel functions, they are falling out of sync. The automation is the main path.
3D printing. Sal is having a blast with his printrbot. He's already decided numerous changes to the design, per the intended purpose of the printrbot as a "first printer". Being Sal, he already plans to use the printrbot for several months to familiarize himself with the issues. A modified Mendel90 looks like the direction he will pursue. Delta-Bot is also interesting.
Prop Based CNC. Sal's statement was, what benefit would a prop solution have over Marlin on ATmega? Presently there is no foreseeable benefit that merits the cost and effort. I better update the CNC thread.
I have a similar board by the same person, Oleg. He does a lot with camera control and mine is a small Arduino footprint. I intended to use it and one of the small Arduinos to controll one of my dSLR cameras. I haven't done anything at all with it. I may have to try it with a Prop and PropForth sometime.
I was looking into implementing a few ANS Forth words in PropForth, and I've run into a snag with "allot" and "create". Since the Prop is a 32-bit device it seems natural that ! and @ should be defined as follows:
: ! L! ;
: @ L!;
So far, so good. Now the "," word write TOS to the current location and then add 4 to "here" by using "allot" as follows:
: , here ! 4 allot ;
However, this doesn't change the value of here after I run ",". Also, "create" doesn't work as expected. If I do "variable xxx", and then " ' xxx " I get the address of xxx on the stack. If I do " create yyy " and then " ' yyy " I get a value of 0.
In ANS Forth I would create a list of numbers as follows:
create doesn't work the same in propforth. we use variable - allot instead for array.
Create is used the "normal" way internally to make forth dictionary entries, but it doesn't leave an address on the stack and so doesn't lend itself to array use.
DOES> is not implemented either, so we don't have separate compile time behavior and runtime behavior. It turns out its just as easy to have separate compile words and runtime words for a given function. Using the create - does> construct is usually a stumbling block, so this was left out.
Thanks. The thing that confused me was the "here" is actually the address of the 16-bit value of data pointer, instead of the data itself. There seems to be a bug with the word "create". As I mentioned before, if I do a " create xyz " then " ' xyz . " prints 0 instead of the address of xyz. The "words" command will show the correct address for xyz. I suppose "create" could be redefined as " : create variable -4 allot ; ".
prof-braino, looks like I was writing my last post while you were posting. I noticed that PropForth isn't case insensitive, so I suppose I could define the ANS words in uppercase so they don't conflict with the existing words that function differently.
As far as compile versus runtime, I can create a state variable to control that. It shouldn't be too hard to implement does>. It's a very useful word.
Prof
I forgot to post my comments on the word “.digit”
In your .digits code you only test for valid hex using TOS > 9 so anything from A..Z will be decoded. You should really should test for the upper limit too. It is unlikely that invalid code would be entered via the “key”, unless it's a simple typo, but it could be pushed on TOS from other code, and .digit stil decode it.
I don't have Propforth installed, right now, so I cannot test anything, but I want to resolve some of the issued that I have with intercog data transfers so I will be reinstalling it at some stage.
Right now I have others things I want to do.
In your .digits code you only test for valid hex using TOS > 9 so anything from A..Z will be decoded. You should really should test for the upper limit too.
In general, Sal's rule for development is "minimum to get the job done" in the kernel, so things like error checking and reporting messages are left to a minimum. Usually these are not required, but can be implemented as extensions by the user (and added to the package if enough folks want it).
Remember, the number base can be anything, binary up to base 63, so we need everything to work for all those cases too.
I'll look into this and see if there is enough to write up, and we sort it out. Hopefully by Sunday's call.
create doesn't work the same in propforth. we use variable - allot instead for array.
Create is used the "normal" way internally to make forth dictionary entries, but it doesn't leave an address on the stack and so doesn't lend itself to array use.
DOES> is not implemented either, so we don't have separate compile time behavior and runtime behavior. It turns out its just as easy to have separate compile words and runtime words for a given function. Using the create - does> construct is usually a stumbling block, so this was left out.
These are interesting contrasts in lexicon. I think I finished editing my HOWTO for the beginner Forth user on the Propeller, but making an actual columnar listing to compare "Starting Forth Lexicon" with "PropForth Lexicon" is already indicating that this comparison might be better offered by the developers of PropForth and not left to the beginner to dig out.
I may get started on something. But I am posting the HOWTO here as it is presentable and some readers of this thread may not know about it.
... making an actual columnar listing to compare "Starting Forth Lexicon" with "PropForth Lexicon" is already indicating that this comparison might be better offered by the developers of PropForth and not left to the beginner to dig out.
I'll look into it. I was needing another project, my list had dwindled to only a few hundred
HOWTO here as it is presentable and some readers of this thread may not know about it.
PLEASE also post your work in the Propforth google code site, some folks don't even know about these forums. You (are supposed ot already) have administrator permission, please use that resource.
This is really cool!
.... regarding a PropForth/Starting Forth Lexicon comparision
I'll look into it. I was needing another project, my list had dwindled to only a few hundred
... regarding Propforth google code site
PLEASE also post your work in the Propforth google code site, some folks don't even know about these forums. You (are supposed ot already) have administrator permission, please use that resource.
Firstly, I already have started on comparing Starting Forth Lexicon with similar words in PropForth 5.0. I just got a print out of a comparision and the results are both interesting and a bit concerning. One fact is that case sensitivity is a big issue. Another fact is there are more trivial irregularities that I expected.
Don't get started on this as I will at least do the preliminary analysis as I benefit greatly from doing so.
And the Propforth Google site?
I have been a bit shy about posting there. I am still learning a lot about PropForth that I was very unaware of or confused about. I will post a limited amount of things that I am very clear on. But that is about all. For now, that means two items.
1. The HOWTO posted above.
2. A PropForth/Starting Forth Lexicon comparison
Comments
"inverse-kinematics-calculation" use uM-FPUv3.1.
YouTube
http://youtu.be/fhyy_JcLuFQ
Sal has finally received his Printrbot 3D printer. Details on this will be in the CNC thread.
Work is proceeding on the Little Robot, I'm drafting the user manual.
Sal is looking into the Green Arrays GA144, more on that in the GA144 thread.
I posted POV_1.1 in this thread.
This time,not watching mirror writing because of using accelerometer.
Delta-Robot_fpu_0.4 has problem.
Receving data from uM-FPUv3.1 by LREADA/LREADBYTE/LREADWORD lost LSB.
Cam(Micromega.Corp) fixed this problem.
We have new iterations of the little robot chassis and wheels, but these are not ready to be posted.
We also have a first draft of the little robot user manual. The draft is still under construction on the wiki if anyone cares to make comments.
Are we ever going to get a PropForth v5.3 release????
Just curious. I'll go back to my cold, dreary day now.
Today's Call:
LITTLE ROBOT
Little Robot prototype 1 is done. Sal drew a design in OpenSCAD, and printed a chassis and wheels on his new Printrbot. He made a custom board, and did his tests. Now he is trimming it down.
Little Robot prototype 2 will be built around a Quickstart, we decided that at least initially, folks will want to reduce the things that can go wrong and opt for a pre-built board. The chassis will be a little shorter and wider, and end up more square instead of a rectangle longer in the direction of travel. It will use mini Bluetooth as power connection, so it can run off a wall or PC for testing. The battery pack will also use mini USB as the power connector, so there will be less chance of hooking up both the battery and the pc. The battery pack will be 4to 6 AA batteries, although I might try C or D batteries just to see what happens.
Currently Little Robot functions are measure, pivot and move; commands are in millimeters or 1/10 of degree.
3600 left causes 360 degree rotation counter clockwise,
3600 right causes 360 degree rotation clockwise,
1000 forward cause 1 meter forward
1000 backward cause 1 meter backward
d triggers a measurement cycle and returns the distance an obstacle.
Bluetooth works well within the same room; when its in a different room or on a different floor the connection gets iffy. It begins to show what looks like RS232 errors, but its proven to be noise.
ANDROID GUI
Sal has an Android app prototype GUI for controlling the Little Robot. Note that this is to run on a dumb old smart phone, NOT on the RPi, etc. So any Bluetooth equipped phone should be able to talk to you Little Robot rig.
3D PRINTING
Sal reports that leveling the printbed using paper and aluminum foils works great. He measured the thickness of both the foil and the paper, the paper is 4x thinker than the foil. he measure the clearance from the printhead to the bed with the paper, and makes a 1 inch square of foil, and folds it half to get the measured offset. Each corner has taken 1 or 2 shims. The glass print surface can be removed and replaced, and the bed does not need to be re-shimmed.
GA144
Sal advises that he has not ordered a GA144 yet, and will not until we get to that point in the project till we have a specific use for it. GA144 is NOT destinined to be a general computer, as the prop itself just barely makes it as a JupiterACE forth terminal. BUT we still see a big place for GA144 in the coming months: Being clockless, it runs based on data flow, up to 1.6 ns. So when we're not sending data, it draws no power. When we get to t point where we need a video processing algorithm implemented (IE an RPi + camera on our little robot with a prop controlling the motors and other sensors) the GA144 is the first choice.
PARALLELA
Sal is interested in the parallela, but does not see it in the propforth development path for the time being, so has not ordered one. I'm sign up for a 16 core unit, but I'm easily distracted.
PROPFORTH v5.3
Remember propforth 5.3? Its been "ready" since forever, we have been checking the last details before release. Turns out the errors on my test rig had something to do with banging it around when moving from one station to another. So we really, really, REALLY cannot find any more bugs. So we decided to do the final cut over from the old version source code to the new (generated from this version) source code. The result is identical from both, we haven't found a bug in months, we think it should be ready (and has been for quite sometime).
We will release the kernel and work the documentation separately. Sal will go through Propforth.htm in the download, that has many obvious changes. As for the rest of the material (wiki, etc) we're going to ask for users to drive the documentation update. Your questions will help determine what gets updated soonest.
I mentioned a request for words SEE, DECOMPILE, and DISASSEMBLE. Sal says he's pretty sure they are in there someplace, but might have gotten lost between versions 4 and 5 since they fell from use. But he's going to find the source, bring them up to 5.3, and organize an extensions package. Thanks to Loopy for mentioning this. Opened as issue 164
STEPPERS
Sal has an idea for driving a whole load of steppers and keeping them sync'd. Similar to the way we can drive a boat load of servos, Sal's experiment will check if there is a similar way to drive many steppers and keep them all sync'd. We don't know what we would do with 28(?) steppers, but if anybody can think of an application, we might try it out.
While we were on the subject, we decided that it might be fun to build an 24 servo spider for under $50. If anybody can find a source for servos under $2 US, please let me know. This would scare the neighbors nicely. So far the best I could find was $2.81
I try MAX3421E again.
But Full Speed Device cannot read Descriptor at all same as last year.
MAX3421E's clock use 12MHz-Xtal.
SPI-Communication(a_send_command , a_byte_read) is assembler-word.
ELECOM-mouse seems to read Descriptors.
But 3-bottun mouse and KeyBoard don't read Report-Descriptor.
There are any suggestions?
i don't have that part. maybe try on the sensors forum?
caskaz, how the heck to you have time to do so many cool things? I can't keep up!
I found up forth-word can't operate Full-Speed-device because of slowing.
It seems it need assemble-word.
BTW, Low-Speed-device operate by Forth-word.
I read usb-mouse's descriptors.
But I cannot read how to usb-mouse's value(X,Y,Button).
I read USB-HID specification. But I have no idea.
Please teach me how to read usb-mouse's value.
How descriptor do I send to max3421e?
Sal is up to version 2 of the Little Robot(tm) prototype mechanical design. Recall that this is a two wheel tail caster design. Its still over built, Sal will pare down the chassis on version 3. The design will be included in the PropForth V5.3 release, and include SCAD files suitable for 3D printing, or manufactue using scrap and simle tools.
Sal is still cutting over to the new code (generating v5.3 from the result of v5.3, rather than generating v5.3 from a previous version of code). He was delayed this week as it has proven too much fun to play with the Little Robot.
What would you pay for a Little Robot Chassis? You you even bother if you had to build it from plywood like erco? We are figuring out costs for the chassis. 3D printer time is down under 3 hours, time is the expense. If there were sufficient demand, these could be injection molded for under a buck, but for now, they will be individually generated. PropellerPowered may be considering carrying a kit of parts for the motor, sensor, and bluetooth, but we'll have to see if any orders come in. This may give us a hint as to whether molded chassis is viable. There are at least two schools talking about class - sized orders, but 24 units doesn't make a Raspberry Pi.
ITERATIVE MAPPING - the Little Robot demo looks like it will attempt iterative mapping. The bot will scan the environment, and make a map. Then travel to the least understood area, than fill in detail. Repeat until the bot can find its way back to origin.
USER INTERFACE - the demo looks like it will have successive development of the user interface. First pass will use the touch buttons on the quickstart. Second, same functions on the terminal. Third, terminal over Bluetooth. Fourth, smartphone android app. And so on.
Sal reminded me that the code itself is ready for release, as it has been for the last several months. He's taking his time with the cut over as he is planning the demo to be included with the release, and there is TONS of documentation to do. If anybody want to release to happen sooner, all we need is some help updating the docs.
ANYBODY INTERESTED IN an earlier release of v5.3 can volunteer to work the docs with us. Be warned the docs require us to be completely accurate in the fewest words, and not be boring. No one will thank you if you do it well, and everyone will jump all over you for the slightest mistake. This is may favorite part. Any takers?
NOTICE: The manual tests (the tutorials in the kernels directory) are NOT updated to match the automation. While the tutorials still demonstrate the correct usage of the kernel functions, they are falling out of sync. The automation is the main path.
3D printing. Sal is having a blast with his printrbot. He's already decided numerous changes to the design, per the intended purpose of the printrbot as a "first printer". Being Sal, he already plans to use the printrbot for several months to familiarize himself with the issues. A modified Mendel90 looks like the direction he will pursue. Delta-Bot is also interesting.
Prop Based CNC. Sal's statement was, what benefit would a prop solution have over Marlin on ATmega? Presently there is no foreseeable benefit that merits the cost and effort. I better update the CNC thread.
This is displaying USB devices's discriptors.
Only low-speed-device.
Which crystal are you using? I thought the prop needs 10Mhz(?) crystal to be able to do USB 2.0?
I use 12MHz Xtal for MAX3421E.
In that case, I'm stumped. Sorry, you're too far ahead of me.
I made cuicuit on breadboard.
Sparkfun sell USB Host Shield(using MAX3421E).
https://www.sparkfun.com/products/9628
Anybody try to write usb's code by using that board?
I have a similar board by the same person, Oleg. He does a lot with camera control and mine is a small Arduino footprint. I intended to use it and one of the small Arduinos to controll one of my dSLR cameras. I haven't done anything at all with it. I may have to try it with a Prop and PropForth sometime.
Thanks for providing some code to try!
In ANS Forth I would create a list of numbers as follows: How would I do this in Prop Forth?
create doesn't work the same in propforth. we use variable - allot instead for array.
Create is used the "normal" way internally to make forth dictionary entries, but it doesn't leave an address on the stack and so doesn't lend itself to array use.
DOES> is not implemented either, so we don't have separate compile time behavior and runtime behavior. It turns out its just as easy to have separate compile words and runtime words for a given function. Using the create - does> construct is usually a stumbling block, so this was left out.
As far as compile versus runtime, I can create a state variable to control that. It shouldn't be too hard to implement does>. It's a very useful word.
I forgot to post my comments on the word “.digit”
In your .digits code you only test for valid hex using TOS > 9 so anything from A..Z will be decoded. You should really should test for the upper limit too. It is unlikely that invalid code would be entered via the “key”, unless it's a simple typo, but it could be pushed on TOS from other code, and .digit stil decode it.
I don't have Propforth installed, right now, so I cannot test anything, but I want to resolve some of the issued that I have with intercog data transfers so I will be reinstalling it at some stage.
Right now I have others things I want to do.
Ron
In general, Sal's rule for development is "minimum to get the job done" in the kernel, so things like error checking and reporting messages are left to a minimum. Usually these are not required, but can be implemented as extensions by the user (and added to the package if enough folks want it).
Remember, the number base can be anything, binary up to base 63, so we need everything to work for all those cases too.
I'll look into this and see if there is enough to write up, and we sort it out. Hopefully by Sunday's call.
These are interesting contrasts in lexicon. I think I finished editing my HOWTO for the beginner Forth user on the Propeller, but making an actual columnar listing to compare "Starting Forth Lexicon" with "PropForth Lexicon" is already indicating that this comparison might be better offered by the developers of PropForth and not left to the beginner to dig out.
I may get started on something. But I am posting the HOWTO here as it is presentable and some readers of this thread may not know about it.
opened issue 167
Thanks kmw! I almost missed this!
This is really cool!
I'll look into it. I was needing another project, my list had dwindled to only a few hundred
PLEASE also post your work in the Propforth google code site, some folks don't even know about these forums. You (are supposed ot already) have administrator permission, please use that resource.
I updated serch_descriptor.
I added report-descriptor and read datas from mouse.
Sometimes endless loop happen inside "detect_devices".
This need power-off-on, not resetting.
I have no idea.
Datas from mouse:
1st byte:?
2nd byte:button bit2:center left bit1:right bit0:left
3rd byte:X
4th byte:Y
5th byte:
6th byte:wheel
7th byte:?
Firstly, I already have started on comparing Starting Forth Lexicon with similar words in PropForth 5.0. I just got a print out of a comparision and the results are both interesting and a bit concerning. One fact is that case sensitivity is a big issue. Another fact is there are more trivial irregularities that I expected.
Don't get started on this as I will at least do the preliminary analysis as I benefit greatly from doing so.
And the Propforth Google site?
I have been a bit shy about posting there. I am still learning a lot about PropForth that I was very unaware of or confused about. I will post a limited amount of things that I am very clear on. But that is about all. For now, that means two items.
1. The HOWTO posted above.
2. A PropForth/Starting Forth Lexicon comparison