OSDev.org

That sounds exilent. I hav found some motors that have a 298:1 ratio and I have decided to use them insted of the air muscle, for one the air muscle design is to bulcy. Touch Sensors FSR, This is what we will be using and then I found a controller for it that connects via Perallel port. Knowing the hardware is nice and all but my enitial Idea was. Build and operating system x86 - Intell compadible, and allow it to use Files Like DLL's so that we can upgrade the os. I would like for the os and the operation software to be seperate from one another. I prefer to code in pascal for the software above the os but that is for later in the game. I love the Idea of using the ethernet Mini PC's, and CCD connectors.

So, If we wrote our own os this would make the developement time triple, but the os would be more efficiont. (Sorrory I can't spell for beans.) If we use a linux based OS and modify it then we would have the OS semi out of the way. and totaly scratch the Menuet OS idea I had. I would rather use Linux, for one I am not an OS developer, I write software and I am into a little bit of animation and siloweting object recognition reaserch.

This leaves me with one more thing, How will we connect over 120 motors to a serial port. Oh, the power source, I had a 12 Dry cell Laptop Battery in mind for testing.

Hi,

VisualPerception wrote:That sounds exilent. I hav found some motors that have a 298:1 ratio and I have decided to use them insted of the air muscle, for one the air muscle design is to bulcy.

I'd assume you'd need a wide variety of different stepper motors - a motor used for turning the head may be far smaller than the motors in the back used for lifting heavy objects..

VisualPerception wrote:Touch Sensors FSR, This is what we will be using and then I found a controller for it that connects via Perallel port. Knowing the hardware is nice and all but my enitial Idea was. Build and operating system x86 - Intell compadible, and allow it to use Files Like DLL's so that we can upgrade the os. I would like for the os and the operation software to be seperate from one another. I prefer to code in pascal for the software above the os but that is for later in the game. I love the Idea of using the ethernet Mini PC's, and CCD connectors.

So, If we wrote our own os this would make the developement time triple, but the os would be more efficiont. (Sorrory I can't spell for beans.) If we use a linux based OS and modify it then we would have the OS semi out of the way. and totaly scratch the Menuet OS idea I had. I would rather use Linux, for one I am not an OS developer, I write software and I am into a little bit of animation and siloweting object recognition reaserch.

This leaves me with one more thing, How will we connect over 120 motors to a serial port. Oh, the power source, I had a 12 Dry cell Laptop Battery in mind for testing.

Those microcontrollers I mentioned have an ethernet port (to connect to the main CPU), 3 parallel ports and 4 serial ports each. The stepper motor controllers handle a pair of motors for each parallel port, so you could use 20 microcontrollers (with a heap of serial ports left over for interconnecting them and other I/O).

The best way to approach any large project is to split it into manageable chunks:

Hardware design - the mechanical side of things. This can wait until the software works.

Hardware design - the electrical side of things (power supply regulation, recharging, motors & controllers, touch sensors, the micro-controllers, etc). In early stages all of this should be simulated by software running on a PC, so all this can wait.

Hardware simulator - simulating the above. This would be software that simulates the behaviour of micro-controllers and shows what is happening where - a little stick man drawing that shows where joints have moved according to what is happening for example. This can be written in any language on any OS - Pascal on Windows will be fine. It will become a useful tool for perfecting the interface to the main CPU and for designing the software in each micro-controller. Because just about everything is connected via. ethernet, in later stages you'd be able to plug the androids real main CPU into the network (a real brain with a simulated body).

Main Software - the software that would run on the main CPU. This wouldn't include the android's OS, but does include the communication to the micro-controllers and CCD cameras, code to translate the CCD images into usable data. You can use any language on any OS for this, as all OS's generally support TCP/IP the same. Pascal on Windows will be fine - although I'd be tempted to use GNU Pascal as it'll be easier to port the software to the real main CPU later. Again, because ethernet is used you can plug real CCD cameras in and the hardware simulator (from above) and talk to it all using TCP/IP. You could also plug the real android's body into a normal PC later on.

Main CPU hardware - this is the CPU, ethernet card/s, sound card, chipset, memory, circuit board, etc for the main "brain".

The OS for the main CPU. This isn't going to matter (most OS's could do). You can rule out Microsoft (licencing costs). I think (based on my own experiments rather than looking at the code) Menuet uses an old fashioned round robin scheduler that makes it completely in-appropriate. Linux contains a large number of things - removing everything you don't need might take ages, but there's a larger number of people familiar with it's internals than any other OS. I'd probably keep an eye on decent OS projects and start with something that's close to what you need and modify it to suit (paying close attention to licensing details). I'd be looking for something with a prioritized scheduler (not necessarily real time because those micro-controllers remove the need), that already has support for ethernet, TCP/IP, and something that would be easy to port your software to (anything that does or could use the GCC tool chain).

The micro-controller software. Software for each micro-controller is going to depend on what that micro-controller is used for. Micro-controllers are generally easy to program though, and you can use the hardware simulator (from above) as a design model. I wouldn't worry about this until the Hardware simulator and Main Software are working with each other well (e.g. the main software is capable of making the simulated android walk around and avoid crashing into objects or falling over).

Out of this I'd probably do them in the following order:
Hardware simulator
Main software
Hardware design/electrical
Micro-controller software
Hardware design/mechanical
Main CPU hardware
Android OS

The OS is last because it's the least important and you can make sure everything works correctly without it.


Cheers,

Brendan

If we do stuff in that order we will then need to rewrite the software to operate the hardware.
Why?

Hi,

VisualPerception wrote:If we do stuff in that order we will then need to rewrite the software to operate the hardware.
Why?

You shouldn't need to rewrite anything (unless you're thinking of writing the software in assembly language - not recommended anyway). You might want to check if there's a library for the language and OS you end up using though (or select an OS later on that does have a library).

Generally the software only needs to use memory allocation & de-allocation, sound, and TCP/IP stacks. Therefore even if the selected OS doesn't have a library you'd only need to add a little bit of "glue" code for accessing the OS's memory management, sound, and TCP. You might need to fiddle with linker scripts and things too, but if you add it all up it's all negligable (or it'd add roughly 0.0001% to the overall time the project will take, and probably save you much more time as it'd be easier to make sure everything works as planned).

For example, if you used ANSI C you'd be able to compile and run it on any computer running any OS. I assume standard Pascal is standard too, which is why I recommended GNU Pascal rather than (AFAIK) windows specific Delphi.

In addition, once you've written the hardware emulation software and the software for the "main brain" you'd be able to demonstrate exactly how everything works. This is great for getting people to volunteer their time (and organising things - "make it work like the emulator"), but it could also be used to impress investors so you can get money before most of the project is done, and possibly hire programmers, etc.

To be honest you should also look into non-disclosure agreements too - otherwise I'll help until the project is almost complete and then sell it (or something very similar) myself and keep all of the money (an example only). You wouldn't want to spend 10 years developing the android and end up with nothing would you?


Cheers,

Brendan

That sounds like a very good plan. Another thing this android must have is the capability of face and object recognition. I want to build the software before even starting the andriod biulding. Just thought I would say that for anyone just coming in. But I love using pascal for coding so if you know of a GNU Pascal IDE for free could you please let me Know. Hey Brendan could you E-mail me so that I could have your E-mail address and you don't have to give it out on the net. My E-mail address that I use for Display as adestraction is (hhb@netxn.com) I will check it to see if you E-mail me. I would love to have you on the Dev Team Once we get started. If you are running A windows machine I am developing some software to manage the files checked out to each Developer so that things do not get overwritten. If you think that it is a good Idea please let me know. My Web Site should be up within a couple of days so if you will please Visit

http://www.duvallclan.com/CyberTech/Main.html

P.S. I very much appreciate that not one person has cussed.

Brendan wrote: 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.

Simplify, simplify. Punt the ethernet and networking protocols stack. Forget the sound. Eliminate the PCI.

Use simple, basic serial communications.

The main CPU can communicate with the peripheral controllers through simple, testable, serial I/O. The main CPU would see a couple of memory-mapped registers where it can read and write data (although the API would use something a little more sophisticated). Since the android should run standalone (a robot does not have a tether, that would be a remote control drone), you don't need a networked connection to the outside world. You just need a simple 3-wrire serial connection to download instructions.

The advantage of using the simplest communications mech possible is to make testing and verification (and troubleshooting) easier. You can intercept and analyse each and every byte passed between CPUs. There is less to program, less to go wrong.

It's easier to write emulators for simple byte-oriented data transfers than for TCP/IP communications.

Fewer parts are required, power consumption is less, fewer layers of software means development time is reduced.

Smaller, faster, cheaper, easier. Why would you choose another way?

Hi,

bregma wrote:

Brendan wrote: 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.

Simplify, simplify. Punt the ethernet and networking protocols stack. Forget the sound. Eliminate the PCI.

Use simple, basic serial communications.

Simplify is what I did. Serial communications will not handle the data from a pair of CCD cameras, and the sound card (and speech) was one of the requirements. Further, the serial ports on a modern (Pentium or above) chipset are connected to the LPC bridge via. a PCI host bridge, so you must have some PCI anyway. Of course you could make your own "host to heaps of serial ports" bridge, which would need to be fast enough to handle the CPU's bus speed (100 MHz or above), as well as handling all the CPU's other requirements (memory, IRQs, etc).

bregma wrote:The main CPU can communicate with the peripheral controllers through simple, testable, serial I/O. The main CPU would see a couple of memory-mapped registers where it can read and write data (although the API would use something a little more sophisticated). Since the android should run standalone (a robot does not have a tether, that would be a remote control drone), you don't need a networked connection to the outside world. You just need a simple 3-wrire serial connection to download instructions.

With wireless ethernet you could have a "remote control utility" and put the android into manual mode. This utility could show the user live video data (in 3D if you've got a headset) while the user controls the android. This would allow the android to be used for specific purposes where humans don't want to go - bomb diffusing, nuclear reactor repair, terrorist negotiation, hazardous environments (hot, freezing, gas).

bregma wrote:The advantage of using the simplest communications mech possible is to make testing and verification (and troubleshooting) easier. You can intercept and analyse each and every byte passed between CPUs. There is less to program, less to go wrong.

It's easier to write emulators for simple byte-oriented data transfers than for TCP/IP communications.

Fewer parts are required, power consumption is less, fewer layers of software means development time is reduced.

This can all be done with TCP/IP with standard packet sniffers or custom written software. You can use TCP/IP for byte-oriented data transfers too (telnet already does) where suitable.

In general the android would need to stay within the design requirements. Simplifying is good, but you can over-simplify. For e.g. you could simplify the design of a car and end up with a bicycle - the bicycle is cheaper, lighter, more efficient and would take far less resources to design & produce (but you can't tow a boat with it, and it becomes a fire hazard when you try to put the petrol in .


Cheers,

Brendan

Very well said Brendan. Another thing is we have decided to use a linux kernal and it already has the TCP/IP connectivity and functionality. Of course we will not need gnome or kde runing until the Andriod is booted in user interface mode. I believe linux would do fine. as for the sound and ethernet connection, we must have them. I just don't know how to program that well. I am a systems anylisys database designer programmer. I know very little about os programming. I must run for know I will continue later.

Okay to continue I have selected Tiny linux, which I have just became the project manager for. This project hopefuly has all the os components needed. I am going to start on the optical software and then post about it and how it is going. Sorry about the downed web site and I am trying to fix it. It my take a bit I am using php and I only know how to use VB and Delphi.