Quote:
Originally Posted by Peter Mitrano
Digging up this thread because I think it's phenomenal.
am the current FRCSim developer. As FRCSim develops, this should hopefully become much easier to do. Gazebo can be run headless on a server, and since all the communication between WPILib and gazebo is done over Gazebo Transport, a message passing system built off protobuf, it should be way easier to write tests.
How would you guys approach testing with frcsim? Would you write junit tests that calls your robot code? Or would you run your robot code as-is, and write a seperate "supervisor" program that messages the the robot code and listens for the appropriate effect in gazebo? Both seem viable to me.
|
Testing code in the Robotics realm is a two-way street. Personally, for testing, I think just running the code yourself in a simulator is good enough for FRC (but that's up to personal opinion).
Quote:
Originally Posted by Peter Mitrano
Would you write junit tests that calls your robot code?
|
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.
Quote:
Originally Posted by Peter Mitrano
Or would you run your robot code as-is, and write a seperate "supervisor" program that messages the the robot code and listens for the appropriate effect in gazebo?
|
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.