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