I also taught technology in the classroom for nearly nine years... Computer repair, networking, A+ certification, CISCO CCNA and CCNI.
I would have been thrilled to have access to the Raspberry Pi for my Linux and networking instruction. The reason being is that for the first five years of teaching, I was dependant on a $1,500.00 yearly budget for materials (not counting books). I can't imagine that things have improved much since I quit teaching a decade ago. We did a lot of "community repair" and curbside donation machines to get training accomplished. (It must have worked, as my kids were winning the state competitions every year, and getting jobs.)
I won't argue that there are better linux boxes which could be obtained and used for this purpose, but it's hard to argue the price for cash strapped classrooms.
If the resource is there, there is no reason not to take advantage of it and build on it.
I don't much care if the final solution is Pi based or not, whatever works. My agenda is to campaign for cross-platform and open solutions that everyone can benefit from. Not just rich kids with Apple gear.
I just feel the Raspberry Pi is not starter.
Why exactly? I would have thought it was great place to start. It has pretty much everything required, is very cheap and sitting on peoples desks now apparently. If it turns out to not be up to the load one can always step up to something else.
It is highly likely to bog down the teaching agenda.
How exactly? Why any more than any other device that might be used?
...but the real solution is a Linux machine of larger scale and faster speed.
My original thought was there would be one such device per student. No problems with load there. A single server may be easier to manage though. It has yet to be determined what the load issues may be. Serving up a web IDE is not strenuous and a few Spin compilations per minute is hardly a worry. I might worry about having so many wifi connections in one room but that is a problem no matter what machine is used.
My ire comes from there being huge unrealistic expectations raised by Raspberry Pi...
No unrealistic expectations spotted in this thread so far:)
...when the prime innovation they have provided is a delivering a $25 micro-computer.
Many would say that is quite amazing. No one else has pulled it off yet either.
Everything else is borrows - the concept of a credit card size computer (which I am wary of as too small), the use of OpenAVR, the Linux and Android OSes, the money to make the darned things.
WTF? A year before the Pi came out I scoured the planet for ARM boards of about that size. I found them too, at a price of nearly 200 euros!
What has OpenAVR got to do with anything? Never even seen it mentioned in Pi circles.
Android is not a supported OS on the Pi.
What money to make the "darned things"? It was all started on a shoe string.
This is a Linux wifi server project first and foremost and doesn't require the GPIO on the Pi.
That is true. Any box with enough MIPs, memory and interfaces will do. Except, I would want to program my Props directly via UART connection. Which is, on the GPIO header!
I have been a teacher and can see the difference between a real educational tool and a toy.
Are you saying that the Pi is not an educational tool? Why?
In my mind the iPad is the "toy" in this discussion. Props and Pi's are the "real stuff".
Anyway, this is all a diversion from solving the iPad problem.
Seems dgately has shown how it can be done quite effectively already. On a Pi !
SD6.28: 8GB Full size SD card pre-loaded for the whole PI experience with with propeller app bundle and GUI enabled.
SD3.14: like SD6.28 except headless ....
USB Share HUB: Host powered 3 or 4 Port USB HUB such as eForCity 290229
USB Class HUB: External power class room sharing HUB such as DLINK DUB-H7
Single User Example: ActivityBot + PiKit + SD6.28
Multi User Example: PiKit + SD6.28 + USB Class HUB
Propeller app bundle for SD card setup by Parallax:
RPi Linux + SimpleIDE SpinSide Bundle (with OpenSpin, etc...) pre-installed.
Question: does the WebIDE work with headless operation? I.E. no window manager GUI running?
I might be misunderstanding your question, but WebIDE works just fine with headless operation. I'm running it here on the RaspPi/Propeller combo and accessing it from another workstation. It is also working just fine from my android tablet.
I might be misunderstanding your question, but WebIDE works just fine with headless operation. I'm running it here on the RaspPi/Propeller combo and accessing it from another workstation. It is also working just fine from my android tablet.
Jeff
Headless as in horseman, rather than not having a bathroom (NAVY term for head)
Do you have the RPi configured to boot the Window Manager GUI so you can use your head (Monitor/Keyboard/Mouse) ?
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.
[*]Compilers, should they exist, would operate remotely on a server.
To some extent this gets us back to the idea of using a RaspberryPi or something like that as a compile server. I guess the difference would be that the resulting binary images would be sent back to the iPad and downloaded directly to the ActivityBot via Wi-Fi? Would you expect to use something like a WiFly module plugged into the Xbee port on the ActivityBot?
I think what Ken is referring to is a program that's already downloaded to the ActivityBot in a more traditional manner and which accepts commands and simple scripts to program its behavior. Such commands could come from a text editor or be output from a GUI. This is in line with one of Andy's recent posts to come up with a command language for the ActivityBot.
I think what Ken is referring to is a program that's already downloaded to the ActivityBot in a more traditional manner and which accepts commands and simple scripts to program its behavior. Such commands could come from a text editor or be output from a GUI. This is in line with one of Andy's recent posts to come up with a command language for the ActivityBot.
-Phil
Yes, I understand that that is one of the options. I didn't think they had ruled out doing actual C programming on the iPad though since he also mentioned porting SimpleIDE.
There already exist code / text editors for the iPad that can be used as models. There already exist WiFi interfaces that can be used for both downloading executable code and acting as a control console for the Propeller (WiFly and its equivalents). If for some reason you don't want to just implement a Spin compiler on the iPad as part of the IDE, you could do a GUI like that for the S2, but generate Spin binary code for downloading. It would be much simpler than a full Spin compiler and GUI although that could be done fairly easily with the Open Spin compiler. I think the most future mileage would be to have a code / text editor and open Spin compiler that runs on the iPad and downloads via a WiFi Telnet connection to a Propeller, then acts as a simple PST-like terminal over the same Telnet connection.
A simple downloader (like the Propeller Backpack's) could be written in TechBasic on the iPad which has access to Internet sockets. This would allow a prototype to be quickly implemented and tested.
Having an online editor which allows multiple students and teachers to edit / view / compile the exact same source-code at the same time I think would be amazing and integration into the compile and load chain would be trivial.
I think what Ken is referring to is a program that's already downloaded to the ActivityBot in a more traditional manner and which accepts commands and simple scripts to program its behavior. Such commands could come from a text editor or be output from a GUI. This is in line with one of Andy's recent posts to come up with a command language for the ActivityBot.
Do you have the RPi configured to boot the Window Manager GUI so you can use your head (Monitor/Keyboard/Mouse) ?
Yes, but naturally, I loose a USB port when I plug in the Quickstart via USB. I don't care for X, personally, I'm a console hacker. But it does work just fine when I initate a startx and webIDE works fine in a local copy of midori web-browser.
Yes, I understand that that is one of the options. I didn't think they had ruled out doing actual C programming on the iPad though since he also mentioned porting SimpleIDE.
I'm not assuming that the two are mutually exclusive. Suppose you wrote C code in SIDE but it resulted in a set of bytes that configured the ActivityBot over WiFi rather than a full compile/download via server.
It should be programmable enough to be used as a WiFiPropTool.
You just need:
- new rev of Activity Board, removing FTDI, adding XBee style headers, appropriately wired to WiFly for TX/RX/NRST or on-board WiFly module
- ide/compiler running on iPad, talking to WiFly to program Prop & serial debugging
Issues:
- Apple will likely flip out over generic serial I/O over WiFi, but may not be able to do much about it due to TCP/IP being an essential standard.
I'm not assuming that the two are mutually exclusive. Suppose you wrote C code in SIDE but it resulted in a set of bytes that configured the ActivityBot over WiFi rather than a full compile/download via server.
I guess that's true. That would involve writing a C compiler that generates these bytecodes though. Not a trivial task.
I'm not assuming that the two are mutually exclusive. Suppose you wrote C code in SIDE but it resulted in a set of bytes that configured the ActivityBot over WiFi rather than a full compile/download via server.
It seems that again, the idea of plugging in devices comes up (drag/drop icons). In this case, it's sending device code as loadable drivers to propeller via a monitor.
Ken got good technical advice regarding the iPad - the strong points were identified ok. I wouldn't port SIDE directly on the iPad unless there is a purpose of doing so, the IDE can be on the server where it is compiled anyway, unless you want to make a specific APP that sends data to the server.
I also think a higher level than C approach is strongly worth considering. 12 blocks, or a refinement thereof, may be a good start. Also, research some of the simplified robotics languages as pioneered in academia (See CMU robotics, MIT or others).
I'm not assuming that the two are mutually exclusive. Suppose you wrote C code in SIDE but it resulted in a set of bytes that configured the ActivityBot over WiFi rather than a full compile/download via server.
If you're mostly interested in controlling a robot with a simple command language maybe this is a good opportunity to do something like the S2 IDE. This could probably also be combined with an effort to make an S2/ActivityBot IDE available on the Mac and Linux as well.
If it can be used to program a Prop over the air then that is a solution worth looking at.
There is no need for the compilers to run on the iPad. They can run on a server locally or perhaps anywhere in the world.
The route is:
1) iPad - Edit code in some web IDE or other. (WebIDE, Cloud9 ...) Hit compile/run button.
2) Code flies to server and is compiled, compiler messages come back to browser. The binary stays on server.
3) Binaries go from server to WiFly to Prop.
4) Any serial output from Prop goes to WiFly to server and back to the users browser in a terminal window. (tty.js)
web sockets are a great way to stream data up and down from Web IDE to server. This kind of solution works for any iPad, Android, Chromebook whatever browser solution.
Don't tell me, the iPad does not support web sockets, I'll scream.
Some of these are things I just don't know and curious about with the WiFLy, others are directly related to the school environment and administration of the "solution" - the comments are meant to be negative or inflammatory in any way - just thought provoking.
OK, so I take an ActivityBOT and plug a WiFly into it, ok, good so far.
Connectivity:
The WiFLy needs a wireless network to talk to.
- is this the school's wireless network?
- If so, are they going to allow "internet of things" type devices to hook up?
- Does the WiFLy need to be configured in any special way to connect to this network? Who will do this?
- If it is given a dynamic IP address via DHCP, how do you get this out of a WiFly (assuming you come back from Summer vacation and all the DHCP leases have expired). Who will do this?
- If the school doesn't allow connection to their network, you need to set up a wireless network for the ActivityBOTs and the iPads (tablets).
- If you provide a private wireless network, most of the questions above, still apply as to WiFly administration.
OK, so now I have my WiFly'd robot connected to a wireless network.
I assume the iPad (tablet) can easily connect to this network.
There will need to be an App for this. If you have no servers on the network, it can't be a web based HTML5 app running in a browser, it needs to be an app written specific to each tablet or at least built for each tablet type if you can find a common code solution. The downloadable from the various stores.
How will the app see the Robot? Hopefully nothing more complicated than an IP:port that it can open to and start talking with.
On the Robot side, what will it be talking to?
It sounds like the generation of a chunk of downloadable Propeller executable code will not be allowed to happen on the iPad. This moves us up a layer or two in abstraction where we are generating a stream of commands (byte codes) to send to a Robot VM or command/sensor monitor of some sort.
Am I headed in the right direction here for the initial support iPad solution??
It sounds like the generation of a chunk of downloadable Propeller executable code will not be allowed to happen on the iPad.
I'm not sure this is true. I think what Apple has resisted are iPad/iPhone apps that allowed you to generate code to run on the iPad or iPhone. Generating blobs of code to run on another processor at the end of a Wi-Fi connection may not be a problem.
I'm not sure this is true. I think what Apple has resisted are iPad/iPhone apps that allowed you to generate code to run on the iPad or iPhone. Generating blobs of code to run on another processor at the end of a Wi-Fi connection may not be a problem.
That's what I had normally thought but Ken had this in his last "for discussion" message:
"Compilers, should they exist, would operate remotely on a server."
That led me to rule out any true compilation of an executable for the Propeller done on the iPad.
I'm trying to stay as best I can within the requirements Ken presented.
Having an online editor which allows multiple students and teachers to edit / view / compile the exact same source-code at the same time I think would be amazing and integration into the compile and load chain would be trivial.
The Apple guy also identified this kind of solution as a huge benefit to our products. He didn't mention etherpad specifically, but certainly embodied this concept.
After a quick google, it looks like websocket support is limited to old, pre-standard version, and binary packets are limited by not allowing 0x00 and 0xFF to be embedded in them.
If it can be used to program a Prop over the air then that is a solution worth looking at.
There is no need for the compilers to run on the iPad. They can run on a server locally or perhaps anywhere in the world.
The route is:
1) iPad - Edit code in some web IDE or other. (WebIDE, Cloud9 ...) Hit compile/run button.
2) Code flies to server and is compiled, compiler messages come back to browser. The binary stays on server.
3) Binaries go from server to WiFly to Prop.
4) Any serial output from Prop goes to WiFly to server and back to the users browser in a terminal window. (tty.js)
web sockets are a great way to stream data up and down from Web IDE to server. This kind of solution works for any iPad, Android, Chromebook whatever browser solution.
Don't tell me, the iPad does not support web sockets, I'll scream.
True. I had considered that but thought it could get crazy in a classroom environment but I guess no more than regular WiFi. If you got all the kids organized and they only grabbed THEIR robot's. The Parrot AR quadcopter uses Ad Hoc mode and it works well. With Ad Hoc, they could also take the robot out of the classroom.
Comments
I also taught technology in the classroom for nearly nine years... Computer repair, networking, A+ certification, CISCO CCNA and CCNI.
I would have been thrilled to have access to the Raspberry Pi for my Linux and networking instruction. The reason being is that for the first five years of teaching, I was dependant on a $1,500.00 yearly budget for materials (not counting books). I can't imagine that things have improved much since I quit teaching a decade ago. We did a lot of "community repair" and curbside donation machines to get training accomplished. (It must have worked, as my kids were winning the state competitions every year, and getting jobs.)
I won't argue that there are better linux boxes which could be obtained and used for this purpose, but it's hard to argue the price for cash strapped classrooms.
If the resource is there, there is no reason not to take advantage of it and build on it.
Jeff
There's that Pi negativity again.
I don't much care if the final solution is Pi based or not, whatever works. My agenda is to campaign for cross-platform and open solutions that everyone can benefit from. Not just rich kids with Apple gear. Why exactly? I would have thought it was great place to start. It has pretty much everything required, is very cheap and sitting on peoples desks now apparently. If it turns out to not be up to the load one can always step up to something else. How exactly? Why any more than any other device that might be used? My original thought was there would be one such device per student. No problems with load there. A single server may be easier to manage though. It has yet to be determined what the load issues may be. Serving up a web IDE is not strenuous and a few Spin compilations per minute is hardly a worry. I might worry about having so many wifi connections in one room but that is a problem no matter what machine is used. No unrealistic expectations spotted in this thread so far:) Many would say that is quite amazing. No one else has pulled it off yet either. WTF? A year before the Pi came out I scoured the planet for ARM boards of about that size. I found them too, at a price of nearly 200 euros!
What has OpenAVR got to do with anything? Never even seen it mentioned in Pi circles.
Android is not a supported OS on the Pi.
What money to make the "darned things"? It was all started on a shoe string. That is true. Any box with enough MIPs, memory and interfaces will do. Except, I would want to program my Props directly via UART connection. Which is, on the GPIO header! Are you saying that the Pi is not an educational tool? Why?
In my mind the iPad is the "toy" in this discussion. Props and Pi's are the "real stuff".
Anyway, this is all a diversion from solving the iPad problem.
Seems dgately has shown how it can be done quite effectively already. On a Pi !
Some PropellerPi "packaging" ideas:
PiKit: AC/USB 2.0A charger wall-wart + RPi + WiFi USB Dongle
SD6.28: 8GB Full size SD card pre-loaded for the whole PI experience with with propeller app bundle and GUI enabled.
SD3.14: like SD6.28 except headless ....
USB Share HUB: Host powered 3 or 4 Port USB HUB such as eForCity 290229
USB Class HUB: External power class room sharing HUB such as DLINK DUB-H7
Single User Example: ActivityBot + PiKit + SD6.28
Multi User Example: PiKit + SD6.28 + USB Class HUB
Propeller app bundle for SD card setup by Parallax:
RPi Linux + SimpleIDE SpinSide Bundle (with OpenSpin, etc...) pre-installed.
I might be misunderstanding your question, but WebIDE works just fine with headless operation. I'm running it here on the RaspPi/Propeller combo and accessing it from another workstation. It is also working just fine from my android tablet.
Jeff
Headless as in horseman, rather than not having a bathroom (NAVY term for head)
Do you have the RPi configured to boot the Window Manager GUI so you can use your head (Monitor/Keyboard/Mouse) ?
When you have a head on them, they initially boot to the shell and then you startx to go GUI.
(of course, I tend to get the wrong versions of things, so many I should try a head!
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
-Phil
A simple downloader (like the Propeller Backpack's) could be written in TechBasic on the iPad which has access to Internet sockets. This would allow a prototype to be quickly implemented and tested.
http://etherpad.org/
Having an online editor which allows multiple students and teachers to edit / view / compile the exact same source-code at the same time I think would be amazing and integration into the compile and load chain would be trivial.
Yes, this is what I'm suggesting.
Yes, but naturally, I loose a USB port when I plug in the Quickstart via USB. I don't care for X, personally, I'm a console hacker.
I'm not assuming that the two are mutually exclusive. Suppose you wrote C code in SIDE but it resulted in a set of bytes that configured the ActivityBot over WiFi rather than a full compile/download via server.
https://www.sparkfun.com/products/10822
WiFly looks good.
It should be programmable enough to be used as a WiFiPropTool.
You just need:
- new rev of Activity Board, removing FTDI, adding XBee style headers, appropriately wired to WiFly for TX/RX/NRST or on-board WiFly module
- ide/compiler running on iPad, talking to WiFly to program Prop & serial debugging
Issues:
- Apple will likely flip out over generic serial I/O over WiFi, but may not be able to do much about it due to TCP/IP being an essential standard.
http://dx.com/p/redeye-mini-universal-remote-adapter-for-iphone-ipod-touch-ipad-106254
$16 and sends IR commands. You'd need an IR receiver on the bot, but I think that's pretty simple...
I think the bot could just pretend to be a VCR or something...
I also think a higher level than C approach is strongly worth considering. 12 blocks, or a refinement thereof, may be a good start. Also, research some of the simplified robotics languages as pioneered in academia (See CMU robotics, MIT or others).
WiFly look very nice.
If it can be used to program a Prop over the air then that is a solution worth looking at.
There is no need for the compilers to run on the iPad. They can run on a server locally or perhaps anywhere in the world.
The route is:
1) iPad - Edit code in some web IDE or other. (WebIDE, Cloud9 ...) Hit compile/run button.
2) Code flies to server and is compiled, compiler messages come back to browser. The binary stays on server.
3) Binaries go from server to WiFly to Prop.
4) Any serial output from Prop goes to WiFly to server and back to the users browser in a terminal window. (tty.js)
web sockets are a great way to stream data up and down from Web IDE to server. This kind of solution works for any iPad, Android, Chromebook whatever browser solution.
Don't tell me, the iPad does not support web sockets, I'll scream.
OK, so I take an ActivityBOT and plug a WiFly into it, ok, good so far.
Connectivity:
The WiFLy needs a wireless network to talk to.
- is this the school's wireless network?
- If so, are they going to allow "internet of things" type devices to hook up?
- Does the WiFLy need to be configured in any special way to connect to this network? Who will do this?
- If it is given a dynamic IP address via DHCP, how do you get this out of a WiFly (assuming you come back from Summer vacation and all the DHCP leases have expired). Who will do this?
- If the school doesn't allow connection to their network, you need to set up a wireless network for the ActivityBOTs and the iPads (tablets).
- If you provide a private wireless network, most of the questions above, still apply as to WiFly administration.
OK, so now I have my WiFly'd robot connected to a wireless network.
I assume the iPad (tablet) can easily connect to this network.
There will need to be an App for this. If you have no servers on the network, it can't be a web based HTML5 app running in a browser, it needs to be an app written specific to each tablet or at least built for each tablet type if you can find a common code solution. The downloadable from the various stores.
How will the app see the Robot? Hopefully nothing more complicated than an IP:port that it can open to and start talking with.
On the Robot side, what will it be talking to?
It sounds like the generation of a chunk of downloadable Propeller executable code will not be allowed to happen on the iPad. This moves us up a layer or two in abstraction where we are generating a stream of commands (byte codes) to send to a Robot VM or command/sensor monitor of some sort.
Am I headed in the right direction here for the initial support iPad solution??
That's what I had normally thought but Ken had this in his last "for discussion" message:
"Compilers, should they exist, would operate remotely on a server."
That led me to rule out any true compilation of an executable for the Propeller done on the iPad.
I'm trying to stay as best I can within the requirements Ken presented.
The Apple guy also identified this kind of solution as a huge benefit to our products. He didn't mention etherpad specifically, but certainly embodied this concept.
After a quick google, it looks like websocket support is limited to old, pre-standard version, and binary packets are limited by not allowing 0x00 and 0xFF to be embedded in them.
http://stackoverflow.com/questions/9894934/websockets-on-ipad-is-there-something-extra-that-needs-to-be-done
http://stackoverflow.com/questions/5574385/websockets-on-ios
http://engineering.linkedin.com/mobile/linkedin-ipad-nativeweb-messaging-bridge-and-websockets
I suppose the WiFly could hex encode/decode binaries and the serial link on the fly.
Geez, all of these problems would disappear with Android!
Maybe not. Ad Hoc Mode can probably be used.
True. I had considered that but thought it could get crazy in a classroom environment but I guess no more than regular WiFi. If you got all the kids organized and they only grabbed THEIR robot's. The Parrot AR quadcopter uses Ad Hoc mode and it works well. With Ad Hoc, they could also take the robot out of the classroom.