On the quality and complexity of software within FRC

[Pault]

I can agree that compared to the CD ME community, the CD programming community really does not do nearly as good of a job at encouraging and helping teams improve their code beyond just making sure they understand the fundamentals and their code works. There is very little talk about making code flexible, or features that could be added, etc. All of the threads are something like either "What programming language should I use?", "Where do I go to learn how to code in X language?", "Why does this code not work?", "What is a PID?", etc. I think it could really benefit the teams on here if there was more in depth conversation.

Your being very harsh on the average team, though. Just like with mechanical and electrical, the goal of many programming teams is just to "make it work well enough for us to get picked for eliminations." Many of them dont even have a coding mentor, and rely pretty much exclusively on the resources online to figure out how to write basic code. I don't think we need to be criticizing them because their code is not as robust as we would expect from our own teams, they are struggling to get it to work at all.

[kylestach1678]

Originally Posted by Pault

I think it could really benefit the teams on here if there was more in depth conversation.

This is very true. Only a very small portion of CD contains anything related to programming, and of that, as you said, very little is anything more than stack overflow-style "why does this not work" problems. It would be fantastic if there was more discussion on CD about the fantastic code that some teams have created such as 971's control code, 1706's and 900's vision programs, and 254's motion planning to name a few.

[Ari423]

I'm afraid I have to agree with OP. I am the head (and only) programmer on my team, and have been so for the past 3 years, so I have a lot of experience with programming for FRC.

I will be the first to admit programming is hard to do well, but I think some teams just aren't putting enough effort to make their code efficient. Just today on CD I saw a piece of code (which I will leave unnamed) that almost brought my eyes to tears in its inefficiency. Even without a programming mentor and with a 6 person team, I have always put an emphasis on code efficiency and design as well as effectiveness. Sometimes I feel as if the FRC community has taken all of the focus from programming and moved it to mechanical, and left programming as an afterthought: something that you just throw together in a few hours to make it work and then never look at again. I understand that there are multiple ways to do a single task, but some ways ARE better than others.

A good example of this is dashboards. I cannot speak to programming a Java or C++ dashboard, but I know that making a dashboard in LabVIEW is easy to do, relatively speaking. Every year, after I finish the robot code and control panel, while I am waiting for the robot to be ready to test on, I program a dashboard that shows the important information coming from the robot, and adds other inputs than those on the control panel (trims, resets, etc). It usually looks something like this:

It doesn't take long to make, makes debugging much easier, and generally looks nice. We don't always use all of the displays, but they is at least one display for every aspect of the robot code. However, I often see much larger and more advanced teams who use LabVIEW but either don't have a dashboard, use the default dash, or make a custom dash with only a few numerical outputs. I don't understand; maybe someone can explain this to me. With the customizability given to you, why not make a dashboard suited to your needs that is easy to read and looks nice?

tl;dr Why is programming becoming an afterthought in the FRC community?

[connor.worley]

IMO once your code works, you get more diminished returns improving it than you do improving your mechanisms. Efficiency doesn't really matter because there's no requirement to scale.

Requiring teams to submit their code to the judges for review might fix this, but I don't know if the volunteer capacity exists.

[Brian Maher]

Originally Posted by connor.worley

Requiring teams to submit their code to the judges for review might fix this, but I don't know if the volunteer capacity exists.

I think this has a lot of potential as an optional submission, but require it to be considered for the Innovation in Control Award, like how a Business Plan submission is required for the Entrepreneurship Award.

This year, I had our team's programmers assemble a document including the code, with full comments, and some flowcharts and rationales. It helped them better understand their decision making process, realize its advantages and weaknesses, and identify ways to improve. It's also nice to have another deliverable for judges.

P.S. getting programmers to document their work can be difficult.

[sforsyth]

You most likely have not worked in the real world... ahhhh to have a fresh college mind where everything is perfect and there is plenty of time to make everything perfect and just the way *I* want it

There are others that have said it in this thread I'm sure... the perfect code is whatever you think it is, your perfect code is not necessarily mine. If it works, then it is probably perfect to the person that wrote it.

Most of these kids are brand new to programming and it is better served just to learn the language, leave the perfection to College courses if that is what they decide to go into.

That being said, I'm sure there there are many ways to help them learn to write clean code and that really should be what you are asking... how can we help the kids?

[faust1706]

Originally Posted by sforsyth

You most likely have not worked in the real world

This is my second summer interning as a software developer. The code base is cleaner than anything I have ever written and it is highly organized. Extremely navigable, highly commented, and the code you submit has to get approval from your ENTIRE team before it gets pushed. The company deals with massive amounts of data for analysis. Optimization is the name of the game. More functions than not have their corresponding big O with it, and many have big theta as well. Anyways, irrelevant.

Originally Posted by SoftwareBug2.0

I agree there's a lot of poor quality code in FRC and little higher-level discussion.

A lot of high schoolers do poorly with programming

Studies suggest that roughly 40 percent of people aren't even capable of learning to program. Just look at the fizz bizz test. Really good read.

Originally Posted by gblake

I am surprised by how few people have challenged the OP's assertion that I'll paraphrase as "most FRC software stinks"; and by how many respondents seem to embrace that assessment.

First agree on what you want a given collection of software to do and be. Then have a proper conversation about quality.

Because it is the general consensus it seems. I did expect some backlash. While robots vary greatly year after year, the software generally does not. I forget where I read this, but it basically said that software is not considered good if it isn't able to adapt to an unforeseen use of it.

Imaging if google crashed when you tried to find a route from london to toyko,

Making adaptive code is something that needs to be a goal from the start, not an after thought.

How about we all just real Zen and the Art of Motorcycle Maintenance and call it a day in regards to a conversation of quality?

Originally Posted by SoftwareBug2.0

Reading code is not very fun.

I love reading code, especially elegant and concise code. I think I'll make an off season "competition" of a code standard challenge from the team's code this year. I'll begin working on the details tomorrow with a friend and anyone else who is interested.

[gblake]

Originally Posted by faust1706

Because it is the general consensus it seems. I did expect some backlash. While robots vary greatly year after year, the software generally does not. I forget where I read this, but it basically said that software is not considered good if it isn't able to adapt to an unforeseen use of it.

Imaging if google crashed when you tried to find a route from london to toyko,

Making adaptive code is something that needs to be a goal from the start, not an after thought.

How about we all just real Zen and the Art of Motorcycle Maintenance and call it a day in regards to a conversation of quality?

Whether or not a general impression about low-quality exists, what is probably more important to think about is whether or not it is accurate.

The notion of adapting to unforeseen use is interesting to ponder. What does it have to do with software that isn't required to adapt to unforeseen circumstances? In that circumstance creating adaptable software is a waste of resources.

I read that book long ago. No need to repeat that.

Instead why don't we discuss what our software is supposed to do and be *before* we decide that it is a failure. The software development industry is no stranger to the importance of putting a good specification in place early.

I understand your thesis; but I don't think you have proven it. Until you can put together a good argument that the majority of FRC Software doesn't satisfy teams' requirements, put me in the camp that both says there is always room for improvement, and says that a general indictment is unwarranted.

[gblake]

Help me out folks, if a team's software isn't made public, isn't it supposed to be rewritten from scratch every year?

And even if all of a team's software is made public from year to year, isn't the general notion of the annual FRC learning experience that software, like the physical robot, will be largely developed anew, during the season, each year?

I realize that there is a broad spectrum of ways teams actually do their software development; but isn't the clean sheet of paper, plus some true off the shelf code, sort-of the big picture thrust of the rules?

[Necroterra]

Originally Posted by gblake

Help me out folks, if a team's software isn't made public, isn't it supposed to be rewritten from scratch every year?

And even if all of a team's software is made public from year to year, isn't the general notion of the annual FRC learning experience that software, like the physical robot, will be largely developed anew, during the season, each year?

I realize that there is a broad spectrum is ways teams actually do their software development; but isn't the clean sheet of paper, plus some true of the shelf code, short-of the big picture thrust of the rules?

I'm pretty sure that you are right and all reused code is supposed to be public. I think a lot of teams throw it on their website or a github repo, but it isn't under a easy to find name. However, it is also really hard to enforce this rule and it usually isn't that big of a deal, so it gets ignored as far as I know.

I don't see why you would ever start completely from scratch - things such as path planning, vision code, state machines, interfaces, dashboard tools, etc. can be developed and refined over years, and generally can't be done well in 6 weeks. Re-deriving your algorithms every year might be a learning experience, but it won't teach you as much as refining and expanding your codebase will.

I think that there are some situations where following this rule and being an effective FRC programmer don't necessarily align. Here are a few theoretical examples where the rule is technically broken.

1. I wrote a spline generator in the offseason / last year, and copy pasted it into my project this year without putting it on Github. This is technically against the rules, but at least the student is still learning.
2. I had my friend / parent / mentor give me a spline generator they wrote for college, and copy pasted it without making it public. This is bad, since you neither shared it nor wrote code yourself.
3. I opened my code from last year, and used it as a reference for how I did certain things such as getting joystick inputs. This to me is fine, since while you might retype certain lines verbatim, a single line or method call barely counts as code - in this case, really you are just not having to look things up in the documentation as much.

I love reading code, especially elegant and concise code. I think I'll make an off season "competition" of a code standard challenge from the team's code this year. I'll begin working on the details tomorrow with a friend and anyone else who is interested.

I would love this, so would it be like you provide a description of the robot and it's sensors / components, and people submit code that should make it run?

[artK]

Originally Posted by gblake

Help me out folks, if a team's software isn't made public, isn't it supposed to be rewritten from scratch every year?

Yes. The rules usually state this fairly early on in the manual. I think Frank even made a post telling teams this rule early so people would publish it.

And even if all of a team's software is made public from year to year, isn't the general notion of the annual FRC learning experience that software, like the physical robot, will be largely developed anew, during the season, each year? I realize that there is a broad spectrum is ways teams actually do their software development; but isn't the clean sheet of paper, plus some true of the shelf code, short-of the big picture thrust of the rules?

Yes, new software is supposed to be written each year. The real question is what new software needs to be written. A number of teams, from my general impression, will start essentially from scratch each year. I believe this may contribute to the problem. Since most teams don't/can't reuse the code from the previous year, they have to start from what they know, and usually without help. It's like asking a designer to CAD up a drivebase who doesn't necessarily know what goes into a drivebase. Yeah, it might work, but it's probably really heavy, slow, and doesn't turn well.

By comparison, other teams will reuse the framework from the previous year, and adapt it to the new robot. It's like starting the season with enough COTS parts to build a drivebase, and the parts increase in quality and quantity each year. Is it ready for competition? No. Does it save development time, allowing programmers to work on other things? Yes. Is their an easily available framework for teams to use? Not really, at least not now. You could borrow code from teams like 254 or 236 who post their code every year, or try and use the scripting languages I've seen 1902, 987, and 4334 post (I think those teams have did that in the past).

[artK]

I've also given the quality and development of FRC controls and software a fair bit of thought. I have also thought for a while about the amount of software discussion versus mechanical, strategic and even business discussions on Chief Delphi.

I think part of it has to do with the lack of robotics programmers, both on CD and in the FRC community as a whole. A lot of teams don't have dedicated software mentors, who can teach the students the principles of software engineering (especially design patterns which allow for easily expandable code), and control theory (at the very least some feedback control, but the more the merrier). Most teams would be lucky to get a computer science teacher who generally teaches the basics (which are important, but doesn't necessarily lead to good software design). This leaves the upperclassmen, who may not have years of programming experience joining the team, to teach the lowerclassmen, with leadership changing every year or two.

A reason for a lack of mentors with experience in robotics software may be due to the lack of exposure of computer science and software engineering students to the field, usually until grad school or dedicated robotics programs like WPI or Waterloo have, which don't have a huge output of people. And the difference between robotics software from what CS and SE students typically work with that plunging in head first is intimidating enough that they never give robotics much thought.

Additionally, I bet a lot of students use other websites not only to help debug their code, but to copy and paste code from a website, which doesn't lead as much learning. I would like to see somebody try and copy/paste a CAD model.

[MikLast]

Originally Posted by arimb1999

I don't understand; maybe someone can explain this to me. With the customizability given to you, why not make a dashboard suited to your needs that is easy to read and looks nice?

Maybe the only thing you really need is three auto buttons.
(that's all we needed. the driver station console gave us everything else we needed.)

[cjl2625]

Originally Posted by arimb1999

I'm afraid I have to agree with OP. I am the head (and only) programmer on my team, and have been so for the past 3 years, so I have a lot of experience with programming for FRC.

Yup, exact same for me.

Most of our code for this year is pretty gross, which is probably a result waiting for the mechanical team to make something, and then me scrapping together something that makes it move. There's plenty of automation, but it's perhaps not the most efficient.

In general, it's just rushed through to make something that works. I usually don't improve it, perhaps because I'm afraid of breaking the code, and then getting yelled at by those darn wrench-swinging monkeys of the mechanical subteam (). But mainly it's a result of time. I'm usually so busy that it's not really worth my time to make these improvements that won't really have a worthwhile effect. Perhaps if the programming team was more than one person, it would be more manageable to produce beautiful, efficient code.
I'm determined to expand the programming team for next year, so we'll see what happens with the code then.

Though over the summer, when I actually have time, I do like to reiterate some of the code that may be used in the future. I've remade our swerve drive code a few times, and now it's significantly more efficient and organized than the original version. And I know there's still room for improvement, which I'll try to tackle this summer.

[faust1706]

Sorry for lack of quotes, on mobile. The blame is also on us. My mentor had me calculate the big O of every algorithm I designed, and he questioned every algorithm design I had. If I didn't have a well thought out answer, I wasn't allowed to use it. We've been using that code base ever since, haven't changed a line of it, and it has been able to adapt to the 2013 game, a 3 camera system in 2014, and 3d imaging this year.

Part of our partnership with nvidia will be promoting good code in the community and getting people excited about programming. We thought of the idea of hosting a class at worlds, but we feel even if we had it, not a lot of people would show up.

I do not have a solution to this deeply rooted problem as it ultimately comes down to each individual team. Addressing it as a problem is the first step. Another idea we had with nvidia is to have an award for quality of source code, teams that want to be a contender would submit their code online before competition began.