-
Notifications
You must be signed in to change notification settings - Fork 11
Using the Simulator
Once you have the simulator set up and ready to use you can customize it for your robot. If you haven't set up your robot yet, running it with no modifications will bring up an example robot for you to play around with
This guide will use the example robot for screenshots.
The first time you boot up the simulator you should see a screen like this
From here you can put the robot into autonomous, disable it, and see the match time. You can also change the setting, like the name of the component and hookup encoders to speed controllers.
A lot of the settings are simple. You can click on any of the gear icons to bring up a dialog to change the settings. Below is an example of changin the solenoid settings
The speed controller settings allow you to [simulate motor responses](Motor Simulation).
The encoder settings allow you to hook up an encoder to a speed controller as a feedback device. This is very useful for simulating things like your drivetrain or elevator
Once you have renamed the components and hooked everything up as you would like, you should see something like this. Not that the encoders now display count and distance rather than "Not Hooked Up"
Once you are all set, you can click the "Save Settings" button to persist the changes to disk, and leave edit mode. Now the next time you start it up, you should see the new names you gave the components
Unfortunately not all of the available simulation options are available for configuring from the GUI and must be done manually by editing the config file.
WPI provides libraries for interfacing with several SPI and I2C gyros and accelerometers. Some of these implementations require a response during construction of the object, and the simulator cannot always figure out what component you have created, and thus the WPI code may say that it didn't find the sensor. In order to avoid this issue, you are required to specify what I2C/SPI port has what object hooked up to it. Here is an example of the code you would need to add to your yaml configuration file
mDefaultI2CWrappers:
0: ADXL345
mDefaultSpiWrappers:
0: ADXRS450
1: ADXL345
2: ADXL362
3: ADXRS450
In addition to the simulators listed above, we also support NavX
(for both I2C and SPI)
A lot of teams likely have a setup where their drivetrain has an encoder on each side of the drivetrain, and a gyroscope to measure the robots yaw. We have provided the ability (through some black magic math that I forget how it works) to read the two drivetrain sides and calculate what the angle of the robot is.
mSimulatorComponents:
- !!com.snobot.simulator.simulator_components.TankDriveGyroSimulator$TankDriveConfig
mGyroHandle: 1
mLeftEncoderHandle: 0
mRightEncoderHandle: 1
mTurnKp: 0.5
Here you must specify the port handle for the three sensors. Note, the port handle does not always equal the value you used to insantiate the sensor in your code. For example, in order to avoid conflicts, the SPI gyro adds 100 to the SPI port you are using, and the 3 NavX SPI gyros start counting from 250. Since you are manually editing the config file, you should be able to look above at where the name is set to see the handle that is being used.
The mTurnKp
parameter is the black magic number used to determine how quickly the robot turns based on the inputs from the encoders. The smaller the number, the quicker the robot will turn.
You have the option to extend the simulator and create custom simulator components for your robot. Examples of this might include:
- Update an Ultrasonic's distance based on the position of the robot to simulate approaching a wall
- Simulate limit switches being pressed by looking at the position of your elevator. Useful for testing your "don't keep going up if the top limit switch is pressed" algorithms
- Simulate camera feedback based on the position of the robot. You can add in things like delays and/or a low frame rate to test the robustness of your consumer logic
- Simulator Custom SPI devices so you can visualize 3rd party hardware devices, or tie them into your robot feedback
In order to achieve this, you need to override the base simulator object
public class YourCustomSimulator extends ASimulator
{
public YourCustomSimulator()
{
// Add your custom code here
}
@Override
public void createSimulatorComponents()
{
super.createSimulatorComponents();
// Or in here. This gets called after the robot has been created
}
}