View Single Post
  #19   Spotlight this post!  
Unread 05-03-2016, 00:30
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 803
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Potential Git and CI integration

Quote:
Originally Posted by Jaci View Post
For a robotics program, this seems like the wrong way to do things. JUnit has it's place, but I don't think FRC is it. Unless your code (and your framework) are specifically designed for isolated testing, unit testing is not really suited for a robotics / embedded software environment. The main reason I say this is because of things like Motion Profiling, PID and any kind of Feedback. While, yes, it is possible to test, the tests often don't reflect actual operation, or do a very poor job of it. That being said, that's probably just my opinion weighing in.
JUnit != Unit Testing. JUnit is a testing framework. It does a great job of giving you tools to check that the expected results are correct, organizing test cases and reporting failures. You are welcome to use it only for unit tests, but it can be used for any type of testing where there is a need for it's features. WPILib uses JUnit running on a roboRIO to make sure PID loops and sensors are all working.

Testing all depends on what you put in it. If you are going to try to mock out a robot subsystem to do unit testing, you are going to have a bad day. Figuring out by hand what a system should return is hard. If you write a simulated subsystem with simulated sensors to support more of an integration test, you can get some very powerful results. You can model almost all FRC subsystems as a motor attached to a mass.

We do pretty exhaustive automated testing of all our control loops and motion profiles, all inside google-test in C++. Last time I counted, we had 20+ tests for our superstructure, and many more tests for things like motion profiles. If you can't control a model of your robot pretty well, you have no hope of controlling the real thing. Unit tests are also very helpful at helping you understand when smaller units of code are performing as expected. This enabled us to have all the software we wrote before the hardware was done this year up and running on the robot in 24 hours, with no modifications after calibrating pots and measuring limit locations. Our arm and flywheel controllers all worked pretty well and were stable, just from the quality of our simulations. That's pretty powerful and well worth the investment.

Motion profiles are actually much easier to test than controllers. You can compute ideal trajectories and see if your generator successfully generates and follows them. You can also write tests making sure they have the bounded acceleration characteristics you expect and bounded velocity characteristics.

I believe that FRC should try to teach some of the best practices in industry to our students. Testing is a key part of developing and maintaining production software. I write both unit tests and integration tests in both industry (safety critical vehicle automation) and at robotics, and it drastically helps the code quality in both locations.