Open brettle opened 1 month ago
Implementation note for 1
: Because these are basically SimDevices
. It could make sense to extend SimDevice
, and provide a constructor that takes (int handle)
, and then add create
methods that have similar logic to SimDevice.create()
.
For 3
, I'm not sure about accepting actual device objects as part of the constructor. This works for CANCoders because phoenix provides a programmatic sim interface for them, but I'm not sure if such a thing exists for other phoenix/rev devices. This would also affect our ability to intercept method calls. We could do this by extending the vendor classes, but
*Sim
classesI think a better option might be to do this same thing, but just let the <Device>Sim
classes replace the mock implementation classes that we currently use.
For the note section, I think you mean to refer to WPIWebSockets
rather than DeepBlueSim
. DeepBlueSim
already depends on WPILib and does not define any *Sim
classes. I agree with the points you posted here, and (to add another), the *Sim
classes defined in WPIWebSockets
are designed to operate after being connected to a running robot project. They would not function correctly in lib199
. Furthermore, it would be preferable to tie into the existing WPILib framework rather than a custom websocket backend.
UPDATE: I found out that CTRE does have a simulation API for most devices. This makes means that a possible (and imo, best) solution is to deprecate the current phoenix simulation classes in favor of the method mentioned above. I'm still not sure about rev tho
Implementation note for
1
: Because these are basicallySimDevices
. It could make sense to extendSimDevice
, and provide a constructor that takes(int handle)
, and then addcreate
methods that have similar logic toSimDevice.create()
.
To be clear, this issue is about creating *Sim
classes that are wrappers around SimDeviceSim
objects that work with the existing sim data currently produced by lib199. Those *Sim
classes would be used in robot code for testing/simulation. They would be more closely related to SimDeviceSim
than SimDevice
. Creating a *Sim
should generally not result in the creation of a SimDevice
. The SimDevice
should (and currently is) created when the real device (e.g. CANSparkMax
) is created. In short, what you're proposing doesn't make sense to me.
For
3
, I'm not sure about accepting actual device objects as part of the constructor.
The *Sim
class would just use the actual device object to get the device's port/id so that it could construct an appropriate SimDeviceSim
object. A constructor that takes the actual device object is handy because it doesn't depend on the caller to make sure they are using the same port/id as the actual device they are intending to create the sim for.
This would also affect our ability to intercept method calls.
I don't see how. I suspect there is just a miscommunication.
I think a better option might be to do this same thing, but just let the
<Device>Sim
classes replace the mock implementation classes that we currently use.
I disagree. The *Sim
classes provide the simulation-facing api. The mocks provide the robot-facing api. The communication between them goes through wpilib's sim infrastructure (via the SimDevice
<-->SimDeviceSim
connection).
For the note section, I think you mean to refer to
WPIWebSockets
rather thanDeepBlueSim
.
Yep. My bad. Fixed now.
**UPDATE: I found out that CTRE does have a simulation API for most devices. This makes means that a possible (and imo, best) solution is to deprecate the current phoenix simulation classes in favor of the method mentioned above.
The CTRE sim support is not compliant with the wpi-ws spec, at least in that a CANCoder does not have the correct device name. Before switching to just using their simulation we'd also want to see how complete it is. For example, does it accurately simulate controller-based PID? In the interim, I recommend we keep the mock and reuse/wrap their simulation support wherever we can. Further discussion on this topic should probably move to another issue.
I'm still not sure about rev tho**
As of this writing, Rev's simulation support is extremely limited and not tied into the wpilib sim infrastructure afaict. Bottom line, it isn't suitable for our purposes.
Ahhh, my bad. I thought you were suggesting creating wrappers around existing SimDevice
s in order to avoid creating the relevant SimDevice
s/SimValue
s manually. If you're instead talking about creating SimDeviceSim
s that correspond to the higher-level classes for use in something like RobotCode2024/subsystems/Arm
, these suggestions make much more sense. Feel free to disregard my previous comment.
Yep, we're on the same page now.
Currently, using the sim support provided by lib199 is error prone because it requires knowing the names of the various devices and properties and using those names (as strings) to create and use
SimDeviceSim
objects. To address this:asyncapi-generator
like we do inDeepBlueSim
, to auto-generate*Sim
classes for the various CAN devices we createSimDevices
for. These would have names likeCANEncoderSim
,CANMotorSim
,CANDutyCycleSim
, etc. The constructors would take the class name (e.g.CANSparkMax
), port number, and an optional "input" name (for devices with multiple inputs).*Sim
classes as consistent as possible with the API provided by WPI's*Sim
classes. In particular, theregister*Callback
methods should return aCallbackStore
subclass and anycancel*Callback
methods should not be public.*Sim
classes for each of the actual device objects we simulate (e.g.CANSparkMaxSim
extendsCANMotorSim
) and have the constructors for those take the actual device objects (e.g. aCANSparkMax
) and construct the appropriate class name to pass to the*Sim
super constructor.Side note: Although we could reuse these
*Sim
classes inDeepBlueSim.jar
WPIWebSockets.jar
(instead of auto-generating separate*Sim
classes there), that would have the following disadvantages:DeepBlueSim.jar
WPIWebSockets.jar
depend on lib199.jar or putting the*Sim
classes in a separate jar that bothlib199.jar
andWPIWebSockets.jar
(and robot projects) depend on.DeepBlueSim.jar
WPIWebSockets.jar
depend on wpilib.DeepBlueSim.jar
WPIWebSockets.jar
depend on vendordeps if the sims weren't split into a separate jar.Those extra dependencies don't seem worth the effort since the "real" common API is defined by the
wpilib-ws.yaml
file use to auto-generate the*Sim
classes in both projects anyways.