Robot Simulator not working

This is my second year of programming and due to the coronavirus most of our team has decided to convert to the robot simulator for the programming team, however I have had much trouble setting the simulator up. Our robot is extremly complex however run the simulator one 2 ecoders and 1 PWM shows up while I know for a fact there is more. Here are some of the errors that I have been getting.

Error at com.analog.adis16448.frc.ADIS16448_IMU.switchToStandardSPI( Could not find ADIS16448
//I know this is the gyroscope, however I am unable to get this to work

[CAN SPARK MAX] Unable to retrieve SPARK MAX firmware version for CAN ID: 20. Please verify the deviceID field matches the configured CAN ID of the controller, and that the controller is connected to the CAN Bus.
// This can also be said about can ids 21, 22,23, and 25

Warning at edu.wpi.first.wpilibj.DriverStation.reportJoystickUnpluggedWarning( Joystick Button 5 on port 0 not available, check if controller is plugged in

It’s trying to read data from a device on the SPI bus in simulation, and it can’t because there’s no SPI bus (ADIS16448-RoboRIO-Driver/ at master · juchong/ADIS16448-RoboRIO-Driver · GitHub). The ADIS16448_IMU class doesn’t support simulation yet. They’ll need to implement SimDevice internally at some point.

We had a similar problem with a navX and the SparkMax. We created simple wrapper classes which short-circuit some of the calls in simulate mode. We have not tested them extensively on a real robot (very limited access ;-() but it should work.

You can see them here:

1 Like

Sorry for the late reply but yes thank you, is it possible to implement this for the Gyroscope as well?

Some of the gyros already are compatible with the simulation, at least the AnalogGyro. You can see it in the examples.

If you want to wrap a specific class, you can see our code here:

There are 2 wrapper classes, one for the navX and one for a SparkMax.
1 Like

Sorry for the late response but how would you implement wrapper classes?

TLDR: WPILib has sim stuff (the SimDevice API), see frc-docs for details.

Wrapper( classe)s are just a fancy name for a class/function that wraps operation of something else.
In this case, you would write a class that has two members: the real device object, and then sim data objects. Then, you add functions (example here: gyro):

public double getAngle() {
  if (RobotBase.isReal()) {
    // read angle from real hardware
    return navX.getAngle();
  } else {
    // read from simulation stored data
    return simAngle.get();

Obviously, this is partially pseudocode - see the docs or implementations for reference.

Just noting that the NavX has simulation support (without physics - see the new WPILib stuff or implement it yourself), you just need to access it yourself through the SimDevice API:

// get the device
SimDeviceSim simNavX = new SimDeviceSim("NavX Sensor [0]");
// get the property
SimDouble simAngle = simNavX.getDouble("Yaw");
// get the property value
double angle_deg = simAngle.get();

I’m not sure of the string keys, check what shows up under Other Devices in the SimGUI. Either way, you can read/write values using the SimDouble object.

Phoenix devices are also connected to the SimDevice API, but CTRE is releasing their own sim physics support so you should use that.
SparkMaxes aren’t currently connected to the SimDevice API, though I believe that REV has plans to do that.
All WPILib device classes are connected to the SimDevice API, though they have classes that do it cleaner:

// in your subsystem hardware declarations
Encoder myEncoder = new Encoder(1, 2);
EncoderSim simEncoder = new EncoderSim(myEncoder);
myEncoder.getDistance(); // should return 100

Their physics support leaves something to be desired, imo. Here’s what you need in user code, among other things, for it to work: Phoenix-Examples-Languages/ at sim-examples · CrossTheRoadElec/Phoenix-Examples-Languages · GitHub. It’s a lot of code, and it uses a strange sort of trapezoid profile instead of actual physics. It’s good enough for testing something moves, but definitely not as realistic as what WPILib offers. Maybe they’ll clean it up before release?

Thank you so much this was really helpful

Just as a note that PhysicsSim code isn’t really meant to be actual physics, it’s just called that because it takes the place of what’s normally physical motor movement. It’s only meant as a rough conversion from Motor Output -> Sensor Input so someone can pull down the examples and exercise the features of the robot-code-side simulation.

For a full robot sim, a real physics simulation should definitely be used in its place. We’re adding a comment before final release/merge to clarify that.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.