Java based Unit testing with simulated hardware

While the definition of a unit test only checks the logic within the context of a specific method. My thought for FRC is that there are a number of times I want to do more of an integration test where I need to make sure some simulated hardware actually reacts as I would expect (i.e. the motor controller’s output value changes and stay set, sensors respond with a simulated response). This is most critical in situations with feedback control (i.e. PID) where having some simplified simulated hardware in the loop becomes exceedingly useful.

In my thoughts the ‘holy grail’ of testing would include a simulated hardware definition that would allow a motor and sensor (encoder) to be connected in a mixed-mode simulation. Then a requested speed/power change on the motor controller would be reflected on the sensor after a specified simulated time interval. But this will be much more involved then a ‘unit test’.

I know that WPILIB now has simulation capabilities and improved unit test functionality, however is there any way to handle simulated hardware from within WPILIB?

I would really like to see code from someone (a link to github would be more than sufficient) that shows a unit test with a mocked-up motor controller connected that can keep state to enable feedback testing.

Thanks

Do you mean something like this? allwpilib/Robot.java at master · wpilibsuite/allwpilib · GitHub

Yes that is what I was looking for!

I had never seen a clean test harness for simulated hardware using the new simulation framework. An yes I have ready the documentation :slight_smile:

Any other examples from teams?

A small presentation I was working on may be of help to you.

Make sure to turn on speaker notes, slides aren’t always meant to be stand alone.

It’s based on the approach I took with 323’s code a few years back to enable development with hardware being 1000 miles away and my desire to not be on a video call for multiple hours every night.

Would you expand on your slide 38 about test driven development being “overhyped” and a “trap to those new to testing” (i.e. my team)?

Short version - there’s a lot of hype around tdd in certain circles as the one true way.

There’s certainly value to it, and it works for some people and some problems. It’s not the only solution and some people find it harder than normal testing approaches.

It’s a trap for a lot of new folks because they see the hype, hate the process, and end up avoiding writing good tests (or any).

It’s not bad, it’s just not the only solution. Sometimes all you can do is test one or two core things. That’s fine. Especially with students doing some testing is better than doing none.

Really I’m trying to say “just do what you can”

4 Likes

See also: agile, model-driven development, devops

1 Like

We’re relying on the simulation paradigms you mention for doing software training and ramp-up without physical access to a robot.

FWIW this was set up to solve the “keep software happy with reasonable approximations of what motors and motor controllers and gears and sensors do”. Not physics accurate on purpose, just “accurate enough” to allow us to make progress.

It relies on wpilib’s ability to deploy robot code in simulation on a desktop PC.

It does not attempt to solve any form of automated regression test. However, that would be a fairly trivial extension.

I am trying to get a simple drivetrain simulation working but am hitting my lack of knowledge of Java/Gradle/build…

Unless I am missing something, the new simulation classes are only in the development version of WPILib so far. I tried using the brief instructions here to switch to the development version:
allwpilib/OtherVersions.md at master · wpilibsuite/allwpilib · GitHub
but it does not seem to actually fetch any new version.

Is there a way to use the prebuilt versions (in Artifactory I guess?), or do I have to clone and build the repo myself?

Following the directions should work but because of some development changes you’ll need to also include the json file at the link below in the vendordeps directory of your project.

Thanks! That got me over the hump.