Simulating a NEO/CTRE mixed robot using new WPILib Simulator

I’m coding in Java first off.
I’m aware that REV and Kauai simulation support is not there yet, but I’m trying to simulate our drivetrain using 4 neos, 2 per side with Navx in the roborio expansion port. We’d like to close the loop for autonomous driving on the Spark Max controllers, so is there any workaround for the lack of simulation support?

EDIT: I just saw Rev’s 1.5.4 release which “adds basic simulation support”. However, I’m not seeing more details in the javadocs. Where can I find more info on this?

EDIT 2: since it went that way anyway, how can I most easily simulate my robot’s mechanisms if it also has CTRE controllers? Title updated.

1 Like

I haven’t found too much information about this on REV’s website, I might have missed it though.
Since there are no new classes/symbols in the API, I assume that 1.5.4 adds the Spark Max to the SimDevice API. NavX is already connected to it. I recently made a CD post outlining how to use the SimDevice API in team code, it’s this. An article about it for frc-docs is in the works.
At last, the console won’t be spammed with missing spark max hardware warnings!

I’ll just note that there is currently no official/vendor support anywhere of simulating onboard control. If you think it’s worth your time, you can write a wrapper class that runs a PID loop on whatever you want though.

Okay. That’s what I figured it would be. I’m just looking for a way to do the kind of simulation I could have done with Talons in the REV ecosystem, specifically modeling the drivetrain using characterization.

1 Like

Wait a minute, what? The drivetrain modeling is in WPILib, not CTRE; and it supports any motor/controller type. Just make sure that you choose the right template when you run the frc-characterization tool.

Right. I understand that WPILib handles the mathematical modeling, but I was under the impression that in order to use it with a simulation using smart motor controllers, the vendors needed to add support like CTRE did.

1 Like

The WPILib drivetrain/mechanism simulation needs to have access to write simulated encoder data. This is basically done over the SimDevice API, which REV now added support for.

CTRE added their own physics simulation APIs parallel to WPILib’s (though I think that the two shouldn’t be used together).

Oh that clears up a lot. I completely misunderstood. So for simulating a robot with a mixed ecosystem, I want to use SimDevice with WPILib’s characterization based modeling where possible?

1 Like

This isn’t quite true. There are some physics simulation items in our example projects (so that you can pull down an example and test it as-is), but it’s not packaged in our library API. We highly recommend replacing it with your favorite physics simulator when porting it to your own projects.

WDYM “mixed ecosystem”? The frc-char tool needs to be run on each mechanism (drivetrain/elevator/arm/flywheel) separately. If you have both Talon/Victors and SparkMaxes in your drivetrain, then you shouldn’t.
If your drivetrain is all Sparkmaxes, run the frc-char tool with the SparkMax - Brushless/NEO template (make sure it’s the brushless template).
Then follow the tutorial, replacing Encoder with CANEncoder and EncoderSim with the distance/rate SimDouble objects that you get from the SimDeviceSim (NOT SimDevice!) objects of the controllers. This is assuming that your encoders are connected to the SparkMaxes.

@Jacob_C - I’m referring to the new SimCollection stuff in the Talon API. Or am I missing something? I’ll admit that I haven’t looked at it.?

This answers the question. “Mixed ecosystem” was just referring to e.g. “Drivetrain is Spark Max, intake is Talon, for simulation we should stick with the generalized WPILib sims.”

1 Like

Ah, I thought you were referring to the PhysicsSim file in our examples (which convert motor output to a sensor delta).

SimCollection methods are the sensor inputs to the simulated Talon - they can absolutely be used in conjunction with WPILib simulated classes. For example, you would pass the sensor data from a Drivetrain sim into the talon’s SimCollection.SetQuadratureRawPosition() (same for velocity), then pass the percent output from the Talon back into the Drivetrain sim.

SimCollection does not simulate physics, it’s just the simulated physical inputs to the Talon (sensors, busvoltage, current, etc.).

So what CTRE has that REV doesn’t yet (or does it?) is simulated onboard control loops. Not that anyone outside REV would probably know so early, but does the Spark Max integration into SimDevice mean that the code can access those control algorithms in simulation?

1 Like

Yes, I believe the SimDeviceSim class will work as @Starlight220 mentioned. We’re working on two things for simulation in the near term, adding examples for SPARK MAX, and adding cleaner methods to access the internal simulation state, similar to the sim classes such as EncoderSim.


I’m don’t think that CTRE has sim onboard control, nor REV.
What CTRE has is SimCollection, which (according to @Jacob_C’s post) is a slightly neater API than SimDeviceSim but it does precisely the same thing: instead of using EncoderSim.setCount() (for basic WPILib) you would use SimCollection.setQuadratureRawPosition() for Talons. According to @Will_Toth’s post, REV is working on an API similar to CTRE’s SimCollection. Until that API is published, you’ll have to use SimDeviceSim.
I just experimented a bit, and this works:

int id = 12;
CANSparkMax realSpark = new CANSparkMax(id, kBrushless);
// device key - this is the string that REV created the inner `SimDevice` in the SparkMax class.  
String deviceKey = "SPARK MAX [" + id + "]";
SimDeviceSim simSpark = new SimDeviceSim(deviceKey);
String fieldKey = "Alt Encoder Position"; // or "Position" for the built-in NEO encoders
SimDouble positionProp = simSpark.getDouble(fieldKey);
// example set distance
realSpark.getAltEncoder().getPosition(); // 100.0

All the strings are the ones that the devices/fields appear with in the SimGUI.

1 Like

I feel like I’m hijacking the thread at this point, but I need to comment on this for anyone else who comes across this thread.

Phoenix’s simulation does support simulating all closed-loop control modes on Talon and Victor. SimCollection serves two purposes - providing inputs for the internal Talon simulation and then at the WPIAPI level it’s used to provide input hooks for websockets.


I don’t feel like it is hijacking because many like us are using mixed controllers on the robot and still learning and trying to understand how to implement simulation in the best ways, so clarifying any confusion is very helpful (like you say for someone later reading comments too).

At first swipe, the REV NEO simulation Sparks weren’t as responsive in the simulator as I feel like the Talon and Victor were for me, but there is good info here to further follow and I may be missing stuff in code to make that happen. By responsive I mean in the device list seeing the output change in the Victor/Talon devices with joystick inputs, but not seeing any of the Spark fields changing in that way. That is without seemingly setting up specific simulation objects (just works). The goal is running a drivetrain simulation for auto routines using the NavX/NEO combo, trajectory and Field2d class, and I hope that is more easily obtainable with the newest REV update.

Title updated to expand scope. You’re not hijacking anymore.


I’m in this boat, so to keep this on topic, I expanded the topic.


Just to let folks know, there’s now a basic Java example for using TalonSRX simulation with WPI’s DifferentialDrivetrainSim:

1 Like

Where are you getting the deviceKey and fieldKey from?