[Coco] COCO Robot update.

[haywire666 at aol.com]

Thanks for the thoughts guys. My thoughts were that If some animated things (Like blinking eyes) could be taken away from the main processor (The coco) and operate independently when the 
robot was turned on that would be fine. I have a small led eq bar that operates on its own, going up and down with the voice. I don't even know how to do that with a micro controller or with the coco.


The led eyes will be done with this little off the shelf component I found. It comes with a circuit to vary the blink rate and the leds, it costs 14$ including shipping. To me, its not worth trying to reinvent the wheel if there is something off the shelf I can just mount. Of course, this may not look right to me, we'll see when it gets here. If it dosn't look right I want to use the relay on the coco.


Besides the color computer as the main "brain" The robot WILL have a couple of micro controllers, as I have two basic stamp homework boards here someone gave me. I also have an arduino board I bought but never used. I believe distributed processing is the best thing for robots. In a robot, there is virtually unlimited amounts of sensors and things. I built a pc based mobile robot some time ago, but I found it nearly impossible to get enough i/o lines to handle all the additions, sensors, flashing lights, and doo dads I would keep adding. Besides this, its difficult to manage one cpu doing everything.


if some sensors could be managed by the microcontroller and just report things to the main cpu, I think the robot would be much smarter and more hmmm... capable?  
Also,If I use micro controllers along with the color computer, I can also do things the coco can't do (or would take too much cpu time) like speech recognition.


Like I said, when I make more progress I'll post some pictures. Right now the head is not attached, the mobile base still needs work and the frame is done, but still mounthing stuff.


Still,my frankencoco robot is slowly taking shape. Thanks for everyone's help!

Steven



-----Original Message-----
From: Frank Pittel <fwp at deepthought.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sun, Apr 8, 2012 10:43 am
Subject: Re: [Coco] COCO Robot update.



Once upon a time the cost (in term of complexity, time, etc) was high
enough that it was important to keep the count down. This was back in
the day when the "support" chips cost more then the processor. Having
a microcontroller that eliminates the address decoding and manipulations
with the control lines/buss and chips that go along with that was made it
fast and cheap to have multiple micros.

My introduction with microcontrollers started with the 68hc11 and while an
improvement in the microprocessors but clearly a long way from current 
offerings.
By removing all or most support hardware the price has gotten to the point of it
being faster, easier and cheaper to use multiple smaller micros instead of 
trying
to get all of the software into one!

The Other Frank


On Sun, Apr 08, 2012 at 12:00:44AM -0700, Steve Bjork wrote:
> I find it interesting that the idea of using distributed processing
> was against the grain.  After all, modern object-oriented
> programming is distributed processing of a program.  Be it hardware
> or software, I find that breaking down the job into small and easy
> to manage tasks makes for easy to design and build systems.  (and a
> lot less errors in the final product.)
> 
> All of may Z-80 and 6809 games used object-oriented programming.
> Since the name "object-oriented" had NOT yet to be coined, I called
> it D.C.B for Data Control Block coding.  But this style of coding
> was the natural direction programmers were taking the art.
> 
> In my Halloween display that I do every year, the whole system is
> based on simple modules that preform their task independently.
> There are signal lines that tell some props to fire while keeping
> other props quiet.  (just like the singals you send to a code
> object.)  One of the key signal is the "QUIET" line that keeps other
> props from firing when a prop has pulls it low to do its show.  When
> the line returns to the high state, another prop can grab it to do
> its show.  To keep props from colliding,  each device has a priority
> number start with 1 to 10.  (It waits that number of seconds before
> trying to grabbing the control line.)
> 
> The great benefit to this system is no Master Control Program to
> waste time on.  (Or take over the world of TRON)
> 
> On a picaxe side-note, the new 18m2+ chip can run 8 tasks at the
> same time.  The older 18m2 could only run 4 tasks at once.  All in
> BASIC to boot!
> 
> Steve
> 
> 
> 
> On 4/7/2012 10:25 PM, Frank Pittel wrote:
> >Steve,
> >
> >My understanding was that the robot control was to be built "in parts"
> >and that the OP was looking for a way to "blink" leds at random rates.
> >While that can be done with "discrete" electronics I've come to the 
conclusion
> >that these types of things are better done with microcontrollers (not 
microprocessors),
> >pics, etc. Let's face it $3 for an 8pin DIP microcontroller is going to be 
able
> >to do a lot more then $3 in 555 timers, resistors, caps, etc!
> >
> >While the larger PICs are capable of doing a lot on there own they are by 
definition
> >intended to work under the control of a more capable processor. When I first 
started
> >working with them a year or so ago that fact went against the grain for me. I 
kept trying
> >to do everything with a single controller. Then it dawned on me that I'm 
better off using
> >2,3 chips of lower capability under the control of something more powerful 
then trying to
> >do it all from one very powerful chip.
> >
> >Currently I'm working with the parallax "propeller" (an 8 "core" controller) 
and their discontinued
> >"SX" pics. Both can be programmed in Basic as well as assembly. The propeller 
can also be programmed
> >in forth and C!! As soon as I'm done with my current project I'm going to 
look into the picax. I think
> >it can be used for a number projects I have in mind. Unfortunately none 
involve the coco. :-(
> >
> >The Other Frank
> >
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco