Is anyone interested in participating in a FIRST-only team programming competition?
See this other thread for info … http://www.chiefdelphi.com/forums/showthread.php?t=25123
Reply here if you are interested.
Depends on when it is and the cost of the entry fee (still being disputed over at the other thread, so I don’t know what you’ll decide). Sounds like fun! 
Sure, after I finish Autonomous.
How about one for what you run in a bot at a competition?
I would be interested, but like they said I need to know what the entry fee is going to be.
:eek: Well it is nice to know that my team just signs me up for stuff. :eek:
What do you think is a fair entry fee and prize?
This is what I would ideally want the competition to look like:
Write an autonomous program that would read in data from virtual sensors and attempt to do a certain thing. The simulator (that is written by the organizers) would feed realistic sensor data to the program. The program would respond by sending signals to the motors.
When everybody’s submitted their code, NRG would make the “robots” compete in an online Flash presentation. Like in real competitions, people would be able to modigy and resubmit their code for subsequent matches. If me and the other NRG members can pull this off, I think it would be really cool.
This sounds like a fun thing … but I’m not too sure about entrance fees and prizes and all. Maybe if it started out as a friendly competition with name recognition and a virtual pat on the back the reward more participation would be obtained. I assume the simulator would be available to teams so they could test their code? (How about the source? Would this be developed independently … or is community involvement being sought).
Eithe way, all I can say is now is too soon! Far too much going on to give it any serious thought (in school alone … but also I believe there’s some sort of robot competition approaching? ;))
Point taken well, but if something is to be ready when Nationals are over, I think it would be best to plan ahead.
- Yes, the simulator would be available to teams ahead of time.
- Who is writing the simulator? I don’t know. Maybe I’ll make it a sourceforge project.
And, I think the visual simulator will be a Java/C++ hybrid, not Flash.
OR - the simulator could be a Direct3d application that would download real time data from NRG’s server.
There’s an idea. DirectX covers video, audio, multi-player, and probably some other things. But realtime may be a little excesive (Maybe not- you may just stream position data and sound)
If you go DirectX, can we send virtual models of our bots with an INI describing motor data?
I must say that using DirectX is one of the best ideas i have seen posted on this fourm. Not that i am saying that i would not be interested if you didn’t use it cuz i still would be. (Even though my team said i would participate before i even knew about it) I think that this is a very creative way of fundraising and depending on just what the fee is I would be very interested. 
That is a great idea for motors being describing in an INI. Virtual models would be possible if someone can write a model loader in Visual Basic for DirectX 9.0. I’ve begun writing the simulator, I’ll probably have incremental downloads accessible at the RoboCoder (any ideas for a better name?) site:
http://nrg.chaosnet.org/coder
I would have to precompute each match’s results at our computers. Then I would make the simulator download the latest match and play it so that each robot followed the path I precomputed. Then after the match, you could resubmit code to improve. I would then precompute the next match’s results, and the cycle continues.
I’m trying to figure out a way to spread the word, how would I go about doing this?
If you check MSDN and search for DirectX, there should be some SDKs on it. I downloaded v7, but I don’t claim to understand it. I would recomend starting a thread to create the file standard. (.Bot for data? :))
Write an autonomous program that would read in data from virtual sensors and attempt to do a certain thing. The simulator (that is written by the organizers) would feed realistic sensor data to the program. The program would respond by sending signals to the motors.
That is a great idea for motors being describing in an INI. Virtual models would be possible if someone can write a model loader in Visual Basic for DirectX 9.0.
Hrm… it seems like the project might be getting a bit complicated. I don’t know, but is there necessarily a need for fancy graphics, or even to “describe” a motor? I guess it all comes down to what you want the competition to be … and so I think you need to first say that, so everyone is on the same page. What sort of challenge is it? Are we competing against other “robots” to get somewhere first, or is it solo (either timed or otherwise scored)? Does everyone get the same virtual “robot”, or can it be modified (if so, I’d remember to keep the focus on programming). I was under the impression it would suffice to model the robot as either a point or other simple geometric object, and that there wouldn’t be a need to display it. Perhaps I’m wrong, but what is the compelling reason to have graphics and other complications? Not that I’m complaining: if you can get it all to work, that would be great … but I’m just trying to think of how manageable it is to code the base quickly enough with less room for bugs so that the competition is more viable. (And not everyone necessarily has DirectX or even windows … but that’s something else to think about.)
intriguing I’ll bet our team would be interested.
The robot would probably be a rotatable/translatable rectangle, not a point, so that you can send signals to multiple motors placed at the corners of the bots. 3d graphics isn’t neccessary or even warranted, but would be a cool “plus” if I can finish everything else first. Java will probably be the simulation language of choice. About the competition itself: one robot vs. another.
The reason I sugested the INI thing was so that the sim could get feed-back from any pots or whatever you have on the bot. Of course, we would have to check it to make sure you don’t have, like, a gear with .5 teeth (REALLY slow, ultra powerful). I would say restrict the motors to kinds in the kit, and in the INI, say which one. I’ll create a thread on it.
A system like this already exists, developed using Java by IBM. http://robocode.alphaworks.ibm.com/home/home.html The robots attack each other, but you may be able to use the framework as a starting point.
I think we should all program with one robot like mtrawls said. You can see my response to this kind of over-complication here:
Focus on the competition
This is the overall structure that I propose:
Everything is written in Java. (If you want to, it may be possible to write in C and link into Java using Native methods, but that’s something to be discussed later). A simulator class will calculate the position of the robots and keep track of scores, the game world, etc. Each team submits one Java class that implements a “RobotCode” interface. Interrupts would not be implemented. The simulator would call an “Initialize” method on each Robot. Then, at every “frame”, the simulator class would call a “NextFrame” method on each robot so that it could calculate the signal to its motors. The robot can call a GetSensorValue method on the simulator to get sensor values. A summary follows:
|---------| <— GetSensorValue ------< |----------|
|Simulator| >— Initialize -------------> |RobotCode|
|---------| >— NextFrame -----------> |----------|
I’m a C man myself (of the languages I use, Java is not included), so this discussion will concentrate on C/C++ data types and such (I trust it should be easy enough to follow, though, Java or not).
I’ll start a discussion of the Robot class, as this is where all the end user action will be, so the most “community” discussion should be concentrated here (as I see it, anyway). The important things for this class will be the private (or public) data and the methods.
The data is mostly sensory input (and other metadata the simulator might need, such as team number). It should be decided, then, what types of sensors will be used, and their range (I assume it would most likely emulate the behaivor of the stuff we use). Maybe an IR sensor – in which case, this might be an opportunity for simplification. Since the competition isn’t designed to test our interrupt-from-scratch skills, just a simple boolean value (see IR or not) would do (or a more complicated value in case there are various beacon types). If you include a gyro, it might be a bit easier so far as the simulator itself is concerned just to give the angle directly, instead of giving rate of turn. Maybe we have some sort of arm that we can extend for some reason, in which case we might have a pot input, which should be straightforward enough. Who knows? The inputs should be controlled by “the creators” of the competition, obviously, so I’ll just leave my thoughts as they are here. (I imagine all this will be encapsulated healthfully enough in some Get_xxx methods. Go OOP! ;))
Then we can move to the (other) methods. This is the fun stuff! Things like Move_Robot(x) and Turn_Robot(x) – or perhaps a bit more indirectly, via Set_Left_Drive(x) and Set_Right_Drive(x). This is where we’d be able to set the motor output to our hypothetical arm, for instance. However you expect us to respond to our inputs will have to be considered here.
Therefore, it would be nice to start with a description of the “robot” we’d all be using … a base design by “the people in charge” so we all have some baseline to work from, and then some community input based on that. It would be immensely easier to start thinking of the design of the simulator itself once it is figured out just exactly what it has to do – and hence what the robot is capable of needs to be defined first.