How does your team incorporate engineering units?

[Greg McKaskle]

I'm hoping to get feedback on how teams are already managing engineering units within their code.

Several of the languages used in FRC can provide compile-time checking to verify that units of distance and velocity, for example, are not combined incorrectly within your code. The upside is that you have a compiler watching your back as you make algebraic statements in your code to update an actuator. The downside is that compilers are sticklers and your code may actually become harder to read, or the points at which you connect to WPILib, which doesn't use units, may just become littered with casts and such.

Is anyone using unit features within the languages or libraries? Do you have another system that you've adopted?

Greg McKaskle

[rsisk]

Didn't even know this feature existed.

[hzheng_449]

For one, my team (we use LV) does not use this unit feature.

To begin with we weren't aware of the feature at all. (Though most of the senior coders have some cpp experience and know how typedefs can be used in cpp)

Also, I don't think it's likely we'll use this feature in the future. My personal opinion is that all our numerical data should be the same data type (ie doubles or rather the LV equivalent.) This makes life easier when coding and debugging since we don't have to cast everything which means 1) the code is less cluttered 2a) We can use LV and WPI libraries more easily since they all take standard numerical inputs 2b) We can ensure our own utility Vis will function for multiple modules of code (which may be using different units)

Moreover, the feature seems to be more of a crutch than a solution. Unit confliction can easily be solved with good planning, sanity checks, and testing.

;tldr: we haven't heard of it before, and we probably wont use it since it's easier to code w/o and the issues can be solved with good coding practice

[sdaustin]

Originally Posted by hzheng_449

Moreover, the feature seems to be more of a crutch than a solution. Unit confliction can easily be solved with good planning, sanity checks, and testing.

;tldr: we haven't heard of it before, and we probably wont use it since it's easier to code w/o and the issues can be solved with good coding practice

I suggest you research the Mars Climate Orbiter for a good example of how a seemingly obvious bug can slip through the cracks, with catastrophic results, in spite of having some of the best & brightest programmers and most stringent QA processes.

[Ether]

Originally Posted by sdaustin

I suggest you research the Mars Climate Orbiter for a good example of how a seemingly obvious bug can slip through the cracks, with catastrophic results, in spite of having some of the best & brightest programmers and most stringent QA processes.

The implication of the above being that not only would that problem not have slipped through, but also no other problems would have been introduced by the harder-to-read code which is littered with casts:

Originally Posted by Greg McKaskle

The downside is that compilers are sticklers and your code may actually become harder to read, or the points at which you connect to WPILib, which doesn't use units, may just become littered with casts and such.

In the absence of a sizable independent controlled study of both approaches, no definitive conclusions can be drawn.

[sdaustin]

Originally Posted by Ether

The implication of the above being that not only would that problem not have slipped through, but also no other problems would have been introduced by the harder-to-read code which is littered with casts:

That's not what I was trying to imply. My point is that people are imperfect. All software has bugs. Using sound software engineering practices to expose them as early in the development cycle as possible is a Good Thing. Ultimately it's a tradeoff of time/cost for QA vs. anticipated impact of a bug that slips through the cracks.

In the case of the Orbiter, the integration testing obviously didn't include the test case that would have exposed the unit mismatch - or the verification side of the test wasn't properly written, or nobody looked at the results, etc.

Would stronger type/unit checking native to the compiler(s) have caught the problem? Would programmers have "fixed" the compiler warnings/errors by littering their code with typecasts to make them "go away", thereby making the coder harder to read/maintain - and possibly causing this exact bug to slip through anyway? We'll never know.

[Ginto8]

Our team's codebase is mostly devoid of values that would be in physical units anyway. Generally, we code to what our sensors provide. Instead of measuring out a path, calculating the number of rotations, then the number of encoder ticks that would take, we take the robot, zero the encoders, and run through the path, recording their values directly. I distrust any assumption (at least in the FIRST timeframe) that a quantity defined in physical units can be cleanly converted to a value from the robot's sensors. If we had the time to create a proper simulation, then perhaps I would use real-world units more, but since our only platform is the robot, we use the values directly from the robot.

As an example, we have this class which allows us to do motion planning from teleop mode. Map this command to a button, and it prints out the lines of code to put into the autonomous mode, using the values from the sensors directly.

[Joe Ross]

We typically convert sensor values to a physical unit, if it makes sense to do so. For example, we convert our drivetrain encoders to feet. However, we only use that unit (easy to do on a small development team, harder to do on a large development team that spans multiple companies like the mars orbiter). When there isn't a straight forward conversion, or where that conversion doesn't "help", we leave it in sensor units. We have not used LabVIEW's convert unit feature.

[mathking]

To the discussion of trade-offs between the benefits of unit checking versus adding to the complexity of the code I will add that making the code harder to read has a very serious downside for FRC that does not exist in some other applications. Namely that FRC code often needs to be very quickly modified and tested between rounds. Adding to the difficulty of reading the code can be a real problem. We have generally tried to include sensor calibration information in the comments for each method.

[Jared]

When we used LV, we were aware that LV had lots of useful data types, but we didn't use the feature mentioned above. To solve the problem of inconsistent units we made all of our outputs clusters that we could unbundle, and each element of the bundle would have a meaningful name with units. Having all the bundle/unbundle, index/build array vi's everywhere got confusing, especially while trying to figure out arrays of clusters and clusters of arrays. In order to simplify the block diagrams, we decided to do all of our math in formula nodes, and figure out all of our equations on a piece of paper, while making sure to check units. This system works, but explaining to newer programmers what type defs are, and how 3d arrays are split into 2d arrays was really tough, and was why we switched to java.

[Jared Russell]

We always use the same units and are allergic to things like encoder counts, loop counts, magic constants, etc. All public interfaces speak in terms of standard units, with the exception of open loop speed commands which are in the range [-1, 1]. All return values and arguments are named so that the units are explicit, and a common library is used for any necessary conversions.

Generally we use:
Distance = inches
Time = seconds
Angles = degrees (in yaw 0 degrees is robot forward, increasing clockwise)

Rates and accelerations are therefore inches/sec, deg/sec, etc. Inches are used because FIRST field drawings are usually spec'd in inches, so it makes for intuitive autonomous mode scripting. We use degrees for angles due to intuition. 0 degrees is north because usually if we care about degrees we are talking about autonomous mode, so the robot's starting orientation defines the coordinate system.

I've played with libraries like Boost Units and javax.units, but always found their syntax clunky.

[SoftwareBug2.0]

Originally Posted by Jared341

I've played with libraries like Boost Units and javax.units, but always found their syntax clunky.

Learning Boost.Units has been on my to do list for a long time but I've never gotten around to it. In my own code, I tend to just do things like:

typedef Foot double;

It's not much more than documentation though.

[Greg McKaskle]

Thanks for the info thus far.

I didn't really expect very many teams to use SW tools to enforce and check units, but thought I'd check my assumption.

If teams were trying to use them, it would be helpful if the WPILib sensors and actuators were had support for the advanced types built in.

Any other input as to whether this would be a useful feature? Do you think it would encourage more/better sensor integration? More/better autonomous?

Greg McKaskle

[SoftwareBug2.0]

Originally Posted by Greg McKaskle

If teams were trying to use them, it would be helpful if the WPILib sensors and actuators were had support for the advanced types built in.

Any other input as to whether this would be a useful feature? Do you think it would encourage more/better sensor integration? More/better autonomous?

This feature is bad because it would use engineering time that ought to be used to fix real problems.

-WPIlib C++ code is flawed. There are places where it may dereference a null pointer. There is a function that takes a lock, looks up the address of a global variable, unlocks, and returns the address. If you're interested I can post a more detailed list of problems.

-The low-level interface is undocumented. This means that to bypass WPIlib requires guesswork about what the field requires. And when people ask for the documentation they're asked to take a hike: https://decibel.ni.com/content/thread/17785

-The tool chain is out of date. It looks like some people are trying to fix that: http://www.chiefdelphi.com/forums/sh....php?t=116921; it would be nice if something like that was available out of the box.

-Problems go unfixed for years. Here's one from 2011: http://www.chiefdelphi.com/forums/sh...ad.php?t=89255. It does the same thing today. If the file to download doesn't exist then the error message is "IO Error while downloading program to robot" rather than "File not found at path [insert path here]".

I think it's fun to add features too but I think there are bigger fish to fry.

[magnets]

Originally Posted by SoftwareBug2.0

This feature is bad because it would use engineering time that ought to be used to fix real problems.


I think it's fun to add features too but I think there are bigger fish to fry.

I agree. It's really frustrating to hear that all these great new features have been added at kickoff (robot simulator, robot builder...), but something really, really basic, like the CPU graph, got messed up, because somebody made a stupid mistake, and decided to change working stuff after the beta test.

I'd rather see development time spent on testing and reviewing code that's going to be released to teams. Like including a driver station log viewer that can actually open driver station log files. Or, a debugger that works over a wireless connection in java. In the past, stupid little bugs like having every other encoder work really hurt teams.

However, the thing that bugs me the most is the documentation page included in netbeans. For new programmers, having a nice place to look is really helpful. On the main documentation page in netbeans, the second line said "This document is a work in progress, more to come by final release", this needs to be removed. Also, none of the three demo projects listed can be opened, and one of the sites linked was last updated in 2010. I had some kids trying to get the v20 cRIO image from 2010. Also, as the previous poster has pointed out, some of the code is just too complicated and poorly implemented to be really useful, like the totally incomplete vision libraries. Before a single new feature should be added, ALL of WPIlib should be documented.