baconomist / vex-unity-simulator Goto Github PK

Create a robot debugger(robot editor script) in which the robot is set to a DEBUG state where it waits for a message to tell it to execute a thread update(manually set the bool _canRobotThreadUpdate) on each click of a button. This way you can see exactly what is happening at any given point in time.

... Or just use Debug.Break() to pause Unity

Don't necessarily make this repo public yet, but make a public trello that people can use to suggest features.

Create a script that randomly generates a vex field within tolerances.

(Since in the real world, your robot needs to be able to handle such tolerances as laid out by Vex themselves)

Be prepared for minor field variance.Field Element tolerances may vary from nominal by ±1.0”. Cube tolerances may vary from nominal by ±0.10”. Cube placement at the beginning of Matches may vary from nominal by ±1.5”. Te a m s are encouraged to design their Robots accordingly. Please make sure to check Appendix A for more specific nominal dimension and tolerances. Note: The field perimeter should always be resting upon the Field Perimeter Rubber Feet, regard-less of whether or not the tabs have been cut from the foam field tiles.

Take some time to make sure that the simulator correlates with the real world.

Test using the real robot and tune the physics system to get similar results.

Stuff to consider:

• Wheel colliders vs. rotating bodies, can rotating bodies work?
• Create a standard in Unity for correlating Unity's coordinates to physics units.
  IE: (0, 1, 0) = 1 meter up
  Best way to do this is to maybe have a Physics class
  and methods like Unit.convertTo(UnityType unitType)
  Unit being a unit class that is used for calculations rather than simply native number types
• Increased Physics time step?

Create a c++ script that reloads and copies Unity Simulator build DLL using a Unity COM implementation of said script.

As of now, the unity implementation works just fine...

Currently, when exporting .obj files from inventor, the object names depend on their index in the editor. If that index changes due to moved parts or deleted parts, the link between Unity and Inventor parts will break and the parts referenced in unity will no longer be the same as they were.

Instead make an addon that assigns each object a persistent uid or custom name the user provides and then exports the .obj file with those names.

Could just use blender instead of cad though... It keeps references to named objects w/ .fbx export. However, it's not as easy to use for CADDING...

Allow the user to add breakpoints into their c++ code which they can capture within Rider or unity in General.

One idea is to make a unity callback for coded-in breakpoints to pause the game, but that isn't as good as a full-on Jetbrains-style debugger.

Currently, if Unity crashes, Visual Studio is a viable debugger.
However, adding breakpoints into c++ code and them exporting them to be debugged in Rider or Visual Studio would be optimal.