Here are improvements to make Squeak more useful for Robot control.
1) Add machine vision tools. I'm told eToys has video camera access but more access to each frame is needed for autonomous robot control including "contour" to reduce the image to arcs and lines to start visual object identification and measurement of object speed and direction as the robot is moving, to either intercept or avoid an object. The same arcs and lines may in some applications be processed into readable text, read your lips, or other interesting things. 2) Method to stop Garbage Collection. I see Squeak 4.5 has a menu item to perform garbage collection so performing collections can be put under program control but there should also be a message to stop any garbage collection until requested or resumed. Why? Imagine you are in a self-driving car powered by Squeak. You enter a curve, turn, or need to stop while going 60 MPH then encounter a 100 millisecond delay for garbage collection. That scenario could put you 8 feet off course into a canyon, oncoming traffic, or a child chasing a ball. So the only way is to use two Squeaks operating in separate cores and use socket communication to guarantee one Squeak is paying close attention to the road while the other collects its garbage, trading off as needed. Perhaps a measure of the garbage pile and growth rate would also help decide which image gets to proceed. 3) The Raspberry Pi has many pins to connect electronics to. Supporting those could potentially provide control for many projects for children and adults. Thank you. Kirk W. Fraser
www.JesusGospelChurch.com - Replace the fraud churches with the true church.
http://freetom.info - Example of False Justice common in America |
1) You doIt:) 2) I know why you want this. Realtime stuff. You'd have to modify the VM, and deal with new bottlenecks and potential (read: certain) crashes when the system runs out of memory, not to mention deciding on another way of freeing space (Objective-C does this with reference counting. Recently they've added automatic reference counting, which sounds interesting, but I haven't explored it.) Anyway, for most people using the system, an easy way to shut down the garbage collector for the entire system would be catastrophically bad news. I don't think this should be built-in. Maybe a VM plugin to do it would be okay, if someone figured out how to do it that way. 3) Yeah, that's cool. I bet there are already people doing stuff like this. I thought I saw a tim post that mentioned something like this. The Pi is relatively new, but I feel really confident that if we give it some time, we'll have excellent support for that machine. I have and use one myself. I'll add a few 4) here. While we're sending out wants into the ether. It'd be great to get a package supporting OpenGL ES and maybe some 3D printing/CADD software to go with it. Would help with doing simulations of e.g. autonomous vehicles; presently the 3D stuff seems pretty tangled up with Croquet. Wouldn't be surprised if someone had something that did the latter already, but hasn't yet been cajoled into taking the open-source plunge! Another thing I'd like to see is some stuff for laying out and designing chips. It would be a quantum leap for Squeak to not only be the instrument of it's own design software-wise, but also the instrument of the design of the hardware that its software runs on. Jecel, anybody? :D One of the things I love about Squeak is all of the possibilities it presents. We can absolutely make it do whatever we want, if we're willing to do our homework, and then get it done. On Mon, Feb 16, 2015 at 9:17 AM, Kirk Fraser <[hidden email]> wrote:
|
In reply to this post by Kirk Fraser
Hi Kirk,
|
Hi,
unless we run under a real time OS the OS will prevent a process from getting CPU cycles for arbitrary timespans. So you cannot ensure that a Squeak program on a Pi will prevent a car from bumping into an obstacle even if you set a very short pause time for GC. Otherwise I'd set the pause equal to the longest time the OS will pause Squeak. Cheers, Herbert Am 17.02.2015 um 05:06 schrieb Eliot
Miranda:
Instead of turning off GC, which will mean that eventually you'll run out if memory, you should ask what is the maximum pause time you want. Pause times for the scavenger in Sour are around a millisecond on typical hardware. Spur will introduce an incremental global scan-mark to collect old space some time this year and it will be set to have similar pause times as the scavenger. So how far would your car drift in 2ms? If you could tune the VM to pause for less than this, what pause time would be acceptable? Can you provide the range of times that spans from marginal to more than satisfactory? |
On 17-02-2015, at 2:44 AM, Herbert König <[hidden email]> wrote: > Hi, > > unless we run under a real time OS the OS will prevent a process from getting CPU cycles for arbitrary timespans. There are bare-metal kernels for Pi, and RISC OS, which whilst not strictly speaking RTOS is pretty damn close. If you run Squeak on RISC OS with no other apps you can get consistent sub-millisecond ticks etc. Linux does quite a few useful things but the more I work on the Pi the more I appreciate how many deeply annoying things it does too. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Paralyzed from the neck up. |
Tim,
what about a SqueakNOS approach. What software support is there? Xen etc... Eliot (phone) On Feb 17, 2015, at 9:59 AM, tim Rowledge <[hidden email]> wrote: > > On 17-02-2015, at 2:44 AM, Herbert König <[hidden email]> wrote: > >> Hi, >> >> unless we run under a real time OS the OS will prevent a process from getting CPU cycles for arbitrary timespans. > > There are bare-metal kernels for Pi, and RISC OS, which whilst not strictly speaking RTOS is pretty damn close. If you run Squeak on RISC OS with no other apps you can get consistent sub-millisecond ticks etc. Linux does quite a few useful things but the more I work on the Pi the more I appreciate how many deeply annoying things it does too. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- Paralyzed from the neck up. > > > |
I'd really like to see a pared-down version of Squeak that would fit on the same hardware that MicroPython runs on (a Cortex M4 chip running at 168 MHz, with 192 KB of RAM and 1 MB of FLASH). Maybe something like Little Smalltalk. No user interface beyond a simple REPL. I've got a couple robots being controlled now with custom boards I designed running MicroPython on this chip. - Jon On Thu, Feb 19, 2015 at 10:59 AM, Eliot Miranda <[hidden email]> wrote: Tim, |
Here's a couple links I forgot to add to my post: MicroPython: http://micropython.org/ NanoSeeker (one of my robots): http://blog.huv.com/2014/10/nanoseeker-v21-populated-board.html - Jon On Thu, Feb 19, 2015 at 12:57 PM, Jon Hylands <[hidden email]> wrote:
|
In reply to this post by Jon Hylands
Hi Jon and all-- > I'd really like to see a pared-down version of Squeak that would fit > on the same hardware that MicroPython runs on (a Cortex M4 chip > running at 168 MHz, with 192 KB of RAM and 1 MB of FLASH)... No user > interface beyond a simple REPL. Would there be a network interface? I can make an object memory with a network-based REPL (based on, for example, web services or telnet) that would fit in either the FLASH or RAM. The virtual machine still needs paring, and I would like some pairing on that. :) Currently the VM would take up almost all of the FLASH, but there's still lots that can be left out. http://netjam.org/context/smallest -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Craig, That sounds interesting - I had forgotten about Context when I wrote that email. It would be better if the REPL could be done through either a hardware serial port, or the USB/serial interface. To add networking is doable, but requires additional hardware modules. The tricky part in all this, once you have the VM and image actually running, is to interface with all the hardware capabilities of the chip. MicroPython uses a uSD card (which is mounted as a flash drive on the host PC via composite USB) to store source files - they are compiled on demand from source when you boot the chip. - Jon On Fri, Feb 20, 2015 at 4:35 AM, Craig Latta <[hidden email]> wrote:
|
> It would be better if the REPL could be done through either a hardware > serial port, or the USB/serial interface. Cool, I've supported hardware serial ports, too. I think USB would be straightforward, but I haven't done it before. > The tricky part in all this, once you have the VM and image actually > running, is to interface with all the hardware capabilities of the > chip. How are they accessible? -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
USB is basically just like a hardware serial port I think, so it shouldn't be hard. - Jon On Fri, Feb 20, 2015 at 3:11 PM, Craig Latta <[hidden email]> wrote:
|
In reply to this post by Casey Ransberger-2
On Mon, Feb 16, 2015 at 9:17 AM, Kirk Fraser <[hidden email]> wrote
>> 3) The Raspberry Pi has many pins to connect electronics to. Supporting >> those could potentially provide control for many projects for children and >> adults. On Tue, Feb 17, 2015 at 3:15 AM, Casey Ransberger <[hidden email]> wrote: > 3) Yeah, that's cool. I bet there are already people doing stuff like this. I have read that there is a version of Scratch that controls Raspberry Pi GPIO pins for input and output. See: http://simplesi.net/scratchgpio/scratch-raspberrypi-gpio/ By the way, Physical Etoys is an amazing Squeak project that supports lots of hobby and educational robotic platforms, with Lego NXT, Arduino and Duinobot built in. However it doesn't support Raspberry Pi's I/O pins, but only those boards that you can connect to a computer's USB. (Some Physical Etoys are Windows only, so take care to choose one that works on Raspberry Pi.) http://tecnodacta.com.ar/gira/projects/physical-etoys/ Have fun! David |
On 25-02-2015, at 6:19 AM, David Corking <[hidden email]> wrote: > On Mon, Feb 16, 2015 at 9:17 AM, Kirk Fraser <[hidden email]> wrote > >>> 3) The Raspberry Pi has many pins to connect electronics to. Supporting >>> those could potentially provide control for many projects for children and >>> adults. > > On Tue, Feb 17, 2015 at 3:15 AM, Casey Ransberger > <[hidden email]> wrote: > >> 3) Yeah, that's cool. I bet there are already people doing stuff like this. > > I have read that there is a version of Scratch that controls Raspberry > Pi GPIO pins for input and output. See: > > http://simplesi.net/scratchgpio/scratch-raspberrypi-gpio/ Si’s scratchGPIO is a python sorta-server app that listens to the Scratch broadcasts and handles all sorts of wild and whacky cases. It also broadcasts back sensor values etc. It’s pretty damn clever, although the code is, well, a bit grungy in places. It’s also Python. I’m not a huge fan of vast chunks of text in files. And whitespace being the major syntactical determinant of semantics? Eek. There’s also a bundle of Python based stuff from Pridopia in the uk to support there range of add-on boards. I know of several people working on more direct gpio/pi access - Doug, Marten, Herbert, me - from Squeak and/or scratch. I have a fairly nicely working demo that can do basic gpio pin control and i2c device support for PiGlow/PiFace etc. Doing things in squeak allows some options not available to any outside code such as providing lists of understood broadcasts & variables, UI access etc. Anyone interested in the latest state of scratch on squeak can try running the current Pi release - https://copy.com/lmzI1gwLrdfYuxzf Obviously it runs on all modern platforms. To get behind the friendly facade, shift-click on the top half of the $R in ‘Scratch’ and choose ‘turn fillscreen off’. For robot specific stuff there is (or at least was) Enchanting, a variant that has lots of ‘bot stuff. And there is ‘S4A’ that provides scratchy arduino programming tools. And there is Phratch, which is a pharo image with scratch stuff and a lot of interesting extensions. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HEM: Hide Evidence of Malfunction |
Thanks, Tim, for all those tips.
You wrote: > I have a fairly nicely working demo that can do basic gpio pin control and i2c device > support for PiGlow/PiFace etc. Doing things in squeak allows some options not available to any > outside code such as providing lists of understood broadcasts & variables, UI access etc. > > Anyone interested in the latest state of scratch on squeak can try running the current Pi release - > > https://copy.com/lmzI1gwLrdfYuxzf And thanks for the NuScratch image. Are any VM changes, configs or VM plugins needed to access Pi GPIO pins from NuScratch on Raspbian? Do you (or Doug, Marten or Herbert) have a Monticello repo or changesets for your GPIO pin source code ? Have fun! David |
Hi David,
I plan to release my code together with Douglas McPherson. What keeps me is the lack of documentation of what I've done and I haven't yet coordinated with Douglas. I use the IO pins via the file interface. I use I2C via OS-Process. You can mail me in private and I send you my code and reply to questions (will help me to cook up docs). Cheers, Herbert Am 26.02.2015 um 12:15 schrieb David Corking: > Thanks, Tim, for all those tips. > > You wrote: > >> I have a fairly nicely working demo that can do basic gpio pin control and i2c device >> support for PiGlow/PiFace etc. Doing things in squeak allows some options not available to any > outside code such as providing lists of understood broadcasts & variables, UI access etc. >> >> Anyone interested in the latest state of scratch on squeak can try running the current Pi release - >> >> https://copy.com/lmzI1gwLrdfYuxzf > And thanks for the NuScratch image. Are any VM changes, configs or VM > plugins needed to access Pi GPIO pins from NuScratch on Raspbian? > > Do you (or Doug, Marten or Herbert) have a Monticello repo or > changesets for your GPIO pin source code ? > > Have fun! David > |
In reply to this post by dcorking
On 26-02-2015, at 3:15 AM, David Corking <[hidden email]> wrote: > And thanks for the NuScratch image. Are any VM changes, configs or VM > plugins needed to access Pi GPIO pins from NuScratch on Raspbian? No extra vm plugins, though you do need ffi to be working. On a Pi you need to do some magic dancing to configure i2c & spi ( http://www.raspberrypi.org/documentation/configuration/raspi-config.md) and if your OS version is a bit old there is some /etc/module-thingy editing. This just got a bit more complex to describe because Raspbian now support Device Tree. Spelling it correctly is about as far as my knowledge goes. See http://www.raspberrypi.org/documentation/configuration/device-tree.md etc. My code isn’t ready to be seen by others as yet but soon, probably. www.wiringPi.com will tell you how to install wiringPi and hooking up to it is just the same as any other ffi stuff - #<cdecl: void ‘digitalWrite’ (long long) module: ‘wiringPi’> etc. I still haven’t found anything approaching doc for ffi so it’s very much search©. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: KFP: Kindle Fire in Printer |
Free forum by Nabble | Edit this page |