FRC Simulator Features Ideas

[BXD Autodesk]

This summer, my fellow interns at Autodesk and I have continued the development of our FRC game simulator, known as BXD: Synthesis and are releasing a Beta in a few weeks. Synthesis applies robot code onto a CAD model. We will be releasing the 2016 version in a couple of weeks. We now need to know what features that you want to see in next year’s release.

Current Features are:

Robot Exporter, from Inventor
• Includes the capabilities of moving parts such as elevators, wheels, and pneumatics
• Includes varying levels of wheel traction
• Mecanum, Omni, and Traction wheel support

Field Exporter, from Inventor
• Can make your own field
• Includes the ability to change levels of friction for different parts of the field
• Includes game piece exportation

Simulator
• Includes diagnostic window
• Re-orient robot feature
• Driver station implementation
• Java and C++ implementation

[SoftwareBug2.0]

How about an API with a non-GUI mode so that it can be easily used in automated tests?

[gblake]

SWEET!

A couple of weeks ago, I randomly found some of the plans we made for expanding the 5th Gear simulator. I'll post some of that and/or exchange some emails with you guys.

With luck I'll find some API code I was working on too.

A few questions to create some context.....

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?
Do you have TCP/UDP interfaces for exporting the robot's externally visible and internal state, and for importing commands to control actuators?
To simplify graphics processing, and computation in general, do you have a low fidelity mode for each robot?
Do you have a Graphics-only executable for displaying multiple robots and game pieces on a field?
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?


The answer to all of the above might be "No". If it is, that doesn't diminish that you are in the process of doing something really special.


Blake

[RyanCahoon]

I'm looking forward to playing with this.

What support are you offering for simulated sensors? Encoders, potentiometers, limit switches, range sensors like ultrasonics, gyros, cameras (as Blake previously mentioned)

Make it open source

Simulate battery and electric motor dynamics effects

Out of curiosity, what are you using as the physics engine?

[Rapture'sFinest]

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?

This is a nifty linear algebra trick (projections (http://ocw.mit.edu/courses/mathematics/18-06sc-linear-algebra-fall-2011/least-squares-determinants-and-eigenvalues/projections-onto-subspaces/MIT18_06SCF11_Ses2.2sum.pdf) from one dimensional space to another). OpenCV already has such as function, called projectPoints. While it isn't advisable to include such a big library such as opencv just to use one function, it is *open sourced.

*Crtl+f for "projectPoints" and you will find the source code for such a function
https://github.com/Itseez/opencv/blob/f824db4803855ca30bf782f8bb37ca39051f319f/modules/calib3d/src/calibration.cpp

[asid61]

Solidworks support? :P
Seriously though, this sounds super cool. I'm going to have to learn Inventor for this. :D
Sensor support would be the main feature that would be good, or just some way to add sensors. Basic distance sensors and encoders (CPR on wheels) would be really useful.
Can the field have elevated portions, or just high-friction areas?

[BXD Autodesk]

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.



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.



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).



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.



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.



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.


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.

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.

[Rapture'sFinest]

Will score be kept?

[cbale2000]

Out of curiosity, is the intent of this program to be a single user simulator/test environment (a virtual practice field, as it were), or a multiplayer game?

I attempted to do something like this a few years back with Valve's Havoc engine. I finished the environment but never got far with the robots, as exporting to the necessary format was impractical and code simulation even harder at the time.

Cool to see something like this being worked on either way.

[BXD Autodesk]

Will score be kept?

This will not be released with the planned release in a few weeks, but it is on our list for a future release.

Out of curiosity, is the intent of this program to be a single user simulator/test environment (a virtual practice field, as it were), or a multiplayer game?

For now, our goal is to provide a realistic simulator to test robot code and robot designs, not provide multiplayer support. We still have a ways to go before it will be realistic, but after that goal is met we may look into adding multiplayer functionality.

[cad321]

I realize you have already said that multilayer is not a priority at all at the moment, however if you were to develop some for of multilayer aspect, it would be cool if you could incorporate LAN capabilities. This would allow each driver to have his/her own "driver station" allowing an even more realistic feel. Most simulators that have multilayer that I have seen have done more of a third person view of the entire field for use on 1 monitor and multiple drivers.

Another thing that would be cool to see is multi monitor support. 1 screen with your driverstation console, the other with your view of the actual field.

[pmax]

Solidworks support? :P


(x-post w/ the Autodesk forum: http://autode.sk/1LcL1MM )

Inventor's new AnyCAD feature will let you keep master CAD files in the system of your choice, and open them in Inventor.
http://www.autodesk.com/products/inventor/features/new/gallery-view

It would be good to test this out with a fully modeled SWx robot.

[Joe Ross]

Solidworks support? :P

The FRCSim (http://wpilib.screenstepslive.com/s/4485/m/23353) instructions were updated over the summer with solidworks exporting instructions. I expect that this capability will be beta tested this fall and released for next season.


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.

Will the API be similar to the simulator API for FRCSim?

[EDesbiens]

Adding labview support would be great :)

[gblake]

BXD Guys,

Is this diagram "What's in a simulated match?" (http://www.chiefdelphi.com/media/photos/42310?) close enough to the way you have viewed robots, fields and matches, for us to use it describing what you have/haven't produced?

I dislike the description I wrote when I posted the diagram, but at the time I uploaded the diagram, that description was the best compromise between work-in-progress and results-of-past-progress that my brain and fingers would type for me.

I do think that it is a useful diagram. I also fully realize that there is more than one way to skin the cat, and I'm curious if the diagram matches your group's approach.

If there is a match (or if you/we can create an different agreed diagram), then (I think) contributors to this thread will be able to post better suggestions and questions. I know that will be the case for me.

Blake