Microcontroller selection

[ilovetabasco]

With regard to my robot tank project, I am currently seeking a microcontroller that will give me enough power for my current project (and possibly future projects).

My current requirements:
Control of:
6 servos
2 steppers
2 H-bridge style motor controllers
2 TTL level digital outputs (for fire control)

Input from:
3 gyroscopes (http://www.analog.com/en/prod/0%2C2877%2CADXRS300%2C00.html)
3 accelerometers (I think) (http://www.analog.com/en/subCat/0,2879,764%255F800%255F0%255F%255F0%255F,00.html)
2 incremental encoders (low resolution)
1 absolute encoder (high resolution, >=10 bit)
2 battery monitor circuits

Processing of:
Current absolute position of all servos and steppers
velocity from the 2 incremental encoders
Digitizing/integrating input from the MEMS sensors to create current absolute roll, pitch, and yaw
PWM generation for the two motor controllers (based on the input of velocity, will eventually be closed loop)
Answering all requests from a connected computer for current parameters (such as roll, pitch yaw, velocity, absolute encoder, etc)

So, a came across this little guy: the ATmega2560 (http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega2560)

It seemed attractive to me for its numerous ADC and DIO connections, abundant program memory, 32 GP registers, sleep modes, a fast clock (if necessary) and lots of free programming tools. If anyone has any experience with these guys I would love to hear about it. Does anyone see why this guy wouldn't work for me, or would you recommend something else (perhaps I don't need quite so much)?

While I'm quite familiar with assembly (in fact I've done RISC assembly before), I would prefer to write most of this in a HLL.

Thanks in advance!

[dunk]

hey,
so that's quite a list of requirements there.

so i'm just starting out with AVRs. (the ATmega2560 is an AVR.) so far i'm getting on well with them.
i have only used the ATmega8 so far but all the AVRs have essentially the same core so are largely interchangeable. just pick the one with the features you want.
this site is a good place to start with AVRs:
http://www.avrfreaks.net/ (you have to register to get to a lot of parts of this site.)
the range of features on the AVR controllers is great. they also run at amazingly fast speeds compaired to other microcontrollers. (they take far less clock cycles per instruction than most microcontrollers.)
the C compiler for these guys is free but there's not a huge amount of on-line information out there for them so i'm finding the learning curve more challenging than i did with other microcontrollers i have used.
(anyone else got any recommendations for good starting points for learning about AVRs?)

so Microchip's PICs are the other option to look at.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=74
they have been around a lot longer than AVRs so there's a lot of example code on the internet on how to program these guys.
if you want to just download someone else's sample code rather than write your own then these guys are the way to go.
they have the disadvantage of needing a more complicated (ie. expensive) programmer and if you want to program in something other than machine code you will have to buy a separate programming language (although PIC machine code is fairly simple to learn).

in my opinion (and this is probably going to get a few people defending their choice of micro) either PICs or AVRs are your 2 best options for what you want to do.
pick a microcontroller with a UART if you want easy communication with a PC serial port. (a UART is basically a logic level serial port.)
then with a little extra hardware you can send instruction to your microcontroller from hyperterminal (which comes free with windows).

have you considered breaking things down a bit into smaller components rather than doing everything on one controller?
what about using many smaller controllers? this would simplify the programming of each controller, especially when it comes to timing critical things like timing servo pulses.
you could have one microconroller for inputs, one for servo controll, one for motor controll, etc.
you would have to find a way to connect them all to a central controller.
i have used an i2c bus for this in the past which works very well. 1 controller as master (which translated signals between the i2c bus and a PC serial port) and all the others as slave devices. this has the advantage of being able to add further devices to the bus as your project grows.

i'm using a bit of a different method for my latest bot though. i'm using AVRs to connect to my main controller's USB ports.
this project was my inspiration: http://www.obdev.at/products/avrusb/index.html
now i can have an on-board computer controlling many different AVRs from a USB hub.
from the way you were talking in your last thread this might suit you as well?

anyway,
glad to hear you are making progress,

dunk.

[Admin]

Summarization (by guessing how you plan to control everything):
14 D/O
8 ADC
3 Interrupts

You are definitely pushing the upper limits of microcontrollers that are available . . .

What are your steppers for? Control might be simpler if you can avoid using them . . .
What about the encoders? I recommend avoiding them when you can, as they are difficult to implement. If you can, only use servos for everything - they are the simplest to work with. 

I also noticed you are using treads. If you are trying to keep track of position for your robot, it will fail for one reason - treads work based on skidding. Skidding is what happens when your robot moves but the wheels (and therefore encoders) do not. Error will build up incredibly fast with treads. You can still use encoders to track wheel rpm's, but thats it. And if your gonna have accelerometers anyway, its better to use the accelerometers to determine velocity 

[ilovetabasco]

Thanks for the prompt reply!

I am noticing the PICs have much stronger following (due to be being around longer, servicing the universities, and giving away free samples).

I did consider a "nework" or otherwise offloading the tasks to different micros, and am not apposed to it. The only reason for grouping them into one was to make data sharing easier, and the AVR looked like it was up to the task.

Generally, it features:
256K flash (more than enough)
16 channel 10 bit ADC
4 USARTS (which I presume is the same as a UART, haven't researched this yet)
86 DIO lines
up to 16 MHz and 1 MIPS/MHz for most instructions

That being said, the scalability of an I2C bus is quite lucrative. I will spend some more time investigating that (and also perhaps a CAN would be applicable?).

By the way, I found a similar project utilizing an AVR and accelerometers/gyros (same ones that I found). http://www.circuitcellar.com/avr2004/DA3728.html

Thanks again!
-ilt

[ilovetabasco]

What are your steppers for?

I haven't done the math yet, but I expected they would be necessary for rotating the turret.
Requirements for turret rotation:
Rotate 30 lbs (this is an upper limit) resting on a bearing turntable (no clue as to coeffecients of friction) 360 degrees in ~ 5 seconds.
Given an absolute position to turn to, I would rather go straight there without oscillating back and forth.
On boot or reset, I would prefer to know my absolute position w/o having to go home.
(hopefully not too ambitious)
The other stepper was for aiming the barrel (paintball gun) up and down, though I could probably replace it with a servo.

What about the encoders?

The absolute, as mentioned above, would be to know my turret position on startup. The other two were for velocity of the left and right treads.

I also noticed you are using treads. If you are trying to keep track of position for your robot, it will fail for one reason - treads work based on skidding. Skidding is what happens when your robot moves but the wheels (and therefore encoders) do not. Error will build up incredibly fast with treads. You can still use encoders to track wheel rpm's, but thats it. And if your gonna have accelerometers anyway, its better to use the accelerometers to determine velocity 

I am actually using positive drive treads (I know my model doesn't show it yet, but the cylinder in the top  is me getting lazy and not creating the sproket), so any skidding that occurs will be between the tread and the ground. I have no clue how much this will occur, but you are probably correct. I am, however, more concerned about velocity than position, so there would be no accumulation.

You're absolutely right though, I don't see any reason to use the encoders over the accelerometers. Obviously I would have to continually integrate the acceleration to get velocity, and recalibrate any time the drive motors stop, but that shouldn't be too difficult.

Thanks as always!

[Spoil9]

Going through old threads on microcontrollers and I came across this.
Just wondering if you had an update to the project, which MC you went with, and how it worked?