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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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) <[email protected]> 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. >>>>> _______________________________________________ Beginners mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/beginners
