Re: On the quality and complexity of software within FRC
 

Was that last sentence intended to extend the scope ?

"Waste of money" sounds like you are talking about something other than just an FRC robot.

Re: On the quality and complexity of software within FRC
 

Hi Evan. If you've got a couple of minutes, there's some unfinished business over on your "Blown CIM" thread.

Re: On the quality and complexity of software within FRC
 

I'm sorry... what are you talking about?

Re: On the quality and complexity of software within FRC
 

I believe that he may have got the wrong Evan.

Re: On the quality and complexity of software within FRC
 

Re: On the quality and complexity of software within FRC
 

OP wanted to raise the bar for the FRC software quality.

What are some ways to do that without being too preachy (and without getting dragged into the weeds by topics like what-is-the-the-one-true-code-formatting-style, or the-one-true-way-to-use-a-Hungarian-naming-convention?

Publish some reference designs (several... the number of good ways to do things will be legion) that guide students, and lead them to ask good questions about details, but that don't hand them answers on a silver platter? Students are given physical kit-bot parts. Maybe the kit-bot BOM should include some software parts they can put together to form a basic FRC software system (does this already exist?)?

Perhaps put a few good examples of software requirements specifications in the Kit of Parts?

Create simulators (that expose the appropriate APIs) that students can use when their own team's real equipment is unavailable, or during off-season practice sessions, thereby giving them more development time during build season, and more practice time before build season?

Something else?

Blake

Re: On the quality and complexity of software within FRC
 

I'm talking in a more general world than FRC.

Re: On the quality and complexity of software within FRC
 

I've thought about this one a lot through the years, because I think that this is the biggest obstacle to highly functional (let alone high quality) code. Most teams simply don't have enough time with a functional robot to do effective iterative software development with hardware in the loop.

Simulation encompasses a wide spectrum of approaches, from mocking speed controller class interfaces all the way to doing a full dynamics simulation. The former is useful for debugging logic errors; the latter is required (to some level of fidelity) to actually do closed-loop testing of the program. This year 254 did a little of both for developing and debugging our control algorithms and designing our can grabbers (however, our approach was strongly tied to our use of Java...we built a "fake" WPIlib JAR and swapped it out to do simulated tests).

The problem with simulation beyond just mocking low level interfaces is that teams now need a way to specify their robot configuration to the simulation. This is tedious and error prone in most cases, and very difficult to do accurately (e.g. estimating friction, damping, bending, or inertial properties of robot mechanisms is hard). Even professionally, I've watched many PhDs lose hours of work having to debug configuration issues in their URDF files (a common format for expressing robot topologies). The best solution for FRC would be to provide examples for common FRC mechanisms and COTS drivetrains and let teams go from there...but I worry that the complexity gets large so quickly that if a team can navigate that, well, they are probably not the ones who REALLY need programming help.

Re: On the quality and complexity of software within FRC
 

Some brave and enterprising young soul might want to try creating libraries that use JNI to implement these interfaces ... if JNI isn't being used already.

Re: On the quality and complexity of software within FRC
 

They are all JNI. The issues come from not being able to pass by reference, so passing structs, such as the ones used for vision, still has trouble even with the JNI.

Some of the things that I know are fine, but still make me cringe, involve the use of generics and enums. Since Java on the CRIO did not support either of these, most of the Java code doesn't have them. However, you can tell that some of the new classes do use generics and enums. I know this is fine, but you can tell there is a disconnect between the old and the new code, and something that would be nice would be for somebody to take a month and thoroughly clean it up. I bet with some cleanup to include new features, and maybe some algorithm refactoring, we could get the code much nicer and easier to work with. Maybe they could fix all the spelling and punctuation errors in the comments too :D

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.