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.
Dave Frederick
Team 1895
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.
Gazebo is actually going to be EOL before too long. All the work is being put into Ignition… which is basically Gazebo but better: Gazebo : Blog
Ignition (Dome is the latest release): Ignition Robotics
That being said, yes, this is cool.
Looks like Ignition still doesn’t have Windows support. They advertised mid-2019 but it’s late 2020 and not there yet…
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.
In some cases, we need help ourselves 
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.
I believe one current robot simulation environment is Webots (https://www.cyberbotics.com/)
Dave Frederick
Team 1895, Manassas VA
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.
I would like to see a user-defined link ratio so that Talons and such can return a roughly realistic encoder value based on motor speed.
There is also the Synthesis simulation code from Autodesk (but it is open source)
https://synthesis.autodesk.com/
So far, I have driven around the precanned robots, but have not had much luck. But also have not put much time into it.
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:
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.
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).
Here’s the docs for the 2021 thing: Physics Simulation with WPILib — FIRST Robotics Competition documentation
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!
