Right now, the problem of getting a robot up and running in the sense that we have been doing for the previous years is not big enough to consume the resources of even one person. ( We have consistently done most of the coding after the robot has been built )
Another problem is that the robot code can only really be written when the robot is done. (you need a robot or a partial robot to be able to debug things)
The business logic that gets written to actually drive the robot will get debugged, and thus most likely written when the robot is built.
Thus the only thing we can do before the robot is built is developing frameworks and libraries.
This means that the problems that are left are much harder (We've already done all the easy stuff)
In the past this has meant:
- A re-loader framework that sped up the downloading process.
Currently ideas I've heard of are:
- Porting ROS to the robot.
This means that we have no comprehensive plan or anything yet on what the structure of the code actually running on the robot in competition is going to look like. Without any such framework, it is going to be really hard to incorporate new team members. Yes, we might be able to run them through some sort of skills workshop or something where we teach them programming concepts, but we won't be able to get them doing anything until they can actually program robot code (which is quite different than tutorial code)
One thing that I would like is to nail down this framework sometime soon.
What would be really cool is to have this framework implemented similarly on a botball robot with enough abstraction where they could write some autonomous navigation code for the botball robot, or some controls thing, or some camera thing, and then be able to stitch that into our FRC robot code. ( meaning we could write navigation code for a robot one year, and use it the next year.) ( I don't know if ROS will do this or not but it sounds like it will work for FRC only if it gets ported )
I think that new members would then be able to fit into this. (we could give them stuff to work on, and then it would work, or they could come up with something and make it work)
Unfortunately, this means my answer is that we are not ready for new programmers yet. ( I propose fixing this is top priority )
I think what you have new members do should be robot related. (it is a robot team after all !)
Thus, what you can do with new members fits into something like this:
- Have them program in an existing framework (my 2011 code, or WPILib ) ( This is going to be taxing if you want to switch out of the framework )
- Have them program botball robots. (some of them already have done this. They will most likely learn very little)
- Have them wait until the new framework is ready.
- Have them stub out the framework, and then get started on stuff ( people could work on writing camera processing logic (I have stuff that tries to do some of this ) ) ( unfortunately these problems are all much harder than what people expect to be doing (there is only so much direct stick to victor code to write) ) ( they'll learn quickly that they'll have to be reading papers and stuff like that)
I see great potential here in how we can put co-processors on the robot and everything, I think we can and should have several other boards processing extra sensor data (this would be super cool)
I think we can make it work with more programmers, but we need a much better plan. (FRC has much fewer programming limits unlike FLL and to a certain extent Botball which have hardware sensor and processor limits)
I'm willing to help sort these things out, but I don't think I'll be doing much showing up until school is out. ( If you really need me in person, I can arrange for that )
I'm also willing to be available through chat / email to look at robot code and provide suggestions.
What we do all depends on how many people are interested, and to what level, and with what skills.
( We could have contests and stuff or whatever. I don't know. They will not continue unless we actually have a place for them. )