|
Post by nardella on Oct 5, 2010 22:10:28 GMT -5
I have not even laid my hands on the EvalBot but I am already coming up with tones of ideas for upgrades.
I would like to see some kind of range finding device to mount on the bot.
I am also curious to know how easily infrared communications could be established as a cheaper solution for wireless.
I also have some ideas for non electronic upgrades.
I think rigid fixed arm sticking out from the bot could allow it to easily push around various light objects.
Also, perhaps a printed card with a pattern on the bot intended to aid external camera recognition of the robots location. This could lead to some very interesting augmented reality possibilities!
For the last suggested physical upgrade I would think adding a lens over it to increase readability.
|
|
|
Post by necromant on Oct 6, 2010 5:28:33 GMT -5
There are cheap servos at dealextreme avaliable... wonder if we can make a robotic arm stick out of the bot. The servo control can be easily done by an atmega, interfaced to this uC via spi
|
|
|
Post by nardella on Oct 6, 2010 11:53:23 GMT -5
I would not be surprised if a mechanical solution for controlling an arm could be found. Just like old school wired toy RC cars with only one motor and nothing else. Forward goes straight reverse turns allowing the car to move anywhere a more advanced car can go. Just slower.
I think this kind of solution would be best because it would be more accessible to EvalBot owners. Perhaps made out of LEGO.
Finally I suspect that anything intended to move something up or down more than a centimeter or two would be too much to ask for such a small and light platform.
Again I reiterate that this robot is probably not very useful for practical applications and would best be used for academic exercises.
|
|
|
Post by Parker Reed on Oct 6, 2010 14:28:35 GMT -5
Is this Evalbot balancing like a Segway? I couldn't tell much from the video. I agree with nardella, that this won't be very useful in practical situations. I envision it being more of a development or rover platform. It could roll up to a ball bearing and scoop it up just enough to transport it to a different location. This will be a great project to tinker with.
|
|
|
Post by Hopelessness on Oct 6, 2010 16:37:45 GMT -5
I'm quite tempted to desolder the motors and replace them with motor drivers for something a bit bigger. Either that or use it to control a radio controlled car at high speed.
|
|
|
Post by nardella on Oct 6, 2010 22:30:30 GMT -5
A new question, could a camera be attached to the EvalBot that would allow it to do image analysis to help it make decisions? Or is it not powerful enough to do the analysis?
|
|
|
Post by jethroevb on Oct 6, 2010 23:32:37 GMT -5
A new question, could a camera be attached to the EvalBot that would allow it to do image analysis to help it make decisions? Or is it not powerful enough to do the analysis? The main problem would be the amount of RAM. A 320x240 pixel 8-bit grayscale image already takes 75 kB or almost 80% of the available internal RAM. If you downscale the image while reading it from the camera, you can save a lot of RAM (e.g. a 160x120 8-bit grayscale image: about 20 kB). Still, you should be able to run some simple feature recognition algorithms. The Cortex M3 core is actually quite powerful, if you can get around the memory limitations.
|
|
|
Post by necromant on Oct 7, 2010 2:08:09 GMT -5
A new question, could a camera be attached to the EvalBot that would allow it to do image analysis to help it make decisions? Or is it not powerful enough to do the analysis? The main problem would be the amount of RAM. A 320x240 pixel 8-bit grayscale image already takes 75 kB or almost 80% of the available internal RAM. If you downscale the image while reading it from the camera, you can save a lot of RAM (e.g. a 160x120 8-bit grayscale image: about 20 kB). Still, you should be able to run some simple feature recognition algorithms. The Cortex M3 core is actually quite powerful, if you can get around the memory limitations. I guess there's no point in truing it to do in software. I think, I'll be ordering a Xilinx spartan FPGA and wiring it as an extension to the evalbot with a bunch of sdram, so that I can run such things in hardware. In that case all the uC should do - pump the video data to the fpga.
|
|
|
Post by nardella on Oct 7, 2010 15:17:53 GMT -5
I guess there's no point in truing it to do in software. I think, I'll be ordering a Xilinx spartan FPGA and wiring it as an extension to the evalbot with a bunch of sdram, so that I can run such things in hardware. In that case all the uC should do - pump the video data to the fpga. How much will that cost? Will it require surface mount soldering?
|
|
|
Post by jackthevendicator on Oct 7, 2010 17:18:55 GMT -5
I'm just reading the schematics, and it seems that the audio encoder supports a microphone (the input lines should be on a header). It supports SDIO too (the lines are on one of the wireless headers), so you can buy a wi-fi sdio card and write a driver for it. The motors run at 12V and the controllers can withstand a maximum current of 3A, then they will "trip" and will put a fault signal low. The controller also supports braking by recirculating the back-EMF from the motors.
|
|
|
Post by nardella on Oct 7, 2010 19:07:16 GMT -5
RE: SDIO I would prefer USB, who has a micro SDwifi card?
RE: Motors So what kind of pulling power does that mean?
RE: Microphone Awesome! Lots of ideas there!
|
|
|
Post by jackthevendicator on Oct 7, 2010 19:30:54 GMT -5
RE: SDIO RE: Motors So what kind of pulling power does that mean? 36W of pure electric power for each motor, with 75-80% efficiency (as wikipedia states). If we know the rpm, we can calculate the torque too. RE: Microphone Awesome! Lots of ideas there! I was thinking about a "sonar"/rangefinder based on time to travel of sound pulses... there was an article somewhere on the internet some time ago... --EDIT-- Article found ;D www.eddiem.com/projects/chirp/chirp.htm
|
|
|
Post by imlost on Oct 7, 2010 23:24:24 GMT -5
|
|
|
Post by necromant on Oct 8, 2010 16:35:13 GMT -5
From what I found in the uclinux maillists they say, that the uC will run code from external ram damn slow and it's not worth it. So, I guess, the best bet is either to make a second board with some at91rm9200, and fpga... or stick to some opensource rtos
|
|
|
Post by necromant on Oct 8, 2010 16:39:53 GMT -5
I guess there's no point in truing it to do in software. I think, I'll be ordering a Xilinx spartan FPGA and wiring it as an extension to the evalbot with a bunch of sdram, so that I can run such things in hardware. In that case all the uC should do - pump the video data to the fpga. How much will that cost? Will it require surface mount soldering? SMD - yes, BGA - I guess not. Costs.. Hm.. just running a quick check on the prices... An FPGA like XC3S500E will be about 20 bucks at most, sdram is cheap, about 3 bucks for 128mb chip (we ain't gonna route ddr in 6 layers, are we?). We might pop in an AT91RM9200 or AT91SAM, to run linux. The costs will be 50 bucks at most, I guess. Well, if you fabricate the pcb at home. More if you are off for factory made.
|
|