That’s probably very difficult to do unless you have somebody doing detailed CAD drawings, exact parts on hand, and can assign kids subassemblies.
If you can break up the robot into two or three large sections (Chassis, Lifting Arm, Gripper, etc.) and have one or two kids work on each section, that might work. Another way to divide labor is to find one or two kids who might like to do programming, learn about sensors, try out ideas for autonomous, etc. so that you can hit the ground running with great software as soon as the robot is mechanically intact. Other kids might do well documenting the design for the notebook. This year, for SkyRise, I think I could have kept two kids busy just testing out different ways for grabbing yellow SkyRise sections.
So this is what our team calls the “States Paradox” because last year for the Northern California State Championships, we tried building each part separately. Each component worked great, but when we tried putting them together we ended up having to rebuild some parts because they just were not compatible. Unless you have the robot CADed out or planned really well, I would recommend not doing this.
Usually our team just has each person working on the same thing, but mirroring/building copies. For example, we have one subteam build one half of the drive and the other build the other half.
We had this issue, as some members in our large team (~8 members), could not do anything on their own, and if not given work, would become a hindrance and distraction for the rest of the team. We then had to resort to having them help with the person building, or assign them menial labor, like sorting screws,cutting c-channel, and finding the ever-elusive white washers, which oddly, they seemed more than happy to do.
We have found it is best to have people on a team assigned a certain job. For example, there will be a lead builder, lead programmer, lead driver, and lead technical tasks. Then each person depending on their skills can help the lead person with their task. But generally it is best with people who specialize in one or two fields. Then have those different talents come together.
There is typically one programmer per team in our club. Sharing code is typically harder than building together. The programmer can tend to have more hours required for autonomous programming. Having a teammate or two be the field resetter helps a lot and is a shared job in programming.
Robot C does not directly integrate to GitHub or other version control systems to facilitate team programming. Putting it on a Google Drive is the best you can do easily without moving on to Convex or Pros where your IDE is your choice.
I found that by using the program Git Extensions, all types of files are easy to host online, and BitBucket allows free private repositories for up to 5 users in an organization. We use this for the Code (ConVex), the CAD (SolidWorks), and any other files, such as videos and pictures.
Thank you both. Just wanted to make sure. We had a situation where someone not very versed in such semantics was doing just that. It had been good so far but all of a sudden it kinda rocked the boat and that would lead to coding conflicts. Although the argument might in the spirit for sharing etc, it would lead to double work fixing things or waste of time explaining concepts etc. Playing with sample code (learn) would be better than jumping into altering competition-level code. Thanks again.
ROBOTC handles versions for us. My recycle bin has hundreds of old versions dated by deletion date.
In all seriousness I usually upload my code to a dropbox folder periodically (more often then not its when I scrap and build a new robot). I left my old High School team with copies of some of my code just for quick reference in terms of syntax and how to go about creating autonomous routines and such.
I would recommend to all people getting into it now to start getting into the habit of version control. Also while your learning good programming habits
COMMENT your code.