Re: On the quality and complexity of software within FRC
 

FYI, you don't actually need an internet connection to run git. You don't have to constantly connect to some server for every little thing and that's one of its greatest strengths. It's why it's called a distributed version control system.

Also, maybe this is just me but it seems like paying attention to what happens with different forks of code should be the easy part of a software mentor's job.

Re: On the quality and complexity of software within FRC
 

The majority of teams don't have a software mentor.

Re: On the quality and complexity of software within FRC
 

Do you only have one programmer, or do they all share one programming workstation?

Re: On the quality and complexity of software within FRC
 

Neither is necessary. The way git works is that updating the code has two phases: commit and push. Commits are the differences between source files from the previous commit (additions and deletions of lines of code). When you commit, you save the changes locally. When you push code, all the commits since the previous push are saved remotely, and the all of them update. Since you commits are local and pushes are remote, you can commit a number of times while disconnected from the internet, then push all of these commits when you reconnect to the remote server. I attached an image from the Git wikipedia page that visualizes what I said.

Re: On the quality and complexity of software within FRC
 

OK

So, if student A uses computer A to work on fixing bug A; and student B uses computer B to work on fixing bug B; and computer C is used to transfer code into the robot; how do the students'results get into computer C (and shared across computers A & B) (during the scarce time available during a tournament) if computers A, B, and C aren't linked by some sort of LAN? Do the students pass around a memory stick?

I think this is the scenario GeeTwo is envisioning.

Re: On the quality and complexity of software within FRC
 

That would be a little surprising to me. Why do you think that? I would have expected that most teams would have somebody who is a de facto software mentor even if they're not experts.

If most software teams have no adult guidance at all that might be the definitive answer to "what's up w/ FRC code quality?"

Re: On the quality and complexity of software within FRC
 

(emphasis mine)
Yes. When you're at competition without the internet, either one workstation has "all the current code", or none of them do. Things were actually worse for us for much of our existence - we couldn't access github over the school internet connection. I wasn't mentoring programming at the time, but I understand that many pushes (from homes) either didn't happen or had to be "straightened out" later by the programming leads. I understand that individual files had to be transferred around on a memory stick and then forced into git as replacements, which sometimes caused additional headaches. Without a connection, git is still useful as a "time machine", but it doesn't really help distributed development, or at least not within our understanding of how to do it.

OBTW, I don't see the image.

Re: On the quality and complexity of software within FRC
 

Thanks for the nightmare fuel.

The thought of having multiple students on multiple computers fixing robot code DURING THE COMPETITION... *shudders*



All joking aside, I really don't see why that many people need to be fixing robot code during the competition. There really should be one or two people who know everything well enough to fix it. Heck. One or two people can develop most robot code on their own. It's a good idea to have two programmers on one laptop in a coding pair to fix bugs quicker, but more than that you end up having too many laptops and people in the pits.

Re: On the quality and complexity of software within FRC
 

This year, 20 had it's best programming team yet. And they were a team, for once, whereas in previous years we often had one person who did most of the programming on the robot.
We had most functions during teleop that were automated, and advanced controls on our elevator , forks, and drive, and it was exceptional to see them take a less-than-ideal mechanical design and optimize it the way they did.

However, I wish we chose a simpler mechanical design, because there was only so much they could do to fix the robot before returns started to diminish.

I'm generally a fan of making the mechanical design support the programming. Making the programming the easy part. Making the programming be "When the driver presses the button, shoot", and not "When the driver presses the button, activate the aiming system, then shoot".

For example, 20's 2013 robot was built to be as simple a floor loader as possible. We shot from one position on the field, and that was right in front of the pyramid. We had some limit switches hooked up so that when the robot was in position, they would cause some lights to light up, and our drivers knew they were locked in and shot.

However, if your team has more programming resources, they could persue a design with a higher ceiling due to programming, like 195's 2013 robot.

They were a full-court shooter, and they went to Connecticut with a very good full court shooter and won the event with Team 20. At champs, they were faster, more accurate, and could shoot from more places. At IRI, they had perfected their bag of tricks to include shots through the opponent's pyramid and from anywhere on the field.

There is definitely a place in FRC for more complex, elegant programming, but it's not necessary to succeed. Complex programming is a resource, in the same way that sponsorships, machinery, and CAD knowledge is a resource. If you're able to use that resource, that's fantastic for you and your team, you have more options en route to success. If you don't have that resource, you have a limited set of options for success.
I know that in 2016, 20 is likely to lean more heavily on our programming team than ever before, because we know they're extremely capable, but in 2017 we might not.

Re: On the quality and complexity of software within FRC
 

We use SVN for version control and take our server with us to each competition. This allows us to have as many or as few programmers working on code, if needed, as we want. While we don’t make a huge number of changes it does vary from year to year. Mostly we are changing the robot configuration file to change autonomous mode.

Another reason for taking the SVN server to competition is to keep track and store the robot configuration and log files from each match. Our drive team does a commit to the SVN server after each match, and then anyone interested can do an update and immediately have access to the last match configuration and log files.

The students are very capable and able to keep track of using version control. I try very hard to teach them the right way and once they get use to this tool it is one of those things you wonder how you lived without it. Even if you only have one programmer on the team you should be using version control. I tell people it is like having a giant edit undue button. One can revert the files to any previous commit. This is a wonderful feature.

We even have our CAD, electronics, & scouting teams using SVN. Why anyone would not use version control is beyond me. It is not that hard and is a tool every student should have in their knowledge base.

-Hugh

Re: On the quality and complexity of software within FRC
 

I just finished my last year of high school, and have been a programmer for my team during my sophomore, junior, and senior years. I took 2 years of Java courses at my school, including the AP CS exam. We gained our first programmer mentor in 8 years at the start of my junior year, and he was a college freshman at the time.

We've won engineering awards at nearly every single competition (maybe not in one or two of the competitions) we've been to since 2012, which is 8-10. No national champs.

So with some decent experience, I'll ask you a question that may give you some insight on the 'state' of FRC programming:

What is Big O? I've never heard of it.

_______________________________


The fact is - many, many teams do not have any insight to advance programming techniques at all. Many teams don't even have access to the basic fundamentals. For gods sake, this year we started using abstract stuff for the first time. We knew what how it all worked, but we never bothered implementing it.

We are one of the few high schools lucky enough to have programming classes at all. A close friend from another nearby team said his school doesn't have any programming classes at all, and they didn't have a programming mentor for multiple years. I'm not sure if they even have one now, but I know they didn't several years ago. How can you expect kids to figure out these 'standards' when they're teaching themselves basic syntax and struggling to understand the concept of the networking system being used in FRC?

_______________________________


I think there is a very, very large disconnect between mentors on CD and the students on their teams. On some teams - like many in this thread - there are very, very large expectations to meet software and programming 'standards', whereas other teams do not even have the slightest clue on the 'norms' of this stuff.

Sure, you can say 'Get your programming teachers at your school to mentor!' Well, yes. But it's not even that simple. The teachers who teach programming courses here are math teachers and know Java and only Java. Additionally, expecting them to dedicate incredible amounts of time to mentoring is a ridiculous expectation. Mentoring is a LOT of work. We're struggling to find someone who will be able to handle the paperwork we go through each year. We aren't exactly in an area with a booming tech industry, and I'm sure many other teams are in the same situation.

Additionally, many teams struggle with building the robot in the first place. Sometimes teams are lucky to test their bot before week 6 begins. It's an immense amount of pressure to get a robot near fully functional in less than a week.

Re: On the quality and complexity of software within FRC
 

I hadn't either until a few months ago, and I minored in computer science (1984). Back then, we just called it "order of magnitude". It tells you how resources required by a process (usually time) scales as the amount of data being handled increases. For example, a bubble sort is of order n² where n is the number of items being sorted, so "n²" is the "big O" for the bubble sort, starting from an unsorted data set.

Re: On the quality and complexity of software within FRC
 

Teachers are one possible source of mentoring, but so are engineers and technicians.

FRC is quite different from how I think of CS classes are normally taught in high schools. FRC is part realtime, part feedback control, and the remainder being composed of scientific/mathematical/engineering tasks such as cleaning up noisy sensors, building state machines, and mathematical transforms to match mechanical or electrical constructions.

The robots I see within FRC don't have a database, don't draw circles and squares using a turtle, and don't have grids of rocks, flowers, and whatnot that morph over time. Also, the issues that happen on the robot are rarely isolated. "Our robot code has a problem", invariably involves a wiring glitch, mechanical bind, toasted motor, missing jumper, scratched encoder disc, and sometimes a logic or race condition mixed in. This is incredibly similar to the type of SW written by NI customers, the majority of whom are not CS.

So don't limit yourself to computer scientists or computer science teachers.

Greg McKaskle

Re: On the quality and complexity of software within FRC
 

You know Maslow's hierarchy of needs?

Maslow posited that the most basic level of needs must be met until an individual can really focus on higher level fulfillment. This idea has been met with a healthy does of criticism, but I think there is an appropriate FRC metaphor to be made:

Basically, you are only as good as the foundation beneath you. Even if you excel at a higher level in the hierarchy, a deficiency in a lower level will ultimately compromise the effectiveness of the robot and team in competition. Teams that are proficient at all of these things can do pretty well; teams that excel at all of them can do excellently. Teams who write excellent software but can't build a mechanism to save their life are usually not going to fare well on the field in FRC.

TL;DR: Software in robotics is hard because not only is it hard to create good software - doing so is also heavily influenced by every other aspect of a team and robot.

There are very few instances of a robot or team where I've thought, "The only thing holding them back is software quality", so I have to agree with Blake that for the majority of teams, the software meets the requirements (though everything can always be better).

Re: On the quality and complexity of software within FRC
 

Having it all in one place isn't usually that bad if your programmers can program as a group (One guy types, everyone talks about it). It allows for a lot of ideas to be expressed and quickly refined as a group, or rejected when the group thinks up a better solution.

A connection of some sort is always going to be necessary in any distributed work. Git does allow for merging, which can take two branches and unite them together again, and allowing the programmer to resolve any merge conflicts. If you could only push at the school, I would commit freely at home, then push at school.

If this is a serious issue, there may be other version control programs that suit your needs better. I am simply most familiar with Git and its features.

Does this work?