Add array and/or string support to `SimDevice`/`SimDeviceSim`.

[brettle]

Add array and/or string support to `SimDevice`/`SimDeviceSim`.

[PeterJohnson]

The idea of SimDevice, per the name, was to provide some level of flexibility to emulate physical hardware devices very efficiently with very simple APIs. Very efficiently in this context meant atomic accesses, rather than mutex-locked, thus the limitation of word-sized data types. In addition, such data types have minimal JNI overhead and are callback friendly, as well as easily visualized in a GUI. AddressableLED isn’t implemented via SimDevice but rather is a custom implementation.

Notably, in addition to SimDevice, we have NetworkTables, which is a pub/sub framework that supports far more complex data values including arrays, strings, and raw and structured/serialized data such as protobuf.

What I don’t want to do is turn SimDevice into NetworkTables. If the ask is to just provide a mutex-locked (rather than atomic) byte array or string value support, it’s something we can look into, but there may be significant performance downsides, so it should be used sparingly.

It’s somewhat unclear to me what hardware you are simulating that would need this complexity of 3D pose information. Normally low level hardware would not provide something quite like this.

[brettle]

In our particular case, we aren't simulating any real hardware device. Instead we were looking for an easy way to get simulation results (e.g. positions, orientations, velocities, of the robot or particular parts of it) from an external simulator back to a test framework which runs the actual robot code. Since we already have a connection between the test/robot code and the simulator via halsim_ws, we were hoping to piggy-back off of that instead of adding a new communication channel such as NetworkTables.

While I admit that the above use is not what was intended, we also would like to simulate the navX-mxp AHRS device and it does in fact provide complete 3D pose, velocity, and acceleration info (among other data). Support for mutex-locked byte array or string values would allow that data to be transferred efficiently while ensuring that it remains self-consistent.

Based on your response, we're now using NetworkTables for the first case. Fwiw, doing so increased the size of the jar used by the external simulator from 1.6MB to 9.9MB. The absolute size is not a big deal in the larger scheme of things, but the large relative increase is at least worth noting.

I'll let you decide based on the above info whether you want to close this as wont-fix, or keep this open as a possible future feature. Regardless, thanks for the quick response!