[Newbies] Raspberry Pi v. Raspberry St

[Ben Coman]

Smalltalk FPGA may be of interest...

http://www.slideshare.net/esug/luc-fabresse-iwst2014

http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_From%20Smalltalk%20to%20Silicon_Towards%20a%20methodology%20to%20turn%20Smalltalk%20code%20into%20FPGA.pdf

cheers -ben

On Tue, Jul 14, 2015 at 11:55 AM, Kirk Fraser <overcomer.man at gmail.com> wrote:
> Hi Casey,
>
> Thanks for the suggestion.  I will have multiple connected controller boards
> and with your suggestion maybe I'll try a Pi for each limb and each webcam
> or maybe your ARM9 suggestion.
>
> To prove it's good as a human in performance I want it to do minor
> acrobatics like cartwheels and balancing tricks, maybe a Chuck Norris kick
> or jumping over a fence with one hand on a post.  Or like those free-running
> videos. Stuff I could not do myself. But it all waits on money.  Maybe I'll
> make better progress next year when social security kicks in.
>
> As far as human performance goals, one professor wrote it takes 200 cycles
> per second to hop on one leg.  Somewhere I read human touch can sense 1 in
> 32,000 of an inch.  I don't have the other figures yet.  I may not be able
> to drive an arm as fast as a human boxer - 200 mph but as long as it's fast
> enough to drive a vehicle on a slow road (not I5) that might be enough until
> faster computers are here.
>
> The vision system seems like a major speed bottle neck.  Maybe a mini-cloud
> can take one 64th of the image for each processor analyze it, then assemble
> larger object detection in time for the next frame.  The DARPA Atlas robot
> used 4 cores for each camera I think.  But a mini-cloud set off nearby to
> process vision and return either the objects with measurements or
> instructions would be a lot of work.   The more I write, the more I see why
> the head of DARPA's robots said they cost 1-2 million as you have to hire a
> team of programmers or make a really intricate learning program.
>
> Kirk
>
>
> On Mon, Jul 13, 2015 at 5:58 PM, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
>>
>> Hey Kirk,
>>
>> I like Ralph's suggestion of doing the time/timing specific stuff on a
>> dedicated microcontroller.
>>
>> I'd recommend going one better: use more than one microcontroller. Robots
>> need to do a lot in parallel; if the robot has to stop driving in order to
>> think, that's a problem (although the converse would be decidedly human!)
>> Anyway, it sounds like real-time is not negotiable in your view, so green
>> threads won't cut it either.
>>
>> Mine has... six controllers in total. That's not counting the ARM9 which
>> is more like a full computer (e.g., Linux.)
>>
>> I think six anyway. Could be more hiding in there. Two drive sensors,
>> three drive motors, one is wired up close to the ARM board to coordinate the
>> other controllers on behalf of what the Linux system wants them doing.
>>
>> I'm curious, have you figured out what the average, best, and worst case
>> latencies are on human reflexes? In my view, matching or beating that
>> benchmark is where the money probably is.
>>
>> --C
>>
>> On Jul 6, 2015, at 12:39 PM, Kirk Fraser <overcomer.man at gmail.com> wrote:
>>
>> Ralph Johnson,
>>
>> That's an excellent suggestion and an excellent story, thank you very
>> much!  Letting the human interface in Smalltalk program the robot controller
>> instead of being the robot controller sounds good.
>>
>> My robot uses a network of Parallax microcontroller chips to drive
>> hydraulic valves, which can be programmed via USB for simple tasks like
>> moving one joint from point A to B but since each controller has 8 cores
>> more complex tasks like grasping or walking can be done on the MCU's or on a
>> small Raspberry Pi or other hardware in a non-GC or controllable GC
>> language.
>>
>> A harder part to wrap my head around is handling the webcam vision system
>> and artificial intelligence while remaining time sensitive enough to do time
>> critical tasks like cartwheels and other acrobatic choreography.
>>
>> I know in effect my human mind shuts down most of its intellectual
>> pursuits when engaged in heavy physical activity - maybe the robot must do
>> the same - think more creatively when idling and pay closer attention while
>> working. That takes care of the Ai timing.
>>
>> The heavy load of vision processing appears to need a mini-cloud of cores
>> to reduce time to identify and measure objects from contours and other
>> information.  To guarantee performance they would also need to run a non-GC
>> language that could be programmed from Squeak interactively as new objects
>> are being learned.  I haven't worked with a laser range finder but I suspect
>> they use it to narrow the focus onto moving objects to process video in more
>> detail in those areas.
>>
>> The current buzzword "co-robots" meaning robots that work beside or
>> cooperatively with people working in symbiotic relationships with human
>> partners suggests everyone will need a robot friend, which will require an
>> artificial intelligence capable of intelligent thought.  As most Americans
>> are Christian it would make sense for a human compatible AI to be based on
>> the Bible.  That is what I would love to work on.  But that level of thought
>> needs a creative CG environment like Squeak at present.
>>
>> I've been thinking that using a Smalltalk GUI to issue command rules to
>> set an agenda for automatic text analysis and editing might be fun, letting
>> the computer do the editing instead of me.  That way it could update the AI
>> knowledge like when a preferred synonym is discovered, without taking human
>> time to do much of it beyond the setup.
>>
>> Your wikipedia entry shows a webpage and blog that apparently are dead
>> links.  Would you be interested in being a team member on my SBIR/STTR grant
>> application(s) for AI and Robots responding to:
>> http://www.nsf.gov/publications/pub_summ.jsp?ods_key=nsf15505  I've
>> enlisted help in writing the application from Oregon's Small Business
>> Development Center and will meet with an SBIR road trip in August I'm told.
>> (I was also told I need a Ph.D. on my team since I don't have one.)
>>
>> Kirk Fraser
>>
>>
>> On Mon, Jul 6, 2015 at 4:19 AM, Ralph Johnson <johnson at cs.uiuc.edu> wrote:
>>>
>>> Here is another possibility.
>>>
>>> Take a look at Symbolic Sound, a company that makes a system called Kyma.
>>> http://kyma.symbolicsound.com/
>>>
>>> This company has been around for over twenty years.   Its product has
>>> always been the fastest music synthesis system in the world that gives you
>>> total control over your sound.  And by "total", I mean it gives you the
>>> ability to mathematically specify each sound wave.   If you want, which is
>>> actually too much detail for most people.   And it is all written in
>>> Smalltalk.  Not Squeak, of course, since Squeak wasn't around then.   But it
>>> could have been done in Squeak.   And perhaps they ported it to Squeak.   I
>>> haven't talked to them for a long time so I don't know what they did, but
>>> from the screen shots I think it is still a very old version of VisualWorks.
>>>
>>> Anyway, how do they make it so fast?  How can they make something that
>>> can be used for hours without any GC pauses?
>>>
>>> The trick is that the sound is produced on an attached DSP.   The GUI is
>>> in Smalltalk on a PC, and it generates code for the DSP.   It is non-trivial
>>> making the compiler so fast that when you press "play", it can immediately
>>> start up the DSP and start producing sound.  It does this (rather, it did
>>> this, since they might have changed the way it works) by just producing
>>> enough code to run the DSP for a few seconds and then starting the DSP while
>>> it generates the rest of the code.   Kyma literally is writing the program
>>> into DSP memory at the same time as the DSP is running the program,
>>> producing sound.
>>>
>>> Anyway, maybe that is the right approach to programming robots.   You
>>> don't even need to use two computers.   Imagine you had two computers, one
>>> running Squeak and the other a simple, real-time machine designed for
>>> controlling robots, but not very sophisticated.  Squeak programs the simple
>>> computer, and can change its program dynamically.  The simple computer has
>>> no gc.   Since Squeak is a VM on a computer, the real-time computer can be a
>>> VM, too.  So, you could be running them both on your PC, or you could run
>>> them on two separate computers for better performance.
>>>
>>> I would be happy to talk more about this.  But I'd like to talk about the
>>> beginning of Kyma.   The owners of Symbolic Sound are Carla Scaletti and
>>> Kurt Hebel.   Carla has a PhD in music, and Kurt in Electrical Engineering.
>>> I met Carla after she had her PhD.  She wanted to get a MS in computer
>>> science so she could prove her computer music expertise, and she ended up
>>> getting it with me.   She took my course on OOP&D that used Smalltalk.  For
>>> her class project (back in 1987, I think) she wrote a Smalltalk program that
>>> ran on the Mac and that produced about ten seconds of sound, but it took
>>> several minutes to do it.   Hardly real time.   However, she was used to
>>> using a supercomputer (a Cray?) to generate sounds that still weren't real
>>> time, so she was very pleased that she could do it on the Mac at all, and
>>> though Smalltalk was slower than Fortran, in her opinion the ease of use was
>>> so great that she didn't mind the speed difference.   As she put it, the
>>> speed difference between a Mac and a Cray was bigger than between Smalltalk
>>> and Fortran.  She ended up turning this into the first version of Kyma and
>>> that became the subject of her MS thesis.   I can remember when she showed
>>> it in class.  She was the only woman in the class, and the other students
>>> knew she was a musician, i.e. not *really* a programmer.  She was quiet
>>> during class, so they had not had a chance to have their prejudices
>>> remedied.  Her demo at the end of the semester blew them away.
>>>
>>> Kurt had built a DSP that their lab used.   (The lab was part of the
>>> Plato project, I believe, one of the huge number of creative results of this
>>> very significant project at Illinois.)   It was called the Capybara.  This
>>> was before the time when you could just buy a good DSP on a chip, but that
>>> time came very soon and then they used the commercial chips.  For her MS,
>>> she converted her system to use the Capybara, and this was when she figured
>>> out how to make it start making music within a fraction of a second of
>>> pressing the "play" button.  Kurt also used Smalltalk with the Capybara.
>>> His PhD was about automatically designing digital filters, and his software
>>> also generated code for the Capybara, though it was actually quite different
>>> from Kyma.
>>>
>>> The two of them worked on several different projects over the next few
>>> years, but kept improving Kyma.   Along the way Kurt started building boards
>>> that had several commercial DSPs on them.  Eventually they decided to go
>>> commercial and started Symbolic Sound.
>>>
>>> -Ralph Johnson
>>>
>>> On Sun, Jul 5, 2015 at 9:05 PM, Kirk Fraser <overcomer.man at gmail.com>
>>> wrote:
>>>>
>>>> >> Tim says a multi-core VM is coming for the new Pi.
>>>>
>>>> > Are you *sure* that's what Tim said?
>>>>
>>>> Of course my over hopeful misinterpretation is possible.
>>>>
>>>> "Squeak runs quite well on a Pi, especially a pi2 - and we're working on
>>>> the Cog dynamic translation VM right now, which should with luck triple
>>>> typical performance."  - timrowledge » Thu Feb 19, 2015
>>>>
>>>> https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=100804&p=698818&hilit=Squeak#p698818
>>>>
>>>> > The trick to getting rid of long delays is more a function of
>>>> > preallocating everything you can than getting rid of GC's (I've done some
>>>> > highly interactive stuff in GC environments and preventing GC's is
>>>> > impractical except over short periods of time, minimizing their frequency
>>>> > and duration is very doable)  One of the things I think I
>>>> recently saw that should help you in this regard is FFI memory pinning
>>>> if you're calling out to external code.
>>>>
>>>> Thanks.  Maybe when I find, make, or build a better place to work, I'll
>>>> be able to tackle some of that.  I wouldn't be surprised if a VM is as easy
>>>> as a compiler once one actually starts working on it.
>>>>
>>>>
>>>> On Sun, Jul 5, 2015 at 6:31 PM, Phil (list) <pbpublist at gmail.com> wrote:
>>>>>
>>>>> On Sun, 2015-07-05 at 17:12 -0700, Kirk Fraser wrote:
>>>>> > I used Cuis at first to display hand written G-Codes in graphic form
>>>>> > for a printed circuit board.  I kept up with Cuis through a few
>>>>> > versions and found a couple of bugs for Juan.  Eventually Casey
>>>>> > advised going to Squeak so I did. Perhaps my requests were getting
>>>>> > annoying.
>>>>> >
>>>>>
>>>>> Perhaps you misinterpreted what Casey said?  Definitely have all
>>>>> options
>>>>> (Squeak, Pharo, Cuis etc.) as part of your toolkit.  Squeak in
>>>>> particular has a very active mailing lists and you'll find a lot of
>>>>> existing code to play with.  I personally do most of my development in
>>>>> Cuis, some in Pharo (for things like Seaside that don't yet exist in
>>>>> Cuis), and a bit still in Squeak.  They all have their place depending
>>>>> on your needs.  Given your emphasis on performance, I would think that
>>>>> Cuis is going to be the place where you can maximize it. (all the above
>>>>> Smalltalk variants use essentially the same core VM, it's the plugins
>>>>> and images that really differ)
>>>>>
>>>>> > I'm mostly interested in using a multi-core Squeak with GC control
>>>>> > for
>>>>> > my robot.  Tim says a multi-core VM is coming for the new Pi.  He
>>>>> > hasn't answered on GC control.  With muliti-core a user need not see
>>>>> > GC control but the system should provide 100% GC free service even if
>>>>> > behind the scenes it momentarily toggles one GC off and lets the
>>>>> > other
>>>>> > complete.
>>>>> >
>>>>>
>>>>> Are you *sure* that's what Tim said?  I see a thread where he's talking
>>>>> about *build* performance (i.e. compiling the C code for the VM) on a
>>>>> quad-core with the caveat 'even if Squeak can't directly take
>>>>> advantage' (i.e. no multi-core VM)
>>>>>
>>>>> >
>>>>> > With real time driving, which I hope my robot will do some day,
>>>>> > getting rid of all 100ms delays is vital.
>>>>> >
>>>>>
>>>>> The trick to getting rid of long delays is more a function of
>>>>> preallocating everything you can than getting rid of GC's (I've done
>>>>> some highly interactive stuff in GC environments and preventing GC's is
>>>>> impractical except over short periods of time, minimizing their
>>>>> frequency and duration is very doable)  One of the things I think I
>>>>> recently saw that should help you in this regard is FFI memory pinning
>>>>> if you're calling out to external code.
>>>>>