Let's have Linux Robots Next Year!

[Ryan M.]

Cool... although I'm a little confused. So... the PC does all the processing, then sends the commands to the RC, which sets the output according to what the PC says? That's pretty nifty, and I'll probably try it out, but is that legal for a match?

[jdong]

Yeah, pretty much

Now that at least a proof-of-concept is working better than originally expected, I'm gonna augment the protocol to send more inputs and allow for more outputs.

[mechanicalbrain]

Originally Posted by jgannon

I am intrigued by this project. However, keep in mind one thing:
"<R69> All equipment connected to the Joystick Ports of the Operator Interface must be powered solely through the power available through the port. External power sources of any type are not permitted on any equipment connected to the Joystick Ports. Portable computing devices may not be connected to Joystick input ports on the Operator Interface."

As you've pointed out, the Dashboard port is one-directional, so the only way to send data to the RC is through the joystick ports. I don't know how this impacts your plan. Nonetheless, good luck, and keep us updated.

(On a side note, those gumstix computing devices look awesome... definitely something I'll keep in mind for future projects.)

I dint know if this was pointed out or not and i may be wrong but this refers only to the joystick ports. This is to prevent the unfair use of extremely expensive or nice control systems by limiting the power available. In fact I'm sure Ive seen control systems that integrated laptops for dashboard viewing. however i agree that the dashboard is not a two way connection. Ive seen allot of threads about using outside computing systems to augment or change the normal game play and i think that it should be explored for the learning potential but should not be attempted in game play as not only would this give teams a hugely unfair advantage it would also change the way the game is played. I didn't read every post on this thread so this might have already been pointed out and if so I'm sorry for acting like a parrot.

[jdong]

Originally Posted by mechanicalbrain

Ive seen allot of threads about using outside computing systems to augment or change the normal game play and i think that it should be explored for the learning potential but should not be attempted in game play as not only would this give teams a hugely unfair advantage it would also change the way the game is played.

I disagree. True, this may evolve the arena, but most of that would be restricted to Autonomous mode features.

Also, I am developing everything under the GPL, from the code required to support the protocol to the ways Team 245 is applying the coprocessor setup to our gameplay. I'd like to see innovation in programming at FIRST, for all teams to take it to the next level. This is just another way to help see that happen.

[mechanicalbrain]

I agree that its very cool and I too would like to see it. My only problem is that after talking to newer and smaller teams who have it hard enough building a robot and then come to compititions and see these arcwelded laser cut robots, will this be something all teams can easily utilize even ones with limited resources? If so power to you and please send me updates of your progress but if not maybe leave it out of the arena and more of a personal project as well as sending me updates. No matter how you look at it its a cool idea i just don't want to see small and unexperienced teams be limited in their ability to compete.

[lynca]

Jdong, I think you are leading the wave of a flexible software platform,

Suggestions for making your software more widespread: most people don't have a linux machine at therey fingertips (not yet anyway) therefore you should make a detailed tutorial on the wiki on how to get started, and make it very big and easy to spot,

this includes downloading subversion for windows or linux ,
running the first example of the code
and pointing out where development needs work,

I will be happy to help write the manual or develop code, just tell me where to start (which wiki page and where)

~Andrew Lynch

[jdong]

lynca -- you gotta understand, I JUST managed to get the communications protocol set. That's just the first step towards this programming platform.

My final vision -- The thing will use USB networking to talk to both Windows and Linux computers via HTTP, with the ability to upload or edit code. The "code" is written in Python, so just a text editor is required for changes (and a text editor runs on any OS).

In other words, the requirements for the FINAL coprocessor would be a web browser and a text editor!

I'm not ready to release this solution to the general public yet; more development on stabilizing the technology has to take place.

Our Wiki for the coprocessor is at http://adambots.gotdns.com/cgi-bin/v...rceCoProcessor and http://adambots.gotdns.com/cgi-bin/v...umstixTutorial. The documentation is going to evolve as we're in a very early phase of development. I'd suggest that you hold on documentation until we reach the 0.5.0 milestone.

[jdong]

http://www.chiefdelphi.com/forums/sh...d.php?p=402247

I've tagged and packaged a preview release. See its thread for links to some Wiki documentation. If you'd like to augment the Getting Started guide with more details or your experiences, feel free to do so!