Please add Robot support tools

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Please add Robot support tools

Kirk Fraser
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



Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Casey Ransberger-2
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:
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







Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Eliot Miranda-2
In reply to this post by Kirk Fraser
Hi Kirk,

On Feb 16, 2015, at 9:17 AM, Kirk Fraser <[hidden email]> wrote:

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.

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?



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




Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Herbert König
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?





Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

timrowledge

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.



Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Eliot Miranda-2
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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Jon Hylands
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,

    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.
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Jon Hylands
Here's a couple links I forgot to add to my post:



- Jon


On Thu, Feb 19, 2015 at 12:57 PM, Jon Hylands <[hidden email]> wrote:
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,

    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.
>
>
>





Reply | Threaded
Open this post in threaded view
|

re: Please add Robot support tools

ccrraaiigg
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)


Reply | Threaded
Open this post in threaded view
|

re: Please add Robot support tools

Jon Hylands
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:

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
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)





Reply | Threaded
Open this post in threaded view
|

re: Please add Robot support tools

ccrraaiigg

> 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)


Reply | Threaded
Open this post in threaded view
|

re: Please add Robot support tools

Jon Hylands

With MicroPython, they use a C library called HAL to access it - I'm not sure of all the details, but I could find out.

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:

> 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
<a href="tel:%2B31%20%20%206%202757%207177" value="+31627577177">+31 6 2757 7177 (SMS ok)
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547 (no SMS)





Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

dcorking
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

Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

timrowledge

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



Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

dcorking
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

Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

Herbert König
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Please add Robot support tools

timrowledge
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&copy.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: KFP: Kindle Fire in Printer