Has FIRST or WPI considered bringing back FRCSIM?
This was a Robot simulator using Gazebo robot simulation (http://gazebosim.org/). This simulation allowed students to write JAVA code in the Eclipse environment.
It was challenging to get working but once it worked, it provide a way to write code prior to having a real robot.
We still have HALSIM extensions for Gazebo (allwpilib/simulation/halsim_gazebo at master · wpilibsuite/allwpilib · GitHub), but Gazebo only supports on Linux, and we haven’t tested things in a while. Gazebo was ported to Windows a couple years ago, but you have to compile it yourself. The effort required to get it working is also too high of a barrier to entry for most/all teams.
I think we’re better off doing something with Unity for cross-platform, high-fidelity 3D environment simulation.
They are like most open source projects and need help. Microsoft has promised a lot of love and attention for ROS but it’s hard making something designed for one operating system run on another. I’m sure there are ways that the talented and thoughtful wpilib community could contribute to another open source project.
One key point is the FRCSIM was built into the WPI library and the development environment.
When you deployed the code, there was always an option to deploy to the simulation.
Our primary focus over the last couple of years has been on high quality 2D simulation features including the simulation GUI (added last year) and simulation physics (coming in 2021).
Thanks to third party contributions, we recently added a WebSockets interface for desktop simulation. This provides low-level read/write virtual hardware (HAL) access to simulated robot code to enable easier interoperation with arbitrary 3rd party simulation engines such as Unity-based 3D engines. The idea is to alleviate the need for every 3rd party engine to figure out how to build and integrate a WPILib simulation plugin. We need to improve the protocol documentation for this feature, but have talked to a number of different 3rd party engine development teams about it.
The environment-neutral interface is definitely a big step forward.
One thing to consider is that, with few exceptions, you don’t need a super accurate physics simulation to test software. The ability to just execute the code on a desktop has enabled much better unit testing and running “open loop”, which covers a lot of ground.
While a full 3d simulation would be nifty, i guess I don’t personally see it being a huge game-changer for how software gets developed. But. Curious to hear if others think otherwise.
612 has been doing a lot of work trying to get Synthesis to work. From my understanding, we were able to get our robot CAD into the program and simulate the code, but it was rather buggy and didn’t work great. @ProPra you know more about how Synthesis went for us.
For basic “toggle a solenoid when the button is pressed”, I agree. It can be hard to test state machines without the mechanism moving in a realistic manner though. You have to set up something like “the encoder moves at a rate proportional to the voltage applied”. The 2021 physics sim classes will hopefully give something more accurate than that for less effort (a couple lines of input-output plumbing in simulationPeriodic()).
We want to add sim physics and unit tests to all the examples eventually, with the idea being teams could run any example in simulation and see it working in the sim GUI. The unit tests would provide example tests for teams as well as ensure we don’t write broken examples.
We set up simulation so that users add code simulationPeriodic() and create sim objects, but otherwise don’t have to touch the normal robot code. The current simulation physics workflow is as follows:
Instantiate a simulation version of an object, like EncoderSim or MotorSim. Each sim object can take the real object in its constructor so it knows what object its setters are affecting.
Instantiate a physics sim class like DifferentialDrivetrainSim. Its constructor takes information like the types of motors you have, the width and mass of the drivetrain, and the gear ratio. We have a factory function specifically for kitbots too for those who want a drivetrain, not necessarily their drivetrain.
In simulationPeriodic():
a. Set the drivetrain sim object’s inputs to the motor outputs
b. Call update on the drivetrain sim object with the loop time (e.g., 20ms)
c. Set the sim encoder position to the value from the drivetrain sim object
To follow this framework, vendors will need to provide simulation versions of their classes with sensor set calls. For example, the way WPILib’s EncoderSim (which is intended for quadrature encoders plugged into the roboRIO) works is you can call SetPosition() or SetRate(), it’ll set the internal count such that GetPosition() will return the value you passed to the setter.
More on EncoderSim internals
When you call SetPosition() or SetRate(), it’ll convert by the distance per pulse and set the internal count such that GetPosition() will return the value you passed to the setter. The simulation encoder setter rounds the internal edge count to the nearest integer, which gives you finite resolution, as you’d expect. It’s kinda nice the HAL sim inherently models that. Here’s an example of that quantization error causing noise in a simulated flywheel’s angular velocity calculation (change in angle divided by change in time).
Agreed - when I was thinking “super accurate physics simulation” I was more thinking the fidelity where you could go back to the mechanical team and describe the effectiveness of their design. For software test, I do believe that “speed ~= command” gets a whole lot of it, and some exponential or first order model gets almost all the rest…
I know one could always construct a complex-enough scenario, especially if you’re doing state-space controllers, where that level of accuracy is required. But a) the vast majority of teams aren’t doing that and b) if you’re in that boat, you’ve probably already solved your simulation problem some way.
But, to the linear system libraries that are coming out, Yes, they look sweet. I’d started playing with adding simple output->input relationships over the summer, with good results so far. Biggest gap was just not having a ton of documentation - but it looks like that’s well on the way. Looking forward to more, and many thanks as always to the volunteers putting this together!