Choice of computing hardware for a robotics project

[Justin218]

I dunno, I haven't read through this entire thread, but most robotics projects do not use desktop PC components. There are arrays of microcontrollers and such that control individual subsystems. Or a better microcontroller that can handle everything. Not a desktop CPU though... I was building a robot for the trinity fire fighting robot competition last year but I never finished it. I kind of went the opposite way of you. I didn't have enough processing power/microcontrollers for what I was doing. I was running the entire robot off one higher end basic stamp. Couldn't handle moving and sensor data at the same time. The basic stamp couldn't multitask. I found this guy's web site, he built a robot for the same competition I was going to enter. His robot looks pretty good. http://voodooz.no-ip.org/robotics/srx1/srx1.html

 

[Lynx516]

To link them you need to find a common interface. This might sound strange but if you change teh amtel CPU to a Motorola core (will post the cores that I think are suitable at the bottom of teh page) you can use USB. However I am not sure how fast it will be. you will have to do some maths based on the siz eof the images and how many you want to get processed a second. Also the Motorola core is/should be fast enough to do the data processing from other sencors. You will be surprised how powerfull these tiny things are. If you code efficently (you might want to use ASM for the motorola/amtel core) you can easily make a very nippy system.

On how to program teh Blackfin the analog decives site has some code examples.

Link to an 8 bit MCU
When you get more than 8bit controllers things start getting alot more complex. i.e. having to put RAM outside the chip e.t.c and you will areadly have that fun with an ARM core.

 

[blahblah99]

Originally posted by: sleepydj
Hi,

I was talking to a good friend of mine who also recommended that I go in for a "split-up" system as opposed to a centralized system; along the lines of what Lynx and blahblah99 and others had recommended. So, I guess I should be doing that.

So does something like this sound ok?:

At the top:
Supervisor and Master Control: some ARM processor

At the 'same level':
Image n audio processing: AD Blackfin
Data processing from other sensors: ? (more ARM?)
Motor Control: x nos Atmel TinyAVR

So, the supervisor/master controller would be the one which interpets the data from the Blackfin and the other processor for the sensors. It then decides what to do and accordingly drives the motor controllers. Obivously, there is more hardware than this, but this is just the arch of how processors will be configured

Alright, I know I should be actually doing this on my own, but just for starters, can anyone say, with what bus I can connect them? I know that Atmel's have the I2C.

Also, what skills will I need to program the blackfin? I was recommended www.dspguide.com , but that's huge! Will I need all/quite a bit of that??!!!

With regards, to how fast the robot will move, I guess it's gonna be somewhere between the 3KMPH to 5KMPH. This is just a based on performances of other teams. How fast ours will go, i have no clue yet. So, I guess, the update frequency can be chosen with the 5KMPH mark in mind with some head room and then suitably modified later on.

Thanks again.

cheers
Jimmy

You're getting there... I would use Motorola's 32-bit ColdFire as the host processor and 1 FAT DSP for audio/video processing like TI's C67... That'll pretty much give you all the processing power you'll ever need for your robot project. The reason why I chose TIs C67 is becuase not only is it a decent dsp, their development kit is CHEAP - $400 gets you everything you need to start writing and testing your code.

Because the dsp is doing both audio and video processing, you only need to reserve one interrupt on the coldfire for the dsp and in a single burst transfer stream both the processed audio and video data over. Then the coldfire could run its control algorithm and spit out the appropriate control signals.

All this may take a while to implement if you have no experience with embedded systems and have never done high speed pcb design before.

 

[sleepydj]

Originally posted by: blahblah99


You're getting there... I would use Motorola's 32-bit ColdFire as the host processor and 1 FAT DSP for audio/video processing like TI's C67... That'll pretty much give you all the processing power you'll ever need for your robot project. The reason why I chose TIs C67 is becuase not only is it a decent dsp, their development kit is CHEAP - $400 gets you everything you need to start writing and testing your code.

Because the dsp is doing both audio and video processing, you only need to reserve one interrupt on the coldfire for the dsp and in a single burst transfer stream both the processed audio and video data over. Then the coldfire could run its control algorithm and spit out the appropriate control signals.

All this may take a while to implement if you have no experience with embedded systems and have never done high speed pcb design before.

Hi,

I was told that working with TI's is pretty complex because they have a complex instruction set and also a poor C/C++ environment(?). Apart from that I was also told, that this being the first time we're working with DSP's etc, we should stay away from TI's. You had also mentioned the Blackfin. What about that?

Meanwhile, I'll check out the ColdFire. Which processor would I need for the sensor interpretation. As for now, we have the basic sensors - a tri-axis inclinometer (used for figuring out the orientation, tilt, yaw, pitch of the robot), a depth sensor, and a Doppler Velocity Log (measures speed by using sonar and bouncing it off the floor). The only thing that microcontroller would have to do is just periodically get updates from the sensor and store them or pass them to the master (that can be decided later). So, i'm guessing we don't need anything fancy here. And I guess the bits of the mcu would be decided by the size of the data that the sensors give, right?

I'll check out both the Motorola that Lynx mentioned and the Atmels that a team-mate recommended. I guess we can use the same ones for the sensor and the motor processor. Or atleast the motor's processor shouldn't need more than 8-bits, and we could get away with only a couple of MIPS, right?

Just out of curiosity, why a ColdFire? why not an ARM? Is there anything better in them? I'm checking out on my own to...but as u'd guess.....at this stage it's kind of difficult to make sense of all the information. Or is it something like ease of programmability etc.?

Thanks a lot!!

Cheers,
Jimmy



*EDIT: What range of MIPS should I be looking for in the ColdFire? or ARM? I'm going through the ColdFire's different models right now and they have ones from 50MIPS to 316. Basically the ColdFire is going to be the master controller. So, it will have to make sense of the imaging data, interpret the data from the other sensors, make desicisions and drive the motors. So, in my opinion that is quite a bit of processing to do, right? But like before actually buying one, how do I judge what is good enough? Any way to guestimate the MIPS?

 

[Lynx516]

To guess how many MIPS you need. you need to basically write your code. or at least split up what you need to do into seperate chunks and make a very very generous estimate on how many instructions (Asembler not C++) it will take to accomplish. From that you should be able to make a guesstimate. Just make sure your guess is more than what you need.

edit: A coldfire Processor is much easyer to implement than an ARM core. To start with ARM dont actually sell the ARM cores they licence them out to other companies who have to make them (I did work experience there and TBH I was not impressed). Secondly ColdFire is an extremely mature solution and has free documentation .