On the quality and complexity of software within FRC

[Ether]

Originally Posted by notmattlythgoe

I'm saying that you shouldn't be spending a bunch of extra time optimizing loops and building adaptable code with the assumption that you'll need that optimization or need to adapt it in the future. In most (not all) cases it will be a wast of time and money.

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.

[Ether]

Originally Posted by evanperryg

...

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

[evanperryg]

Originally Posted by Ether

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

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

[kylestach1678]

Originally Posted by evanperryg

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

I believe that he may have got the wrong Evan.

[evanperryg]

Originally Posted by kylestach1678

I believe that he may have got the wrong Evan.

yep, found the other evan...

[gblake]

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

[notmattlythgoe]

Originally Posted by Ether

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.

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

[Jared Russell]

Originally Posted by gblake

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?

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.

[gblake]

Originally Posted by Thad House

This is a very true fact. You can tell the Java libraries for this year were rushed to get finished in time. Also, some of the hacks needed to interface with the native c++ code for the FPGA just look like they could cause more issues. This is the same thing that causes the vision libraries to be slow. It wastes alot of time marshalling the structs between java and c++, and this looks to be what is so slow. We've been trying to alleviate alot of these issues in the DotNet port, and its easier since working with native code is easier, but its still a challenge trying clean up the code to make it faster, yet keeping it running the same code.

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.

[Thad House]

Originally Posted by gblake

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.

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

[SoftwareBug2.0]

Originally Posted by evanperryg

We've begun to encounter the issue that WPIlib for Java is poorly coded itself. The libraries relating to vision code are particularly messy. This may be why so many teams opt to build their own libraries entirely. ...

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

[notmattlythgoe]

Originally Posted by SoftwareBug2.0

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

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

[wireties]

Originally Posted by notmattlythgoe

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

Pretty common in embedded environments.

[evanperryg]

Originally Posted by Thad House

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

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.

[Thad House]

Originally Posted by evanperryg

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.

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.