Also switch eventName and gameSpecificData to fixed 64-byte arrays to avoid mallocs and
extra NetComm calls. This behavior matches 2018 LabView.
The DS caching is kept in Java to avoid JNI and/or massive amounts of allocations.
This does not increase latency because Java still only hits NetComm once.
Moving the DS caching benefits all languages other than Java, because it avoids the need
for individual implementations. If caching is ever added to NetComm, it will then only be
necessary to remove it from the HAL and Java rather than all languages.
It is much more reliable than the old approach, as it no longer depends on a magic string
in a manifest file, and if the user changes their main class, or makes it not import from
something RobotBase, it will fail to compile instead of failing at runtime.
With requiring an importer, we should be able to automate this in the importer.
4.9 will be needed for some things being added to a few of our plugins. It adds the new lazy configuration tasks which help a good amount in some cases.
I don't have a good way to ensure this always works, so this is going to be a documentation issue.
But initializeHardwareConfiguration is now reentrant, so we can just have all tests call it.
Also fix the return type of HAL_IsNewControlData() and HAL_MatchType's type.
Since UsageReporting is intended to be namespaced, it is hidden when this is being used in C.
Fixes: #476Closes: #535
Ref: #1122
The models and meshes are not included. We will need
to find an alternate way to reintegrate these and use them.
* Add simulation/gz_msgs back, and build with Gradle.
* Add back in the frc simulation plugins for gazebo.
* Add a new shared library, halsim_gazebo.
This library will become the interface between the
HAL sim layer and gazebo.
* Preserve the first channel number used in created Encoders in the Sim MockData.
This allows us to use the DIO channel number to connect with simulated encoders.
* Have the HAL Simulator set the reverse direction on creation.
This enables a simulator to be aware of the direction.
* Add a drive_motor plugin.
This is a bit of a 'magic' motor, which allows us to build robot
models that drive in a more realistic fashion. It does this
by apply forces directly to the chassis, rather than relying on
the complex motion dynamics of a driven wheel.
This in turn allows the model to reduce wheel friction,
reducing scrub, and allowing for a more natural driving experience.
This optimizes the common case of a single simple callback (e.g. std::function
or lambda) so no additional allocation is required. As a Connection return
value is not possible in this case, provide a separate connect_connection()
function to provide that.
Imported from https://github.com/palacaze/sigslot
Classes were renamed from lowercase_me to UppercaseMe style, primarily
to avoid conflicting with the C standard library "signal" function. They
were also moved to the "wpi::sig" namespace.
