One very viable approach does not involve a compiler and server at all, but ability to configure a state-machine ActivityBot to behave as desired through C coding or a GUI.
Are we looking for an Activity Bot exclusive solution or one that also includes microcontroller (WAM etc.) curricula?
One very viable approach does not involve a compiler and server at all, but ability to configure a state-machine ActivityBot to behave as desired through C coding or a GUI.
Can you explain what you mean by this? What sort of state machine would the ActivityBot be running that would allow it to be programmed using C coding on the iPad? You mean that the C code on the iPad would be compiled locally and when run would generate a sequence of instructions to the ActivityBot like "turn right", "rotate", "move forward", etc? Sort of like Logo Turtle Graphics? And the program logic would be running on the iPad?
[*]One very viable approach does not involve a compiler and server at all, but ability to configure a state-machine ActivityBot to behave as desired through C coding or a GUI.
The GUI becomes very like I remember Lego operated ?
State machine control is relatively simple, but gets tricky to manage above a small number of states.
It could work on nothing more than a text editor, but leaves users to solve syntax issues.
One state engine example I have open right now is this
PRESENT StateNameOrNumberX
IF ConditionA NEXT StateNameOrNumberY;
IF ConditionB NEXT StateNameOrNumberZ;
default NEXT StateNameOrNumberX; // can be implicit
A State parser operating during terminal download might be enough to handle syntax errors and typos ?
( eg Duplicate and illegal states )
OUT commands and Timer Delays and Monostables would flesh out the state controls.
I had a productive meeting this morning with an influential, capable person with a very impressive record. This person understands all of the pieces, development considerations on an iPad, business development, working within Apple, etc.
Please keep in mind this relates to the original topic, not the offshoot related to Linux SBCs like RasberryPi.
I'd like to share the recommended conclusion and receive your input.
WiFi is the the best technical choice for connectivity to an iPad. Bluetooth gets a distance second, but is still practical. All other forms of connectivity are not appropriate for one reason or another.
iPad as a code/text editor is very appropriate. Maybe a SIDE port.
Compilers, should they exist, would operate remotely on a server.
One very viable approach does not involve a compiler and server at all, but ability to configure a state-machine ActivityBot to behave as desired through C coding or a GUI.
This approach favors using iPad as an introduction tool rather than a complete programming environment, gives the student relatively high-level control, and continues to keep real development on a computer.
I have another meeting with Jeff and a key internal Apple person to followup, but would appreciate hearing your thoughts on this approach.
Ken Gracey
I have thought since you raised this problem that WiFi was a good solution for the Activity Bot. Otherwise Bluetooth LE may be useful.
IIRC there is an XBee socket above the microSD socket? I think this would take the WiFly module. Rather expensive given other methods around. Perhaps Parallax could also build an equivalent. A cheaper alternative could be a WR703N and reprogrammed to do WiFi to USB (to the Prop) but this would have to be checked.
Presuming this solves the Activity Bot end...
Simplest starting point would be that the iPad can download over WiFi to the Activity Bot (can be binary or commands - concept would be similar so will leave that for separate discussions).
Again, simplicity, a server (either at school or over the internet and perhaps housed at Parallax) to edit the code using the iPad and Safari, and then compile it. Later, an App on the iPad for local editing would be a huge improvement. Compilation could still be done on a "cloud" server. Next, compiling on the iPad.
As you can see, all this can be done in stages. It also would permit the "class" programming using the "etherpad.org" concept too.
So as I said in my first post - the biggest hurdle is to prove the iPad to Activity Bot link - WiFi or whatever. Once solved the rest can be worked out.
Question: If the iPad uses WiFi to the Activity Bot, can it also connect via the WiFi to the "server". ie Can both connections be available simultaneously? If not, what is required to enable/disable connections on WiFi - is it simple or difficult???
The only way for the iPad and the Propeller to talk and the iPad and the server to talk at the same time would be for them all to be on the same wireless LAN (WiFi network). If the server is local (not needing the Internet), then you could have them all on a single ad-hoc network (all the iPads and all the Propellers along with the server). If you need the Internet, then all the iPads and the Propellers have to be on the same LAN along with the server.
State machine control is relatively simple, but gets tricky to manage above a small number of states.
True, if your only image of a "state machine" is a diagram with circles and arrows and state transition conditions. But, hey, even a C program is a state machine. I totally get what Ken is referring to: a simple script with loops and conditiionals that describes the behavior of a robot in macro terms, without all the fol-de-rol of a low-level C program. It's a laudable and completely achievable objective.
True, if your only image of a "state machine" is a diagram with circles and arrows and state transition conditions. But, hey, even a C program is a state machine. I totally get what Ken is referring to: a simple script with loops and conditiionals that describes the behavior of a robot in macro terms, without all the fol-de-rol of a low-level C program.
Have you seen the S2 GUI, David? Reduced to script form, it's just a bunch of calls to the S2.spin object. Those calls could easily be codified as commands in a script language.
Have you seen the S2 GUI, David? Reduced to script form, it's just a bunch of calls to the S2.spin object. Those calls could easily be codified as commands in a script language.
-Phil
I'm afraid that my S2 robot is another piece of hardware that I bought but haven't spent much time with. Maybe part of my problem is that the IDE doesn't run on my Mac. Any idea when it will be ported to the Mac and Linux? :-)
Any idea when it will be ported to the Mac and Linux?
David, I know you're asking that rhetorically, and it's off-topic, so I'm not going to go into detail here about the issues involved or my progress towards a solution. The point is that the low-level aspects of C are totally unecesssary for expressively directing the behavior of an educational robot. Ken has it right: a scripting language that abstracts behavior away from low-level language constructs is more than adequate to provide a rich experience for robotics newcomers.
David, I know you're asking that rhetorically, and it's off-topic, so I'm not going to go into detail here about the issues involved or my progress towards a solution. The point is that the low-level aspects of C are totally unecesssary for expressively directing the behavior of an educational robot. Ken has it right: a scripting language that abstracts behavior away from low-level language constructs is more than adequate to provide a rich experience for robotics newcomers.
-Phil
I can see having a special language for controlling a robot. What confused me is that I think Ken originally mentioned C. Maybe he really meant "a C-like language" rather than the full C language with all of the gory low-level details.
I can see having a special language for controlling a robot. What confused me is that I think Ken originally mentioned C. Maybe he really meant "a C-like language" rather than the full C language with all of the gory low-level details.
From the context, I took Ken's C coding or a GUI to mean Text coding or a GUI
If he is looking for simple script control, (no compiler), then perhaps a variant of Prop BASIC with some state machine options/keywords added would be close enough ?
PropBASIC does not have a CASE statement, but does have a BRANCH instruction, so could likely support a clean state engine.
From the context, I took Ken's C coding or a GUI to mean Text coding or a GUI
If he is looking for simple script control, (no compiler), then perhaps a variant of Prop BASIC with some state machine options/keywords added would be close enough ?
PropBASIC does not have a CASE statement, but does have a BRANCH instruction, so could likely support a clean state engine.
My xbasic compiler could be built for the iPad and it includes a CASE statement and also compiles to byte codes that run under a PASM VM so it's pretty fast.
How about real C, but a really easy to use library???
real C has a pretty klunky case syntax, and Ken was trying to avoid the Compiler.
Of course C is a valid choice for those who know C, and have the compiler.
My xbasic compiler could be built for the iPad and it includes a CASE statement and also compiles to byte codes that run under a PASM VM so it's pretty fast.
So you could host that on an iPad, and send byte codes to a small loader/VM on the Prop ?
Sounds good, any links/examples/code size limits/numeric types ?
How does it manage student typos ?
If it uses a Bytecode VM, does that mean it could also run/step on an iPad ? (at least to the mathops level, pin IO obviously has to be a little imagined )
How large is the Prop resident VM and how does speed compare with spin, or PropBASIC ?
What is the byte-code image of an example program ?
I could not see keywords for WAITCNT/WAITPEQWAITPNE ?
How about real C, but a really easy to use library???
Great idea. It's called "wiring".
Let's remove the Propellers and replace them with Arduinos!
Whilst we are at it let's replace all that complicated hardware that is the robots and connectivity with robot simulations that run in the iPad. Then the students don't have to be concerned with any of that annoying reality stuff at all.
I am joking.
Back in the seventies we learned programming in school. The computer the school used was in the "cloud", a mainframe far away we talked to via teletype and modem. To make things "simple" we were taught BASIC and an artificial assembly language that was interpretted, a simple model of the real thing.
Of course that meant our progress in actual programming skill or computing education was retarded by at least three years.
This whole project sounds like history repeating itself...
xbasic is a nice language with performance and program sizes comparable to SPIN. All Propellerisms like waitcnt are supported in the Bytecode ASM syntax. Clockmode and speed are set using a config file.
I wrote a big LCD device based application with xbasic. I never got pinched by HUB memory size with it. xbasic also supports xmmc mode.
xbasic is a nice language with performance and program sizes comparable to SPIN. All Propellerisms like waitcnt are supported in the Bytecode ASM syntax. Clockmode and speed are set using a config file.
Sounds good. Do you have an example of how the user gets at Propellerisms like waitcnt ? - the xBasic manual does not find Bytecode or ASM ?
Do all the programming in the browser in JavaScript.
1) The students program, in JS, is edited in the browser with a web based editor/ide with syntax higligting and all good things. There are many ways to do this Web IDE, ACE editor Cloud 9 etc.
2) The JS is run in the browser.
3) Via some simple JS libraries it can send commands to the students robot, start, stop, tern_left, turn_right, whatever. It can also recieve signals from the robot regarding sensors.
4) The robot runs a simple interpreter of those commands and controls the hardware. It also monitors sensors sending data back to the browser.
5) Tablet to robot communication is via WIFI.
This addresses all those suggestions of a simplified language for students to work with and hopefully the communication issues.
It leverages an existing language and run time.
For those who want a graphical "blocks" programming system that can be done very effectively as well. There are "scratch" like systems for assembling programs from graphical elements that become JavaScript. As used on Espruino and others.
If the student happens to have FireFox or Chrome they have very full featured debug tools buit in.
JavaScript is a significantly less useless language to learn than BASIC, Forth, dare I say it even Spin, for most students.
JavaScript is very easy to get started with as the Espruiono project demonstrates.
3) Via some simple JS libraries it can send commands to the students robot, start, stop, tern_left, turn_right, whatever. It can also recieve signals from the robot regarding sensors.
I can see that could have a place for initial learning, but with that topology, unplug the Wifi, and the bot is lobotomised.
I guess that is a lesson in itself
The next class can cover 'Why do we need autonomous operation' ?
"Less useless?" Is that damning with faint praise, or what?
Deliberate ambiguity...
I am currently infatuated with JavaScript. It has features that only recently Java and C++ has have tried to implement. First class functions, Lambdas, closures, etc. It's evented model of programming makes many jobs very easy. It's significantly easier to develop some kinds of programs in and the results can perform as well as the C++ counterparts. It works in the browser it works on the server it works on embedded systems. What's not to like?
I love C and C++ too. Sometimes I think the best thing you can do in C++ is write a JavaScript interpreter so that you can then get on an develop your application quickly and easily:) The Qt guys have, after many decades, realized the truth of this and done exactly that, they now push the idea of writing your GUI apps in JavaScript. See QML.
I'm into Python. I'm into Spin. Spin and the PropTool/BST/SimpleIDE is a wonderful thing. Spin/PASM are such a perfectly, dare I say it, "synergistic" solution for the Propeller. I would not dream of using Spin anywhere else though.
This month I'm having to make changes to a big Pascal project. Object Pascal is OK. Nice because it compiles in a flash.
I hate any language that relies on the use of $.
BASIC and Forth give me migraines. I'd rather hack x86 assembler in old fashioned 16 bit segmented mode!
Anyway, language wars aside, my comment was just an observation that JS is more likely something students would be able to use elsewhere. A transferable skill rather than some one off language that they might spend hours getting to grips with only to never use again.
jmg,
I can see that could have a place for initial learning, but with that topology, unplug the Wifi, and the bot is lobotomised.
Very true.
I guess that is a lesson in itself...The next class can cover 'Why do we need autonomous operation' ?
Oh yeah.
At that point you just move the JavaScript execution to the Robot by adding a Raspberry Pi (ducks) or Espruino board to the robot. Espruino is dirt cheap.
...
At that point you just move the JavaScript execution to the Robot by adding a Raspberry Pi (ducks) or Espruino board to the robot. Espruino is dirt cheap.
or, you could use a careful subset (checked with a javascript module, of course ) and then target a Prop hosted variant.
Of course, you now need a Prop specific byte code compiler somewhere. ( a .js Parser version of xBasic perhaps ? )
Wow! I thought I woke up in Bizarro world the way this thread was headed. I almost thought someone was going to suggest a domain specic language written in Forth or something that you could just throw text at through some radio link that ended up looking like serial input to the Prop..or a GUI app that generated the DSL commands.
I'm glad we're back to parsing languages and compiling to some intermediate byte code that can be sent to a vm running on the Prop or some intermediate processor.
If it uses a Bytecode VM, does that mean it could also run/step on an iPad ? (at least to the mathops level, pin IO obviously has to be a little imagined )
How large is the Prop resident VM and how does speed compare with spin, or PropBASIC ?
What is the byte-code image of an example program ?
I could not see keywords for WAITCNT/WAITPEQWAITPNE ?
Yes you could do run/step from an iPad. The resident VM fills one COG but can also use a second COG for access to external memory. In fact, this is where I originally developed the XMM code used by PropGCC. If you restrict yourself to only hub memory then only one COG is needed for the VM. I'm not sure how the speed compares with spin but it is certainly much slower than PropBASIC since that compiles directly to LMM code and doesn't use a VM at all. I'll have to dig out a bytecode image of a program. I don't have one handy. The VM is a stack machine though so you can probably guess what it looks like.
Comments
Looks like the MRF versions of the Microchip Wifly modules will support Wi-Fi Direct.
Are we looking for an Activity Bot exclusive solution or one that also includes microcontroller (WAM etc.) curricula?
John Abshier
The GUI becomes very like I remember Lego operated ?
State machine control is relatively simple, but gets tricky to manage above a small number of states.
It could work on nothing more than a text editor, but leaves users to solve syntax issues.
One state engine example I have open right now is this
PRESENT StateNameOrNumberX IF ConditionA NEXT StateNameOrNumberY; IF ConditionB NEXT StateNameOrNumberZ; default NEXT StateNameOrNumberX; // can be implicitA State parser operating during terminal download might be enough to handle syntax errors and typos ?
( eg Duplicate and illegal states )
OUT commands and Timer Delays and Monostables would flesh out the state controls.
In the Graphical format branch, this is getting close to PLC languages in
http://en.wikipedia.org/wiki/IEC_61131-3
the Function block diagram (FBD),
and
Sequential function chart (SFC)
some examples are here
http://www.batchcontrol.com/s88/sfcs.shtml
Text based State could also be based on a CASE statement, available in almost any language.
IIRC there is an XBee socket above the microSD socket? I think this would take the WiFly module. Rather expensive given other methods around. Perhaps Parallax could also build an equivalent. A cheaper alternative could be a WR703N and reprogrammed to do WiFi to USB (to the Prop) but this would have to be checked.
Presuming this solves the Activity Bot end...
Simplest starting point would be that the iPad can download over WiFi to the Activity Bot (can be binary or commands - concept would be similar so will leave that for separate discussions).
Again, simplicity, a server (either at school or over the internet and perhaps housed at Parallax) to edit the code using the iPad and Safari, and then compile it. Later, an App on the iPad for local editing would be a huge improvement. Compilation could still be done on a "cloud" server. Next, compiling on the iPad.
As you can see, all this can be done in stages. It also would permit the "class" programming using the "etherpad.org" concept too.
So as I said in my first post - the biggest hurdle is to prove the iPad to Activity Bot link - WiFi or whatever. Once solved the rest can be worked out.
Question: If the iPad uses WiFi to the Activity Bot, can it also connect via the WiFi to the "server". ie Can both connections be available simultaneously? If not, what is required to enable/disable connections on WiFi - is it simple or difficult???
-Phil
-Phil
-Phil
From the context, I took Ken's C coding or a GUI to mean Text coding or a GUI
If he is looking for simple script control, (no compiler), then perhaps a variant of Prop BASIC with some state machine options/keywords added would be close enough ?
PropBASIC does not have a CASE statement, but does have a BRANCH instruction, so could likely support a clean state engine.
real C has a pretty klunky case syntax, and Ken was trying to avoid the Compiler.
Of course C is a valid choice for those who know C, and have the compiler.
So you could host that on an iPad, and send byte codes to a small loader/VM on the Prop ?
Sounds good, any links/examples/code size limits/numeric types ?
How does it manage student typos ?
I've attached a manual for it.
Ummm.... Maybe not that well. That could be impoved though. At least it gives some indication of where in the line the error occured.
The code is here: https://code.google.com/p/xbasic/
XBasic-Manual-revised.docx
Interesting. I see no speed/size comments ?
If it uses a Bytecode VM, does that mean it could also run/step on an iPad ? (at least to the mathops level, pin IO obviously has to be a little imagined )
How large is the Prop resident VM and how does speed compare with spin, or PropBASIC ?
What is the byte-code image of an example program ?
I could not see keywords for WAITCNT/WAITPEQWAITPNE ?
Let's remove the Propellers and replace them with Arduinos!
Whilst we are at it let's replace all that complicated hardware that is the robots and connectivity with robot simulations that run in the iPad. Then the students don't have to be concerned with any of that annoying reality stuff at all.
Back in the seventies we learned programming in school. The computer the school used was in the "cloud", a mainframe far away we talked to via teletype and modem. To make things "simple" we were taught BASIC and an artificial assembly language that was interpretted, a simple model of the real thing.
Of course that meant our progress in actual programming skill or computing education was retarded by at least three years.
This whole project sounds like history repeating itself...
xbasic is a nice language with performance and program sizes comparable to SPIN. All Propellerisms like waitcnt are supported in the Bytecode ASM syntax. Clockmode and speed are set using a config file.
I wrote a big LCD device based application with xbasic. I never got pinched by HUB memory size with it. xbasic also supports xmmc mode.
Sounds good. Do you have an example of how the user gets at Propellerisms like waitcnt ? - the xBasic manual does not find Bytecode or ASM ?
Do all the programming in the browser in JavaScript.
1) The students program, in JS, is edited in the browser with a web based editor/ide with syntax higligting and all good things. There are many ways to do this Web IDE, ACE editor Cloud 9 etc.
2) The JS is run in the browser.
3) Via some simple JS libraries it can send commands to the students robot, start, stop, tern_left, turn_right, whatever. It can also recieve signals from the robot regarding sensors.
4) The robot runs a simple interpreter of those commands and controls the hardware. It also monitors sensors sending data back to the browser.
5) Tablet to robot communication is via WIFI.
This addresses all those suggestions of a simplified language for students to work with and hopefully the communication issues.
It leverages an existing language and run time.
For those who want a graphical "blocks" programming system that can be done very effectively as well. There are "scratch" like systems for assembling programs from graphical elements that become JavaScript. As used on Espruino and others.
If the student happens to have FireFox or Chrome they have very full featured debug tools buit in.
JavaScript is a significantly less useless language to learn than BASIC, Forth, dare I say it even Spin, for most students.
JavaScript is very easy to get started with as the Espruiono project demonstrates.
-Phil
I can see that could have a place for initial learning, but with that topology, unplug the Wifi, and the bot is lobotomised.
I guess that is a lesson in itself
The next class can cover 'Why do we need autonomous operation' ?
I am currently infatuated with JavaScript. It has features that only recently Java and C++ has have tried to implement. First class functions, Lambdas, closures, etc. It's evented model of programming makes many jobs very easy. It's significantly easier to develop some kinds of programs in and the results can perform as well as the C++ counterparts. It works in the browser it works on the server it works on embedded systems. What's not to like?
I love C and C++ too. Sometimes I think the best thing you can do in C++ is write a JavaScript interpreter so that you can then get on an develop your application quickly and easily:) The Qt guys have, after many decades, realized the truth of this and done exactly that, they now push the idea of writing your GUI apps in JavaScript. See QML.
I'm into Python. I'm into Spin. Spin and the PropTool/BST/SimpleIDE is a wonderful thing. Spin/PASM are such a perfectly, dare I say it, "synergistic" solution for the Propeller. I would not dream of using Spin anywhere else though.
This month I'm having to make changes to a big Pascal project. Object Pascal is OK. Nice because it compiles in a flash.
I hate any language that relies on the use of $.
BASIC and Forth give me migraines. I'd rather hack x86 assembler in old fashioned 16 bit segmented mode!
Anyway, language wars aside, my comment was just an observation that JS is more likely something students would be able to use elsewhere. A transferable skill rather than some one off language that they might spend hours getting to grips with only to never use again.
jmg, Very true. Oh yeah.
At that point you just move the JavaScript execution to the Robot by adding a Raspberry Pi (ducks) or Espruino board to the robot. Espruino is dirt cheap.
or, you could use a careful subset (checked with a javascript module, of course ) and then target a Prop hosted variant.
Of course, you now need a Prop specific byte code compiler somewhere. ( a .js Parser version of xBasic perhaps ? )
I'm glad we're back to parsing languages and compiling to some intermediate byte code that can be sent to a vm running on the Prop or some intermediate processor.
I guess its not Bizarro world after all.