Hi,
VisualPerception wrote:A bussines plan is no good unless you know exactly what you will be doing and know what you need. I have stated earlier to that the first enitial priority of this plan is to develope the technology in the os.
An OS is no good unless you know exactly what it will be doing and know what it needs.
I apologize for assuming the android would be intended for the general market, yet after re-reading the messages in this forum I've not been able to find anything to indicate exactly what the android would be used for, nor the general functionality it should have.
VisualPerception wrote:Eroe Space is willing to pay 7 billion for a working androide to call their own. Then it is their own problem producing it.
That is at least an indication of required functionality, albeit subtle. Other indications from earlier messages include a pair of colour CCD cameras, a pair of video capture cards, a digital gyro, a USB controller, some touch sensors (possibly all for sensing grip?) that connect via something(?) to a parallel port, serial ports used to talk to something(?), and an air compressor running "air muscles" (pnuematic rams?), a LAN card for wireless networking, over 48 servos to control the compressed air and a speaker for speech (and a sound card I presume).
I'll assume that 48 servos (and the gyro) implies you want a biped (2 legs rather than wheels or tracks), and that a pair of CCD cameras are for depth perception. Serial ports controlling something and servos being controlled by something - I guess I can assume the servos are controlled by the serial ports.
From here I can deduce the computer's architecture (using standard componets) may look something like:
Code: Select all
CPU
|_Memory
|_PCI host bridge
|_wireless ethernet card
|_sound card -> speaker
|_video capture card 0 <- CCD0
|_video capture card 1 <- CCD1
|_USB controller <- digital gyro
|_PCI to LPC bridge
|_serial port -> servos
|_serial port -> servos
|_parallel port -> touch sensors
Ok, that's 6 different types of communications devices. Would it be possible to reduce this? USB is a pain to program and it's only used by the digital gyro. Honeywell Aerospace Electronic Systems do a digital gyro that will connect to a standard RS-232 serial port (see
http://content.honeywell.com/dses/produ ... 20an01.htm).
Now, about those video capture cards and CCD cameras. How about just using ethernet instead of RCA? You'd get a better quality picture and wouldn't have to bother with software to control the video capture card. They're common as mud, so why not (see
http://vepp4-pult1.inp.nsk.su/~vepp4/CCDD/e-index.html). This would involve using a small ethernet switch, but that's negligable.
You've not mentioned any form of power source, so I'm going to assume rechargeable sealed lead-acid batteries (makes the most sense to me). Using electricity to compress air and then using compressed air to create mechanical movement isn't too efficient, and the computer will have no way of knowing the position each "muscle" is in. How about we scrap the idea and use stepper motors instead? It'd be quieter, lighter, more efficient and much easier to get accurate positioning. There's a few commercial kits around for this (e.g.
http://www.robotics.com/md2.html) but it'll depend on the actual requirements for each motor. The good thing is that they can all be controlled by parallel ports..
So that lot leaves us with something like:
Code: Select all
CPU
|_Memory
|_PCI host bridge
|_ethernet card <-> ethernet switch <-> wireless ethernet, CCD0, CCD1
|_sound card -> speaker
|_PCI to LPC bridge
|_parallel port -> touch sensors
|_parallel ports -> stepper motor controllers
How about if we used a collection of small microcontrollers between the main CPU and the stepper motor controllers and touch sensors? The main CPU would be able to tell the microcontrollers what it wanted (e.g. what position to move to, or how much pressure to apply) and the microcontrollers would handle the details. For example, you could have a microcontroller built into each hand that controls grip motors and the touch sensors with built in intelligent control provided by it's microcontroller. These microcontrollers could also be connected to each other via. serial connections where desired, such that an elbow controller and wrist controller can be designed to ensure that the hand is kept level without any control from the main CPU. Imagine this android standing in a strong wind without being blown over and without the main CPU being used.. There's several microcontrollers that have built in ethernet interfaces (e.g.
http://www.rabbitsemiconductor.com/prod ... ndex.shtml) that make this easy enough to do (and simplifies a lot for the main CPU & architecture).
This leaves us with:
Code: Select all
CPU
|_Memory
|_PCI host bridge
|_ethernet card <-> ethernet switch <-> wireless, CCD0, CCD1, microcontrollers
|_sound card -> speaker
Now almost all of the software for this can be written in any language on top of any OS. You could use several computers on a LAN where one runs the main controller software and a few others simulate the behaviour of all the motors, touch sensors, etc with the whole thing tied together will TCP/IP.
I realise it's probably not exactly what you're after - it's just a demonstration of how a decent hardware description dramatically influences the software required.
So my next question for you is, can you provide any sensible description of the hardware you're actually planning on using?
Cheers,
Brendan
")