What is the Purpouse of Usin Micro Contoller in Autonomous Robots?

To contol the robot.

How do you think they get to be autonomous?

Perhaps this will make more sense. Ask, what is the purpose of the brain in a human?

How would you do it?

The real purpose of a micro-controller in an autonomous robot is to baffle a novice what the robot can and will do. If this is a homework question, we don't do students homework here. If this is not a homework question, your question appears to be so naive that I doubt you'll recognize the difference between a good and a bad answer here.

Autonomousnos...

SWARM ROBOTS...

I loved all the answers Guys, I feel you held yourselves back very well, congratulations.

I don't know personally what "deps" means, but in German (we are multi-language here), you don't want to be called a "Depp", which I am sure sounds similar, its not nice as "Depps" are known for asking stupid questions!!!!

Here is the dictionary page I was looking at:-

http://www.dict.cc/?s=Depp

See what I mean?

I think a rapid name change could/should be in order and fully acceptable to all on CR4.....

Ouch!

We use them to keep humans from making stupid mistakes.

Fun answers, all. But I'm going to go out on a limb, and make an assumption, that the OP is asking why a MicroController, vice a more conventional MicroComputer. Note that my assumption is based on a MicroController being recognized as a device optimized with more I/O CONTROL capability, as opposed to the MicroProcessor, optimized for more Data I/O throughput. Both may have a fairly prodigious computing capability, but one is more built to collect and cogitate, while the other, the MicroController, is more designed to collect and preform actions upon, data.

If that is true, my answer would be "to implement the primary program control loops in sensors, with the resulting data being parsed, and reacted to, as a secondary function" (such that the robot, when it's UltraSonic sensor detects a void in front, doesn't need to cogitate about what to do, since it's hard-wired response is to back away, turn, and try another route) as opposed to a more software intensive "look ahead, map obstacles, determine a path, recheck for clearance, THEN move forward". One requires a lot more processing power BEFORE commitment to a motion, while the other is designed in hardware to be more reactive, and expects that movement will uncover obstacles, which can be reacted to AFTER motion has already started.

In a complex environment with many moving obstacles (Urban Robotic Vehicle tests), only the more processor intensive "calculation before movement" paradigm is survivable. But in a "Follow the troopers wherever they go carrying their equipment, assuming they won't go where I can't go, and I'm tough enough to handle getting shot trying, and failing the first try, to follow, if they forget, or are forced into very bad terrain" scenario, less processing might be required, except that needed for things like balance recovery, directional navigation, Identification of Friend or Foe (IFF) and such like. And in a sufficiently complicated application, perhaps BOTH could be employed, to allow for the more mundane, day to day, "go here, but don't fall down there routines" to be implemented in a microcontroller, and the more sophisticated survival routines implemented in a microprocessor, which might have an override capability to stop the microcontroller loops in time to implement or redirect a change in program response.

This sort of Hierarchical Programming, with priority interrupt loops has been used for this early robotics experiments, and probably is today, though I don't have any specific examples.