Quote:
Originally Posted by SoftwareBug2.0
How about an API with a non-GUI mode so that it can be easily used in automated tests?
|
Currently we do not and are not planning to fully support an API for automated tests in the upcoming release, but we have implemented a fake version of WPILib to simplify the interface between WPILib and the simulator. This could be extended to provide support for automated tests in later releases.
Quote:
Originally Posted by gblake
- If you imagine a typical (weak) school computer, can that computer simulate one instance of one complex robot at real-world speeds? On that imaginary computer how often can the simulation update (in real world, wall clock time), and how much simulated (robot's imaginary world) time would each update represent?
|
It varies vastly depending on the hardware of the computer, the background processes, and what robot and field you are trying to simulate. On a laptop with an i7-3820QM CPU running at 2.70 GHz, 8.00 GB of RAM, and a NVIDIA Quadro K2000M, the simulator runs
very smoothly.
Quote:
Originally Posted by gblake
- Do you have TCP/UDP interfaces for exporting the robot's externally visible and internal state, and for importing commands to control actuators?
|
To update the internal state of the robot, we send a UDP packet, similar to how it works on the field. The robot sends back a UDP packet with various internal states, such as the output of its sensors (note: sensors will not be supported in the upcoming release).
Quote:
Originally Posted by gblake
- To simplify graphics processing, and computation in general, do you have a low fidelity mode for each robot?
|
Inside of the rendering engine, we do not support a low fidelity mode. However, when exporting your robot from Inventor you can select an option to simplify the robot and export less polygons.
Quote:
Originally Posted by gblake
- Do you have a Graphics-only executable for displaying multiple robots and game pieces on a field?
|
We have a graphics-only executable to display the robot after it has been exported. We currently do not support viewing the field pieces in this application.
Quote:
Originally Posted by gblake
- Do you have an executable that can create an image (an updating array of pixels) that approximates what a robot mounted camera would see? What about scenery that would surround a field?
|
We do not support this currently, but this will be implemented in a future release.
Quote:
Originally Posted by RyanCahoon
What support are you offering for simulated sensors? Encoders, potentiometers, limit switches, range sensors like ultrasonics, gyros, cameras
...[snip]...
Out of curiosity, what are you using as the physics engine?
|
Unfortunately, sensors will not be supported in the upcoming release, but these are a high priority on our task list. Sensors are very close to being supported and will definitely appear sometime in the future.
For the upcoming release, we are using the Unity game engine, which uses PhysX as a physics engine. We are working to switch to the Bullet physics engine for future releases.
Quote:
Originally Posted by asid61
Solidworks support?
...[snip]...
Can the field have elevated portions, or just high-friction areas?
|
We do not support Solidworks and have no current plans to support it, but there is a chance that it could be supported in future releases.
We have full support for the 2015 field, including the elevated scoring platforms.