CyberTech

[VisualPerception]

I am looking some good programmers to help me develop a linux based os. I am designing an android and I have come to the conclusion that the best way to operate the bot is to use a pc running a fast os. Since windows has so much overhead I need something fast and something we can go system level easily with. I am not big into os development so I will mostlikely not help with the os Dev. My offer is the people helping to become partners with CyberTech devision of Visual Perception. That means that not one person recieves money until the Android Or OS is done and the company makes money. Every time the company makes money 10% will be taken out and put in the company's account. The rest will be distributed acording to the amount of work logs submited.

Our site is underconstruction.
http://www.phatboysnare.com/VisualPerce ... index.html

To become a Partner Click Below
http://www.www.phatboysnare.com/VisualP ... /Join.html

[[AlAdDiN]]

hmm, interesting, i'll be glade to join but i dont have enought time now (exams+projects+"piece of social life ")

but IMHO : for sumthin like this a microkernel is better
...anyway if you want to build a personalised linux for this android take a look here http://www.linuxfromscratch.org/ it contains many documentation to build ur linux from scratch

[VisualPerception]

Thank you for your help. I can use all the help I can get.

[theubu]

Hello Captain Obvious,

Well it's great you're full of energy to start a project that is involved as this.... However I would recommend that you do a little more planning and designing before anyone just starts to hack away.

Since the scope of this project is so large it would be a horrible waste of time down the road to have to re-implement half the work, which was done all over again to make it all, fit together.

As far as a ?fast os,? well running equipment such as robotics would be better handled by a RTOS rather then a preemptive one.

If you get some design specs online I?m sure you might be able to get more able people to help you out or point you in the right direction.


-Christopher

[VisualPerception]

OK I have some of the vast specs to tell you. The first step is the os must be able to operate hardware through the serial ports. I have also decided for testing perpises that there should be to platforms runing the same kernal, the first being the development environment, the second be the os the Android runs on. The actual mechanics of the android will run from an air compresser and air muscles. Back to the os, the os must have imaging functionality for face recognition and sound functionality for voice and command recognition. I have given this some thought and I have com to the conclusion that maybe Me OS (menuet OS) might be a little better for this becuase it is written in assembly. Then a programmer I look up to also told me that I should start from scratch and build the whole nine-yards with my team. I don't know what the best thing to do is.

[rexlunae]

Most OSes are capable of using serial ports. Writing software to dump commands to a serial port can be done in anything, and it does not require system-level access. And as far as performance goes, serial ports are very slow, so unless you are doing a lot of really intense processing, I doubt you will need much performance. That depends on what you are trying to accomplish, but there are a lot of OSes out there to choose from, many of which perform very well, and since it is just a means to an end for you, I doubt if your project will be able to match the quality of what is freely available.

I can't really recommend anything specific, because you are not very specific about your needs, but one aspect that you might consider is the need for low power consumption, in which case you probably don't want to use a PC. Consider an embedded processor with a stock OS or with modifications appropriate to your choice of architecture.

Also, if you do choose to write an OS, I would not recommend writing it in assembly because that will probably only make it more difficult to code in exchange for only modest performance gains, and then only if you are really good at hand-optimization.

[theubu]

Hey,

Well the language used to impliment the os isn't as important as it would seem...

Most important is how well it can fit into your product model... and like I said you're probably looking for a RTOS because of your application.

Starting from scratch is always a good option how ever it's not always needed it will add years to your deployment time... Have you figured out your hardware needs as of yet?

[VisualPerception]

Okay the hardware I will need are mainly the following. I lan card for wireless networking. Then I need to run well over 48 servos. Mainly switches to let air be pushed to the muscles or air to be drawn out of the muscle. Then it will need a graphics card that can capture rca impute at real time. For two CCD Cameras. This is the main reason I have chosen to use a PC board instead of an imbedded os on the circuitry. This will also have a dual channel mic input for listening and a speaker out for speech. I don't realy care how the speech sound for know I just need the os the be developed. Ihave been doing some more reaserch and have com to the concusion that we can start from scratch using assembly and C. I have no knowledge of building an OS but with help I will learn quicly. Unlike my spelling and grammer. I am only familer with Delphi 7 For windows and I have been toled that C is much like Delphi Pascal Coding. I am sorry I changed topics. OK Other than the Servos, Mics, Speakers, Video Controls, are the Sensors that sense the grip. These are actually used in the windows OS. I would like to us windows but their is to much overhead. Please Tell me what you think.

[VisualPerception]

Okay I have an Update that you guys might want to read. I have done a little more reaserch and found some of the parts we need.
First, I stubled across A (digital gyro) A bit expinsive but all we need right now is to know how it talks to the pc. This device connects to the PC Via USB.
Second, I found a set of eyes(CCD Color Cameras). Complete with the mounts and the circuitry. Connects Via RCA. This is the reason for the capture card.
Third, I found the Touch Sensors FSR. These connenct to a splitter then to a board that connects to the perallel port.
For now these are some of the operations that the os must handle.

[theubu]

Sounds good... How ever you'll need to supply some developers with the hardware if you want any useful programming done

[Brendan]

Hi,

Okay I have an Update that you guys might want to read. I have done a little more reaserch and found some of the parts we need.
First, I stubled across A (digital gyro) A bit expinsive but all we need right now is to know how it talks to the pc. This device connects to the PC Via USB.
Second, I found a set of eyes(CCD Color Cameras). Complete with the mounts and the circuitry. Connects Via RCA. This is the reason for the capture card.
Third, I found the Touch Sensors FSR. These connenct to a splitter then to a board that connects to the perallel port.
For now these are some of the operations that the os must handle.

Sorry to sound a little negative but the internet is full of people with big dreams and no idea. Have you done a cost analysis to determine how much each android will cost to produce, and market research into how much you can sell them for if they ever actually work?

For industrial applications remote control robotics is far more practical and can be done with standard radio control gear, without any CPU within the robot.

The only other market I can thing of is kids toys. Kids generally play with a toy for around 6 months (if you're lucky) before they lose interest, so parents (the ones with the $$$) generally won't pay more than $500 US for any toy. To handle the data from a pair of CCD color camaras you'll need a decent CPU (otherwise there'd be no point having 2 CCD cameras and the video capture). Therefore your cost for the CPU alone will exceed the price you'd be able to sell it for.

Let's be optimistic and say people will pay $2000. First people sell things to make money in the form of "mark-up" so you can subtract around $200 for that. Then there's manufacturing costs at around %50 which brings you down to $900. Out of that $900 you'd need to cover the material costs and administration, transport costs, advertising/marketting, accountancy, etc. If you manage to sell thousands of them this might leave as much as $500 for materials.

So, a frame and plastic body for $45, a reasonable air compressor for $60, 8 pneumatic servos at $15 each, $25 for servos, video capture at $30, 2 CCD cameras at $20 each, various micro switches (bump sensors & limit switches) for $10 and a gyro for another $45. Then you'd need a power supply - $20 for a sealed rechargeable 20A/hr battery, $15 for the charging circuitry and regulators. That means you'll be need to be buying your CPU, memory, parrallel, serial, etc for under $90 (or much less considering the original $2000 is far too generous - you wouldn't sell thousands of them at that price so your overheads will be worse).

One practical alternative would be ditch the CCD and video capture and use a grid of photo-sensors with a low resolution (e.g. 16 * 16). This would enable you to use a cheap micro-controller - for e.g. a pair of PIC16F877 chips would be adequate and only costs about $8 US each (see http://www.futurlec.com/Microchip/PIC16F877.shtml for datasheet).

Of course if you knew enough about electronics to actually build an android you'd realise the CCD is a huge useless overkill, and if you knew enough about business you'd realise that the price of modern CPUs needs to be avoided completely (which rules Linux out).

The only question that remains, is whether I've annoyed you enough to produce a business plan detailing the actual costs (rather than my guesses), and the market research mentioned earlier. Trust me - these things a far more important than the actual design.


Cheers,

Brendan

[theubu]

Brendan,

Gosh feller blowing this poor kids pipe dream... What if he was just building a toy for himself?

Then again look at robo sapian it's $99 and it's remote controlled there is probably no cheap way to produce what he is looking to do anyways....

But what you said is true planning is needed not just for the development but the practicality of it....

[VisualPerception]

Okay you didn't do much reaserch, I can tell. I would like to know where you are getting a digital gryo for 49 dollars. Try 1,925. I don't want to sell them or produce them, Just develop the os and a prototype tester.[/quote]

[VisualPerception]

I had to leave so i cut off earlier.
OK First,

The only question that remains, is whether I've annoyed you enough to produce a business plan detailing the actual costs (rather than my guesses), and the market research mentioned earlier. Trust me - these things a far more important than the actual design.

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. Eroe Space is willing to pay 7 billion for a working androide to call their own. Then it is their own problem producing it.

[Brendan]

Hi,

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.

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