Searching \ for '[PIC]: Genetic Programming' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Genetic Programming'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Genetic Programming'
2001\10\16@202827 by mail

flavicon
face
Hi,

I'm new to PICs. What I'm wondering is.

Can one PIC clone itself into another PIC?

Specifically, what I'd like to accomplish (some day) is genetic
programming (GP) implemented on a PIC, such that
- some learned behavior is stored
- this behavior somehow 'maps' to program snippets
- the program snippets and the main program are somehow integrated (I'll
worry about the details ;)and burned into the other PIC
- learning resumes on the other PIC and the process will repeat

I have experience with genetic algorithms, and I see essentially no
problems with a straightforward implementation of a GA on a PIC (apart
from memory limitations).

This is different from GP where the result is a new program rather than
new parameters.
I'm just curious whether what I described above has been attempted or
whether there are reasons why it could not work.

Peter Bruinsma

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\16@205427 by Philip Galanter

flavicon
face
Hi Peter, you might have the germ of an idea here as a metaphor, but
as a literal engineering thing I don't quite get it.  I do know quite a
bit about GP and the like so ...

At 2:19 AM +0200 10/17/01, Peter Bruinsma wrote:

>Specifically, what I'd like to accomplish (some day) is genetic
>programming (GP) implemented on a PIC, such that
>- some learned behavior is stored

data in memory

>- this behavior somehow 'maps' to program snippets

data can be code

>- the program snippets and the main program are somehow integrated (I'll
>worry about the details ;)and burned into the other PIC

memory contents can be transferred

>- learning resumes on the other PIC and the process will repeat

same machine, same data, same program = same behavior


>I have experience with genetic algorithms, and I see essentially no
>problems with a straightforward implementation of a GA on a PIC (apart
>from memory limitations).

yep

>This is different from GP where the result is a new program rather than
>new parameters.
>I'm just curious whether what I described above has been attempted or
>whether there are reasons why it could not work.

seems like it should work, but simply in the sense it already works in a
single CPU, or a single CPU emulating multiple CPU's...etc...

I feel like I am missing something in your question!  But I am really
interested in this kind of thing ...

Philip

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\10\16@211252 by mail

flavicon
face
Thanks Philip!

The reason I mentioned two PICs is because I made the (apparently wrong)
assumption that a PIC cannot overwrite it's own code sections. I just
learned that the 16F87x and can accomplish this with use of a
bootloader.

So, I think my question is already answered: it should work.

Time to go to bed in Stockholm...
Peter.



> {Original Message removed}

2001\10\17@042913 by Roman Black

flavicon
face
Peter Bruinsma wrote:
>
> Hi,
>
> I'm new to PICs. What I'm wondering is.
>
> Can one PIC clone itself into another PIC?
>
> Specifically, what I'd like to accomplish (some day) is genetic
> programming (GP) implemented on a PIC, such that
> - some learned behavior is stored
> - this behavior somehow 'maps' to program snippets
> - the program snippets and the main program are somehow integrated (I'll
> worry about the details ;)and burned into the other PIC
> - learning resumes on the other PIC and the process will repeat
       <snip>

I think this is a great idea! Very exciting.
Here's some suggestions:
* Use a big PIC like 16F877 etc
* keep main "brain" in lower half of the code
memory, and use it almost like an interpreter, so
the actual personality "values" of the robot are
stored in top memory.
* the personality values can be constantly adjusted
by the bot itself so it can "learn" stuff.
* have a few bots competing for "food" from stationary
chargers etc.
* make each bot "grade" it's own performance, then
if it meets a bot that is stupider, it can be dominant
and download it's entire personality variables into
the dumber bot, or the areas of its personality
that are superior.
* if you split the personality stuff into areas, like
       * locating food sources
       * navigating obstacles
       * energy conservation
       * jostling other bots for food
       * avoiding danger
etc, the bots can become proficient at different
tasks and then train each other in their personal
specialty.

I think this is very exciting and although would take
a bit of work initially its not really that hard.
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@060527 by mail

flavicon
face
Roman Black wrote:

{Quote hidden}

Of course at this point there would be serious risk of one bot
downloading malicious code into another bot. Now suddenly the bots would
require an immune system.
It would turn into core wars!

I was thinking along the line of legged robots who are learning how to
walk from scratch, e.g. they have all the necessary hardware but they
need to 'come up' with the software.
Fitness is measured by the amount of movement over time, stability, and
smoothness of movement. Feeback from a couple of accellerometers in the
head and either GPS or a local 3D tracking system would be required.

(I have a theory about walking that I would like to test, namely that an
organism that can walk has learned how to move around while using the
least amount of energy, a simple fitness test!)

Peter.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@073026 by James Caska

picon face
Peter Bruinsma wrote,

>I was thinking along the line of legged robots who are learning how to
>walk from scratch, e.g. they have all the necessary hardware but they
>need to 'come up' with the software.

In my experience GE and GP only really work when you have huge populations
(hundreds of thousands) over large numbers of generations (hundreds). It may
prove impractical for a couple of dozon physical real robots to learn how to
walk. Simulated robots using simulated PIC's on the other hand... You could
build a simulated Robot, plug it into Virtual Breadboard with a PIC16F877
simulated controller and let your bots make whoopie :-)

Hey now this becoming fun. While I am at it I could make an internet plugin
extension to virtual breadboard to allow interested members to host their
own pet robots as part of the "collective" (any trekies out there) so that
potentially several thousand simulated robots could be going at it like
rabbits at any one time.

And as it so happens..(no co-incidence really) I am just about to release
the new version of Virtual Breadboard with an extensibily component and a
PIC16F877 so I am motivated to contribute to something like this to increase
interest in Virtual Breadboard. Once it learns to walk the real thing could
be built to see how it goes. Funny thing is that I actually did my
university thesis on this exact thing 10 years ago. I build a GE that
learn't how to program a fuzzy logic controller to control a PIXAR Luxo lamp
simulation for "smooth and optimal motion" and also how to drive a car
around a track. Might have to drag the old code out...

Who knows.. it might actually walk!!

Regards,
James Caska
http://www.virtualbreadboard.com
caskaspamKILLspamvirtualbreadboard.com
ujVM - 'The worlds smallest java virtual machine'

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@082632 by mail

flavicon
face
James Caska wrote:

> In my experience GE and GP only really work when you have
> huge populations (hundreds of thousands) over large numbers
> of generations (hundreds). It may prove impractical for a
> couple of dozon physical real robots to learn how to walk.
> Simulated robots using simulated PIC's on the other hand...
> You could build a simulated Robot, plug it into Virtual
> Breadboard with a PIC16F877 simulated controller and let your
> bots make whoopie :-)

I have had good results with GAs and populations of 100 with only a
moderate number of generations (<50).
I don't know about GP though.
As far as simulation goes...it seems that it would be difficult to
simulate the real world part (the physics of motion) that is needed for
feedback.

> Hey now this becoming fun. While I am at it I could make an
> internet plugin extension to virtual breadboard to allow
> interested members to host their own pet robots as part of
> the "collective" (any trekies out there) so that potentially
> several thousand simulated robots could be going at it like
> rabbits at any one time.

Definitely, the robots do not have to be in the same room :-)
They would have to be build on the same architecture though, I suppose.
If this is put into a kit form, I don't see why there couldn't be
thousands of these robots!

> And as it so happens..(no co-incidence really) I am just
> about to release the new version of Virtual Breadboard with
> an extensibily component and a PIC16F877 so I am motivated to
> contribute to something like this to increase interest in
> Virtual Breadboard. Once it learns to walk the real thing
> could be built to see how it goes.

I think there is real potential for something new here.
I can't recall seeing any collective robot learning projects yet.

Peter.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@090857 by 742-9014

face picon face
> The reason I mentioned two PICs is because I made the (apparently wrong)
> assumption that a PIC cannot overwrite it's own code sections. I just
> learned that the 16F87x and can accomplish this with use of a
> bootloader.
>
> So, I think my question is already answered: it should work.

Maybe.  Keep in mind that the program memory is only rated for 1000 writes.
This is meant for firmware upgrade, not code that regularly rewrites itself.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@125806 by Philip Galanter

flavicon
face
At 2:27 PM +0200 10/17/01, Peter Bruinsma wrote:
>I have had good results with GAs and populations of 100 with only a
>moderate number of generations (<50).
>I don't know about GP though.
>As far as simulation goes...it seems that it would be difficult to
>simulate the real world part (the physics of motion) that is needed for
>feedback.

Karl Sims has done exactly that.  Cool stuff...

http://www.genarts.com/karl/evolved-virtual-creatures.html


Philip

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@133549 by mail

flavicon
face
Philip Galanter wrote:
>
>
> At 2:27 PM +0200 10/17/01, Peter Bruinsma wrote:
> >I have had good results with GAs and populations of 100 with only a
> >moderate number of generations (<50). I don't know about GP though.
> >As far as simulation goes...it seems that it would be difficult to
> >simulate the real world part (the physics of motion) that is
> needed for
> >feedback.
>
> Karl Sims has done exactly that.  Cool stuff...
> http://www.genarts.com/karl/evolved-virtual-creatures.html


Yes, I have seen these. Very impressive. Others have done similar things
with virtual fish.

I see no reason why this couldn't be done with *real* robots.
Although, one problem could be, as Olin Lathrop just mentioned, that
program memory of a PIC is limited to only 1000 writes. However, data
memory is limited to 1 or 10 Million writes if I remember correctly...
This would change the exercise from GP to GA, which is fine of course!

In fact, that would simplify things considerably. There would be less
risk of the program breaking, since the program will not need to change
in the case of GA.

Peter.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\17@170800 by Peter L. Peres

picon face
I think that your approach will work, but I think that it would be best to
use two PICSIMMs or something like that since they can read their own
program (bytecode) I think. I once made a clock that would learn how much
it deviated by being attached to an accurate clock (that made square waves
at 1Hz), and then write a fudge factor into its own EEPROM.  Then it could
write this data to another clock of the same kind using TTL RS232 at 1200
Bauds. It used a 16F84. It was supposed to be ported to 16C672 but then it
was dropped. This is not GP but you get the idea.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\10\18@052854 by mail

flavicon
face
In the mean time, I have found out that others have attempted GP in
silicon with the goal to configure or co-evolve harware controllers for
robots. Both use FPGAs, probably more suited to this task.

www.cs.indiana.edu/l/www/robotics/FPGA97/Main.html
http://www.genobyte.com/robokoneko.html Robokoneko is evolved in a
software simulation first to overcome problems in hardware simulation
(such as human intervention).
There are undoubtedly been more projects like this.

However, I still think it would be interesting to attempt evolutionary
computation on a PIC. Rather than self-modifying code, it may be
sufficient to evolve a set of parameters in data memory. (I do want to
play around with FPGAs eventually though!)

Using two PICs can still be advantageous, even if it were only to have
some kind of co-processor. I'll know it when I need it :)

Peter (who just got his first PICs in the mail 15 minutes ago!)


> {Original Message removed}

2001\10\18@103357 by Michael Vinson

picon face
Just to add my 2 cents:

Peter Bruinsma wrote:
[about using data rather than program memory. Note, for those who
 have not been following this discussion, GP is genetic programming,
 in which the code itself "evolves", and GA refers to genetic
 algorithms, in which the code stays fixed but the parameters that
 control it are allowed to change. --MV]

>This would change the exercise from GP to GA, which is fine of course!
>
>In fact, that would simplify things considerably. There would be less
>risk of the program breaking, since the program will not need to change
>in the case of GA.

I think GA is definitely the way to go for your proposed project. GP
requires a LOT of code space, and plenty of room (both in space and
time) for deleterious mutations. With GP, almost any mutation will
result in non-working code, and that is why you need megabytes of
program space and millions of individuals evolving over thousands
of generations. If you think about the biological context, most of
our DNA, and there is a lot of it, is "junk". Things are much easier
to control with GA.

Michael

Thank you for reading my little posting.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\10\18@131229 by mail

flavicon
face
Michael Vinson wrote:
>
> I think GA is definitely the way to go for your proposed
> project. GP requires a LOT of code space, and plenty of room
> (both in space and
> time) for deleterious mutations. With GP, almost any mutation
> will result in non-working code, and that is why you need
> megabytes of program space and millions of individuals
> evolving over thousands of generations.

I am now convinced that GA is the way to go (on PICs).

It will make co-evolution much simpler. The code base can be the same on
every co-evolving entity (robot or system). Only parameters need to be
exchanged (via IR, RF, Internet, etc).

Given a good framework, GA can be accessible to everyone and useful
things can be created on relatively short term compared to GP.

>
> Thank you for reading my little posting.
>
'welcome!

Peter.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...