Re: On the quality and complexity of software within FRC
 

Interesting. The C++ version always gave me the impression that it was written by someone who really wanted to be writing Java.

Re: On the quality and complexity of software within FRC
 

That's funny, because I always get the impression that the Java libraries were written by a C++ developer.

Re: On the quality and complexity of software within FRC
 

Pretty common in embedded environments.

Re: On the quality and complexity of software within FRC
 

We're working on it. Among other things, we've also removed three nested while(true)s with no delays, and the notorious error message that swears at you.

Re: On the quality and complexity of software within FRC
 

I would love to see this when you guys get done, or close to done. Maybe some of the fixes would be useful in the other ports as well.

Also, which nested while loops? I haven't noticed any that have caused issues so far, but maybe I just don't remember. I've read too much code lately.

Re: On the quality and complexity of software within FRC
 

It could be both :). For best results, assign someone good at Java to do the Java version and a C++ expert to do the C++ version. For "interesting" results asssign the Java guy to do the C++ and a C++ guy to Java.

Anyway, here are a few of the reasons that the C++ looks like somebody wanted to write Java:
-Pointers to stuff passed around without specific notes about ownership
-Abstract base classes used like Java's interfaces in places where templates might be more appropirate
-Virtual fuctions overused
-Types that can't be used like normal C++ variables because they don't have copy or assignment operators the rule rather than the exception

What C++isms do you see in the Java version?

Re: On the quality and complexity of software within FRC
 

Underscores, underscores everywhere.

Re: On the quality and complexity of software within FRC
 

Whats also great about the WPILib is that whenever you initialize a digital port, delete it, and create a new one, the HAL leaks 6 bytes. Now since many teams don't do this, its not a big deal, but still, its a little odd that an official program has a memory leak, even if it is such a small rare one.

Re: On the quality and complexity of software within FRC
 

Has anyone run valgrind, or something similar, on as much of the WPILib as they could?

Re: On the quality and complexity of software within FRC
 

I don't how much people have tried it but the version from here has a static assert that's basically sizeof(void*)==sizeof(int32_t).

Re: On the quality and complexity of software within FRC
 

Note that at the HAL level, freeDIO() is the opposite of allocateDIO(), and not the opposite of initializeDigitalPort(). The initializeDigitalPort function allocates the memory you're talking about, and was only intended to be called once (ever) per port, with the caller being responsible for saving the resulting pointer across multiple uses. The lack of an uninit function to free the memory in question is admittedly poor API design, but it's worth noting that the higher level WPILib classes use the HAL consistent with the above (call init once, then just use allocate/free), and thus have no memory leaks in this case even if you create/destroy multiple times per port.

I've found that the WPI folks are very welcoming of patches... I'm sure a patch to add appropriate uninit functions to the HAL would be accepted in short order.

Re: On the quality and complexity of software within FRC
 

However, if you don't keep the same digital input, and instead go new, it does initialize a new digital port. So calling
Talon t = new Talon(0);
t.free();
t = new Talon(0);

Leaks the memory. Because InitDigitalPort always returns a new digital port, instead of reusing an old one. At least on the java side. And t.free() does not actually release the digital port structure.

I have a few bugs I plan on submitting to WPI that I have found.


I do want to say thank you for doing the python port. I have been able to use that for some help as well, and am implementing the DotNet simulator to use a dictionary similar to the python one, and it should be directly compatible with the websim api.

Re: On the quality and complexity of software within FRC
 

Before is slips off of everyone's radar for good, I thought I would give this thread one more poke.

Re: On the quality and complexity of software within FRC
 

After thinking about this more, I'm not sure if it's even a problem. I've never expected FIRST to take in a bunch of kids and spit out seasoned engineers. The main goal is just to get them to check a STEM box when they're choosing a major for college. So let the enthusiasts develop as much as they please, but I think the average experience is already pretty good as far as accomplishing FIRST's goal goes. Just getting a joystick to control a motor is pretty exciting for most people.

Re: On the quality and complexity of software within FRC
 

Agreed.

Hello worl...AHHHH!!! It's out of control! Jane, stop this crazy thing!

Re: On the quality and complexity of software within FRC
 

I think its great if my students develop advanced programming and controls. Its a great thing to learn and can be incredibly inspiring to see the robot perform amazing functions on the field that would be impossible or very difficult otherwise.
However, if I have a few students who go from no programming experience to some programming experience, and this makes them want to pursue it further, thats just as good to me, if not more in the lines of FIRST's goals.

I do, however, wish I knew how to keep a large programming team engaged (and perhaps thats the topic for another thread), as its difficult to let every programming student work on robot code when you have a large team.

Re: On the quality and complexity of software within FRC
 

I think that falls under inspiration. Last time I checked, it was one of FIRST's goals.


Perhaps this recent thread?

Re: On the quality and complexity of software within FRC
 

Honestly, games where autonomous has tiered rewards that are actually worth something and that are not penalized for attempting them.

2015 - Pretty terrible, the only task you could accomplish on your own was REALLY hard. The other tasks all required your partners to also do something. (I don't count can burglaring as an auton task)

2014 - Almost good, the penalty for attempting to score a ball was pretty harsh though.

2013 - Great. 0 penalty for attempting to score in any of the goals. Even drive forward and dump 2 in the low goal was viable and provided a reasonable reward. And the reward -> difficulty scaled appropriately to even the upper tier.

2012 - Scoring was MUCH harder than 2013 so meh.

2011 - Most teams struggled to score, let alone scoring uber tubes autonomously.

2010 - Literally 0 point.

2009 - There was a game?

2008 - Great. Even just driving forward was worth points, bonus points if you could turn at the end of it.

2007 - See 2011 only strike the word uber

2006 - See 2013

2005 - meh, not a whole lot of teams attempted it. Vision was REALLY hard.

2004 - Very few teams attempted to knock off the balls. But a lot of folks prepped for teleop, kinda decent but not really.

2003 - Robot Demolition Derby isn't really a good auton, sorry.


If teams have a reason to write good code they probably will write some. But if they are penalized for attempting auton teams will just pass because the risk is not worth the reward.

Re: On the quality and complexity of software within FRC
 

I consider canburgling an auto task- THAT WAS STILL REALLY HARD, especially if you wanted to do it at more than a regional level.

2012 autonomous was just as good as 2013 IMO, because scoring low baskets was easy, and worth 4pts/score (vs 2013's 2 pts/score), and feeding balls into a partner was another great autonomous task that was easy.

2014 would have been perfect as well, were it not so punishing to miss autonomous.

Really the GDC has gotten autonomous right 3 times. 2008, 2012, and 2013.

I think 2012 was the best year for programmers. Improved controls turned into improved results for most teams. Improved autonomous was valuable, and there were effective tasks to do for teams at every level, programming-wise.

Re: On the quality and complexity of software within FRC
 

Definitely agree. That year was the holy grail of good game design, a nice correlation between automation difficulty and point return, and the tools to make it happen. The robot code I wrote that year is one of the few things from that long ago I'm still proud of

Re: On the quality and complexity of software within FRC
 

I'll throw out my 2 cents for what I think is the main thing that holds back the evolution of programming on a team:

Getting a mechanical system to the base state of "it works"(regardless of how well) takes a lot more effort and time then programming does. By that I mean that code changes can be done quickly and efficiently with minimal peoples' effort and mechanical changes often involve a team of people machining, bolting, cutting, lifting, etc. This may sound like programming could evolve quickly but what usually happens is that mechanical issues take precedence in the design process. When engineers are making a big modification to a mechanical part they often like to keep all other variables static. Which means programming changes don't go through if the mechanism still needs to be tested out / modified.

Once the code "works" it can be hard to justify changing it when you know that you are already sinking time into changing mechanical or electrical systems.


A good way to avoid these situations are to ensure that your programming team has an adequate testing environment so that code can evolve in isolation from ever changing mechanical parts. Set up a branching model so that you can give the mechanical folks a working build and then continue to develop in parallel. This is one of the things we strove for this past year and it, I think, made a big difference in the quality of our code.

Re: On the quality and complexity of software within FRC
 

What effects would this change to the rules have on software quality?

I purposely left out fixing the robot in the new language.

Re: On the quality and complexity of software within FRC
 

I'm only going back to 2012, as befits my team's experience:

Apart from the mobility bonus "gimme" in 2014 (really? drive across a line?) I thought that 2012 and 2014 were nearly identical. You got bonus points for scoring in hybrid/auto. If you miss, you have to pick up the ball again to score it for no bonus. And while the two years of experience certainly helped, scoring unopposed in AA seemed a lot easier than in RR, both high and low.

2015 was the only one that failed to reward incrementally, and the number of things that could go wrong caused a number of teams (including mine) to decide that none of our routines was worth the risk. I am surprised at how many teams did NOT have a "drive into the auto zone" auto. Granted, it was only three points, but it was essentially the same as the mobility bonus in 2014, and it seemed like the great majority of teams did it.

I do not consider canburgling as an auto task, but I can see the point - it was a scarce worm that went to the early bird. The two reasons not were that it was not rewarded directly because it was autonomous, and (more importantly) most of the canburglar programming was a single actuator with no sensor feedback. That is, it was best solved as a mechanical problem, not an automation problem.

I don't recall Rebound Rumble this way at all, but I wasn't mentoring yet. As I recall, if you didn't do the kinect (and I saw few teams that did), you had either very easy (score preloaded balls; tip one bridge) or rather hard tasks (both; tip multiple bridges; pick up balls and score them) in auto/hybrid. Please expand on this.

Re: On the quality and complexity of software within FRC
 

If teams can't fix the robot (or even effectively troubleshoot wiring, which usually amounts to the same thing), they won't be able to operate it to test software once something breaks. If the rule is actually followed, it would have about the same average effect as moving bag and tag back to 12:15 am on Wednesday.

Re: On the quality and complexity of software within FRC
 

The big difference cor 2014 was that unscored auto balls could NOT have ASSIST points applied to them which was the primary means of scoring that year. So if you missed an auto shot (or 3) you then needed to clear those balls before you could start scoring points in the range that your opponents could. You lost valuable cycle time to playing cleanup for a relatively meager amount of points.

Re: On the quality and complexity of software within FRC
 

In Rebound Rumble during auto, you could:
Feed a partner balls
Score low goals
Score middle goals
Score high goals
Grab the two balls off the side bridge and shoot those as well
Grab the two balls off the middle bride and shoot those as well

In Aerial Assist, if you missed balls, you couldn't score during teleop until those balls were scored. Also, in 2012 if you missed, you could score those balls from the key during teleop, where opponents couldn't defend you, where in 2014 you got rammed if you tried to pick up your misses.

Re: On the quality and complexity of software within FRC
 

Before the season, that's what I expected. The actuality was that most of our matches seemed to devolve into one robot on offense and two on defense on both sides; no assist points, and few truss shots. It was really disappointing seeing how poor many teams' ball pickups were.

I only recall one time where we had to chase a wayward auto ball for more than a few seconds. Our pickup roller was somehow still in the track of our launcher; it started upright to be within the frame perimeter. The ball went backwards (not quite a reverse truss shot). If it had happened in teleop, the effect would have been the same.

I guess if you had a low percentage auto, it was not worth loading them at all in 2014, or stuffing them in the low goal. If you were much over 60%, the risk was more than justified. And even a box on wheels should be able to a score a low goal auto pretty consistently.

OK, I missed that. I don't remember passing balls between robots being illegal, but I don't recall it ever happening, either. Or is this something else?

This was a difference in teleop, not auto. The key was protected whether the balls you were carrying had been preloaded in the robot (or if you didn't have any balls). In both games a loose ball was a loose ball, whether it was initially loaded in the robot; in RR it was available but not a liability, and in AA you couldn't get another ball until you scored it. The "opportunity cost" of missing a shot was usually the same whether the shot was taken in auto or teleop in both games.

Re: On the quality and complexity of software within FRC
 

Did you watch 2014 Einstein Finals-2?
Missed autonomous shots caused the 254-469-2848-74 alliance to lose a match because of how long it took them to re-score those missed balls. Whereas missed autonomous balls on Einstein in 2012 didn't mean you automatically lost the match.
What this meant was that if you messed up auto at most events during eliminations, you lost the match.

As for feeding balls to partners in 2012, 4334 did it throughout Archimedes Eliminations, as well as on Einstein. 20 did it as the third robot of the Connecticut Regional Championship alliance.

Basically the problem with 2014 autonomous was that letting your partner run their autonomous routine was a major liability if they failed, whereas in 2012 and 2013, missing auto shots just lost you that autonomous score.

Re: On the quality and complexity of software within FRC
 

no, I admit that after Bayou I lost interest.

Was this only in eliminations? Was the ball passed on the floor, or was there some sort of hand shake? Honestly, I was surprised more teams couldn't to a bumper-to-bumper or short pass ball transfer in Aerial Assist where you could effectively score 10 or 20 points each time you did it; it's nice to know that some teams did this in a game that didn't directly call for it.

Re: On the quality and complexity of software within FRC
 

The two ways I saw ball passing occur in 2012 was either on the floor (through the shooting robots intake) or a light toss into the shooting robots' hopper if they had one. I know 3322 did it very early in the season.

Re: On the quality and complexity of software within FRC
 

Minimal, at best, and it might actually make it worse.

As pointed out, no fixing (or other electro-mechanical work, presumably) would be allowed, thus as soon as something broke, no further testing of software could be done.

But... most upgrades of software tend to work with (and follow after) upgrades in hardware. No upgrades in hardware mean software doesn't need upgrading.

And there is one other item that I can see happening. This is why I think it could become WORSE code, not better.

--A team could, theoretically, upload a base code right before the bag that has driving disabled, make one upgrade (enabling the drive code), and spend the rest of the allowed time "testing the upgrade"--which to everybody else is "driver practice". As a side note, a good, practiced driver can often do at least as well with lousy code as with good code--just a touch of compensating needed maybe.

Re: On the quality and complexity of software within FRC
 

Interesting that your experience with AA was entirely the opposite of mine. What I saw was teams all contributing in some way offensively, then contributing in some way defensively when they completed their offensive job for that cycle. What I also saw was teams doing their best at every level of play to keep opposing alliance members away from their auto balls. (see: Crossroads, Einstein finals, IRI) I also saw lots of boxes getting caught on walls, or just not moving at all in auto.

Having worked with 548's brutal can pullers, I can attest to the fact that the fastest (or at least some of the fastest) did use sensors. A potentiometer was used do detect when the pullers were all the way down, so they would move forward as fast as possible.

As for the quality and complexity of FRC code, I think we can all agree it'd be great to teach great programming. It'd also be great if more teams actually did great programming. Yet, ultimately, we have the kind of hardware that allows us to be sloppy, libraries that are poorly made themselves, and generally diminishing returns for making code more efficient. Great code can be made in FRC and it can have good returns, but unless you have everything else about your robot down to laser-precise perfection, there's probably something else that could be made better more easily, whose returns would scale better with the effort you put into it. For the sake of inspiration, have at it because programming is vital to our future generation of engineers. However, for the sake of making a consistently successful team, there is often something that will give greater returns for less effort.

Re: On the quality and complexity of software within FRC
 

Programming spent hours tuning our canburglars to be the fastest they could possibly be, and still be accurate. At FiM Livonia we probably won the can battle against 503 because they had a programming issue that caused theirs to be deployed a quarter second slower then they should.

Re: On the quality and complexity of software within FRC
 

As a novice on this website, I have never really drawn an interest until I saw this thread. This is been one of the most interesting threads I've seen anywhere.

Now, as I have now been a programmer for FRC for two years, I think I might be able to offer some observations on this subject. On the Mechanical/Electrical opinion, they are absolutely correct. Small mechanical changes can absolutely make a huge difference, from flipping cans on your mentor to stacking 3 6-stacks capped in a match. However, this change won't be any good if the code is inefficient for the driver. Sometimes, automatically doing multi-step tasks can reduce your time at the feeder by 10 seconds a stack. I think part of the reason programmers get so restless and irritated by mechanical is the fact that it takes about 2-3 weeks to finish the first iteration of the code, but 12 weeks to make a robot mechanically ready for champs. Programmers maybe get one hour a week to test on a robot, but what about the other 20+ hours? This seems like a major issue for our programming team. More people need to spend time working on extra-robot programming. I spent the entire season working on our scouting application, and I must say that it was one of the best programming experiences I've ever had.

tldr everything part of making a robot necessary, programmers need things to do when not testing.