Self-training robot

self-training/self-learning, i.e. about robots with ability

to hard coded behavior. Any info about real

I am searching for this too. I think Honda is trying to add this
feature to Asimo, but I do not know about the programming details.

Joel

  You are lucky .  I am the worlds expert .
  You need to make the mcu "kernel"
 have a most efficient method , so
 first , toss English text , and allow
 this kernel to work in his own way .
   Linking means , the kernel can
 most efficiently "connect" dissimilar
 objects and code fragments .
   Especially the lowest levels , will
  be linked 100% , so if kernel
  needs to improve some of his
 low level code , he can use these
 links to "figure" what went wrong .
   The poison of this linking is
 multi-tasking by forced interupts .
    So i never use IRQ's , i write the
 code to dynamically alter the
 perceived importance of a task .
   The kernel figures how much idle
 time the highest priority can give up
 and then passes this freespace to
 only a task that can fit in that space .
   This solves problems !
   At idle time , kernel polls IRQ's and
 does so in order .
    But this is a small task , cause kernel
 knows not to poll the hardware that needs
 lots of space !  , kernel only polls s few
 that can fit in the 3 microseconds .
   Now you know why FIQ is NOT needed !
   Cut to the chase scene ,  modern Forth
 is the only simply way to program robots .

    We all want to create an algorithm to
  make the robot walk .
   Create code with a short loop .
   Just as your brain does , then
  allow a higher part of the brain
  develope a good habit  from .
   More than one balance method ,
  from stupid pendulums to rate gyros
  and magnetometers and VideoCams* .

   and a "local" mcu to over rule the
  slow methods when they cant keep up .

   The main mcu only needs to command
  and destabilize and then relax , the
  local mcu is accidently walking the
  robot , by correcting it !
    Thus it is always in a balancing act .
   If the local mcu has good enuf "inputs"
 it will be able to learn how to balance
  better and better .
   It has feedback , so it knows that the
  fall was due to its'  ignoring the faster
   input !   Because if it knew the "rate"
  better , it would have been able to
  correct faster !
   So next time you push , it uses the rate
  to make a faster correction .
    But it wont overshoot , because its
  seeing the feedback of the loop .
    The first time , it saw the feedback
  did not change fast enuf , so it crashed
    Next time it tags that slow input as being
 only useable at slow rates .
  All of this can happen without any initial
 programming !
    You can even add sensors , and it
 will characterize them and use them .

   But all is lost if you bury your self
 in the C langauge .
   You cant afford such a waste of
 time .
   Especially robot s/w , must be written
 with a track-ball mounted on the robot ,
  not a Host PC IDE !
   No need for a big color LCD ,
  a $10 128*64 BW from B.G. Micro .

  some of my high performance
 ideas , use a spinning BW , low lux
  vid cam .  It only uses alternate
 vertical scan line , maybe every
 6th or 8th line .
  Each line gets a ARM9 mcu .
    It works like a insect eye , each
 line has a clock , so when that line
  sees a fast contrast change , its
  mcu can 'match" this change to
  its map , and send a fast signal
  to the main mcu , that position
  has changed 1 degree west .
    This is in the fast mode , when
  stuff is goin slow , the whole vid cam
  can be used to walk in the dark , using
  a few I.R. LEDS ( VidCam = .01 LUX)
    Trying to make ur own insect eye
  is actually harder than using a few lines
  from a $20 BW VidCam .



.