Quote:
Originally Posted by Jaci
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.
|
I'm inclined to agree on this one.
Quote:
Originally Posted by Jaci
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.
|
I'll push back on this one. I see no reason why you can't tune a good robot model such that the same PID parameters work in simulation. It's a bit of work, but people have done it with the Atlas robot, Ardupilot, and Baxter, which are all far more complicated and dynamic robots.
Quote:
Originally Posted by Jaci
This seems more viable, but it's usefulness would depend a lot on what gazebo sends back. If you're sending back things like what speed the motors are, or if a port is on or off, that's often quite useless from a testing perspective. Something more useful would be things like displacement of the Robot. Things like that can be compared against 'what it should be', and could practically test things like PID loops and motion profiles.
|
This I think is gazebo's strong point. You can get literally anything. You want to test that your auto drives forward 5 meters? Great, just get the world pose before and after. You want to test that your LaunchCatapult command works? Cool, put a ball in and check where it lands, or even just get the pose of the joint. You can also piggy back on any sensors your robot has, and check something things like driveUntilWall, by comparing absolute distance between the robot and a wall, versus what your rangefinder says and where your robot stops.
That said, I still think even testing "is my motor spinning" is a huge improvement over what most teams do (no testing at all).