Log in

View Full Version : Version Control Systems


rwodonnell
20-09-2013, 18:16
I have been mentoring the last couple of seasons, and although I am a software engineer by profession, there are other mentors in our club with that skill as well, and they also have more experience with robotics type code (I am a web application developer.) As a result, I have found other ways to get involved, which has been a great learning experience.

However, in watching our programming team, it always sort of works out the same way. Though we have a few laptops capable of running the IDE (we are using Java), we end up with one kid on one of the laptops, and the others crowd around as he writes the code. As you can imagine, many of the kids that want to be engaged don't remain engaged, as well as the fact that the kid behind the wheel, so to speak, changes from meeting to meeting, and he doesn't always understand what changes the other kids made, and so on.

It seems to me that we are badly in need of using some sort of source control, and we are holding ourselves back by not using it more. (Technically, we check in and out of SVN, but really only about twice a season.) It would make sense to me, based on the kind of projects I have worked on professionally, to have one machine dedicated as a build machine, where nobody actually writes any code, and let the others do their work and check in, and so on.

I think there are several barriers to this, though. First, part of the reason they are operating the way they are now is that they have trouble having connecting to the robot and the internet at the same time. So the build machine can deploy to the robot and they update and deploy, and the cycle goes on like that, not really stopping until they're done, at which point they will check it in as a safety measure once in a blue moon. The second problem is that there is no way to test your code without deploying to the robot - the need for a simulator is huge, it seems to me, though I imagine with the variety of parts used in the robots, would be difficult.

So, because I am a noob to robotics programming, and really robotics in general, any help on these general questions would be great:
1. Do most teams use version control, and what do they use?
2. Do teams use a build machine, or build server, and what?
3. Is there a solution to this problem of connecting to the internet and to the robot network at the same time?
4. Is there a simulator that can help programmers?

Sorry so long... I guess I rambled. Thanks in advance for any answers.

Rick O'Donnell

calcmogul
20-09-2013, 19:17
The team I mentor uses C++. We have our code hosted on GitHub and use Git as our version control system.

Each of our programmers tends to have their own laptop and they each test changes independently. Once each has been tested, changes are pushed to GitHub and merged at the end of the night. One of the more experienced students and I fix conflicts as they arise.

As for internet, you could write a batch script for changing your network settings. I'm pretty sure there's a thread on CD that has discussed that before.

There's a simulator for LabVIEW and perhaps Java too, but I don't know of one for C++.

AllenGregoryIV
20-09-2013, 19:29
3. Is there a solution to this problem of connecting to the internet and to the robot network at the same time?


There are a couple, one you can connect the robot router to the internet. You can also have the robot router connect to another router that is online and have all the programmers connect to that router. Make sure to configure the routers IP settings to work nicely with the 10.xx.xx.xx configuration.

The second option and easier one, is to just use an external usb wifi adapter for connecting to the robot. I keep a cheap old 802.11g adapter in my bag for this reason.

westin444
20-09-2013, 19:38
My team has a setup very similar to Spartatroniks'.

We use C++, Git, and GitHub.

Typically the less experienced programmers on are team are delegated to two people per laptop if we do not have enough laptops that can use the IDE. The more senior programmers typically have one person to a laptop unless they are teaching.

The way we handle testing is code gets pushed to a "canary" branch on Git once whomever programmed it feels confident it will work. Depending on the type of change this sometimes involves testing on the robot and sometimes just involves syntax checking and walking through the change.

Once someone pushes a fairly large feature to the canary branch, or someone simply feels like it is time, the canary branch is compiled and downloaded to the robot. This is where most of the bugs get ironed out; whomever is testing just fixes the bugs that come up. Once the code is working properly, with no obvious bugs, it ends up in the release candidate branch. If a major bug is found the feature is either disabled, and an issue submitted on GitHub to the author of that subsystem, or sometimes, if the schedule is tight enough, it just gets fixed then and there as well.

The release candidate branch is simply all the code that has no obvious error, no bugs that occur every time it is run, etc... Once this code has been tested multiple times, and there is a high confidence level on it's lack of bugs, it gets pushed to the stable branch.


The way we addressed connecting to the robot and to the internet is we reconfigured the robot's router to act as a DHCP server. This allows our programmers to quickly jump between the internet-enabled wireless and the robot, without having to reconfigure their IP settings.


As for a simulator for C++... there is none that I know of. There have been a couple projects that worked on one, such as the WPILib Test Harness (http://firstforge.wpi.edu/sf/projects/wpilib_test_harness).

nyaculak
21-09-2013, 19:42
1. Do most teams use version control, and what do they use?

My team (Team 53) uses git (via Github) to version our code. I've never tried other version control methods but I'm so happy using git that I don't see a need to experiment. In your post you mentioned that your goal was to get more people involved in the programming. Using a version control system didn't really help in that regard (at least for our team). If you look at our Github organization (https://github.com/erhs-robotics) > 99% of the code we wrote was contributed by just two members.
2. Do teams use a build machine, or build server, and what?

We usually upload code directly from our personal laptops. Most of us have our own so it doesn't tend to be a problem.
3. Is there a solution to this problem of connecting to the internet and to the robot network at the same time?
You would have to hook up the router on the robot to the internet. This could be done with an adapter of some kind I suppose.
4. Is there a simulator that can help programmers?
Personally, I don't like to use robot simulators. They really aren't very good. I eliminate bugs by constantly rereading my code and fixing problems that I can detect before uploading.

Joe Ross
23-09-2013, 14:02
Each of our programmers tends to have their own laptop and they each test changes independently. Once each has been tested, changes are pushed to GitHub and merged at the end of the night. One of the more experienced students and I fix conflicts as they arise.

This is the model that we use as well.

Blackphantom91
23-09-2013, 16:28
We have used github and dropbox in the past. As far as getting multiple people working on the same code it eventually goes back to the one computer 5 or so kids crowded around because they normally flock to the main programmer.

As for code retention and version control It took 4 years to get a good system developed that the students actually followed. We just have multiple copies of code in at least 3 different places.

joelg236
23-09-2013, 21:04
Each of our programmers tends to have their own laptop and they each test changes independently. Once each has been tested, changes are pushed to GitHub and merged at the end of the night. One of the more experienced students and I fix conflicts as they arise.


We also do this. It's a really nice workflow for what we do, since it can be very modular. People work on literal features, and we merge these features in nicely.

Some related links:
http://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/workflows