Programmers: I Have A Challenge For You

[Rion Atkinson]

Originally Posted by ideasrule

For people who are interested in this, take a look at the autonomous programs on Spirit, Opportunity, and MSL. They have 20, 20, and 200 MHz processors respectively, running vxWorks, the same operating system that's on the cRIO. They also operate in a much simpler environment than FRC. These robots give a good idea of what vision processing is capable of.

Those would me the MARS Rovers, no? I think Dave could shed some light on that subject.

[Radical Pi]

Originally Posted by 45Auto

It appears that we have a big disconnect on what "fully-autonomous" means. My definition is more in line with the online dictionaries and Wikipedia:

A fully autonomous robot has the ability to

- Gain information about the environment.
- Work for an extended period without human intervention.
- Move either all or part of itself throughout its operating environment without human assistance.
- Avoid situations that are harmful to people, property, or itself unless those are part of its design specifications.

Not sure what your "human sensors" are (voice recognition or real people pressing buttons in the loop?) but in either case, it's still human intervention

Probably not the idea of the other people wanting to participate in this, but I don't think a "full autonomous" robot is a good target. A "Human-assisted autonomous" (like hybrid mode?) is a more reasonable target for competition use IMO. In my limited memory of the mars rovers, I remember that even they weren't "fully autonomous". To compensate for the immense lag in transmissions between earth and mars, the human operators on earth would send out high-level commands, and then the rover implements the commands autonomously, doing things such as avoiding rocks in it's path while moving. That's exactly what would be useful in one of these competitions.

Imagine walking to the field with a control board that is one switch: score or block. These tasks are all autonomous, it's just the human operators tell the bot whether to kick that ball or to pin that bot. I'd still call this an excellent project if that was where it went

[theprgramerdude]

Originally Posted by tsa256

I agree, the processing is a very debilitating bottleneck. We've debated some solutions such as other processors and ran into the same problems discussed above. I think the way to combat would be to find the best combination of processing and plausibility of it actually working. As stated above you could strap a computer on the robot but not only does a CUDA processor pull massive power, upwards of 400 watts if I remember correctly; and as for getting useful information out of the mother bored would be a challenge. Also probability of a mother bored not cracking is slim to none. Although I'm unfamiliar with this new camera module I think that may be the way to do it. I'm planning on researching it in depth as soon as I can.

I was aware of the power draw. I'm not saying we should strap on a few 295GTX's in SLI and go from there, but use a smaller processor which draws 100-150 watts max. A low-power dual-core CPU would simply handle off-loading tasks to the GPU and handling I/O to the memory banks and Crio. My old-model 8800 GTS would easily handle the job, and it tops out at ~120 watts.

I guess we'd also need a way to keep a powersupply which can survive even in extreme low voltage situations and keep the current going to the system. As you could witness by watching the DS during a match this year, simply taxing 2 CIM's to stall drops the voltage to 8ish volts from a full battery, more if you have other systems or a damaged battery (as I witnessed when we got down to 5, then witnessed some fluid around it after the match. It was retired).

[gblake]

Folks - About adding more computing power to an FRC Robot - The last time I looked into them, I thought the Gumstix line offered some attractive options - Blake
http://www.gumstix.com/
http://en.wikipedia.org/wiki/Gumstix

[davidthefat]

Originally Posted by gblake

Folks - About adding more computing power to an FRC Robot - The last time I looked into them, I thought the Gumstix line offered some attractive options - Blake
http://www.gumstix.com/
http://en.wikipedia.org/wiki/Gumstix

Currently attempting to make a board with a PIC controller, mentors gonna help me decide on what though

[davidthefat]

Oh $@#$@#$@#$@#, costing me about $100 out of my mom's pocket for all this stuff... $@#$@#$@#$@# it can get expensive real fast

[Greg McKaskle]

Cost is one of the reasons why mentors have been encouraging you to consider simulation or emulation. SW development doesn't have to wait for HW completion, and in the real world it typically doesn't.

Greg McKaskle

[demosthenes2k8]

Although I haven't read the full thread, I would like to say that I think it's feasable, and would love to attempt this over the summer.
We had a concept like this early on, but it was scrapped due to hardware problems-half the sensors it needed didn't get mounted. It definitely wasn't as complete a concept as this, but it should possible with Chopshop's current system. We still have the code saved in svn and hg, so we can get it back. The hardest part would probably be using the camera to see what's going on...

[AustinSchuh]

Originally Posted by gblake

Folks - About adding more computing power to an FRC Robot - The last time I looked into them, I thought the Gumstix line offered some attractive options - Blake

The BeagleBoard is another comparable board that costs about $149. It's a lot cheaper than a Gumstix, though it isn't as small. And it uses the same CPU.

BeagleBoard

The BeagleBoard and the Gumstix are running an OMAP3 chip, which as an ARM Cortex-A8 core in it. They are clocked between 500 Mhz and 600 Mhz CPUs with Cortex-A9's are coming out shortly, and look to be very high performers. They are clocked at about 1 Ghz, and have two cores. I'm personally waiting until I can get my hands on an Cortex-A9 before I invest in any hardware for a similar project.

For those of you interested in learning how to do some AI, I recommend looking over the CS188 lecture slides from Berkeley. http://inst.eecs.berkeley.edu/~cs188...uncements.html I took the class a semester ago, and learned a lot.

[Radical Pi]

The BeagleBoard could be a good option. Load a small distro of linux on it, and then communicate over RS-232. Personally I couldn't do it since my mentor would kill me for breaking the CAN-bus (do RS-232 multiplexers exist, and more importantly, would they be FRC-legal?

EDIT: Actually, a board with an ethernet port would probably be easier to use. If we put a switch on eth2, we could plug the camera and extra board in and have the alternate board read directly from the camera and do the processing there. It would save a lot of overhead for many teams and bypass any rules issues, since ethernet switches are perfectly legal (2CAN)

[The Lucas]

You can also use SPI, I2C, and CAN for communication, provided you follow the rules.

[Kevin Watson]

Originally Posted by ideasrule

For people who are interested in this, take a look at the autonomous programs on Spirit, Opportunity, and MSL. They have 20, 20, and 200 MHz processors respectively, running vxWorks, the same operating system that's on the cRIO. They also operate in a much simpler environment than FRC. These robots give a good idea of what vision processing is capable of.

Anyone care to guess how far Spirit or Opportunity can drive fully autonomously during the few minutes a match lasts?

-Kevin

[Boydean]

Originally Posted by Kevin Watson

Anyone care to guess how far Spirit or Opportunity can drive fully autonomously during the few minutes a match lasts?

-Kevin

I would say about 20ish feet. Given the overall mechanical speed and the environment its in. Plus it needs to be REALLY sure its not going to get hurt wherever its heading. Then again, I would imagine they don't want it going to far with asking for another command because of safety issues.

[Chris is me]

Originally Posted by Boydean

I would say about 20ish feet. Given the overall mechanical speed and the environment its in. Plus it needs to be REALLY sure its not going to get hurt wherever its heading. Then again, I would imagine they don't want it going to far with asking for another command because of safety issues.

The limiting factor probably isn't mechanical speed...

[Burmeister #279]

I actually laughed out load at the first post I would love to do it, but our head mentor has zero faith in the programming for who knows what reason. I was told that once she decided the robot was performing fine i wasn't allowed to touch it again until after competition. God himself couldn't convince her to allow the programmers to fully automate our robotn