You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The easiest cross-platform + cross-language interface is a web browser, so what we do is build a web server into a special version of WPILib (or perhaps in a secondary executable that pretends to be a gazebo server, depending on how it works out), and that web server updates its webpage dynamically depending on the state of the robot.
The UI would be written mostly using HTML/JS, so that the same functionality would be identical to use in Python, Java, and C++ robots.
Users could click on the web interface to activate various sensors, and things like motor output would be shown in the interface as well. Additionally, a field would be shown, and the robot could move around in 2d space based on the motor output (I already have the motion equations working for pyfrc).
I theorize that the primary usefulness that programmers will get from a simplistic simulator is "whether or not the thing moved when I told it to move". To enable this, the simulator has a library of simple animations that you can enable, and 'attach motors or sensors' to it, and the animation will move when your robot code makes it move. All of the animations would be written using HTML/javascript, and it would be trivial for users to add their own animations for more complex simulation. The types of motion that would be originally supported would be:
Circular motion about an axis using a motor
Solenoid piston action
Linear motion using a motor
There are other types of motion that should be trivial to animate, but I still need more thought on this.
The primary advantage to this type of simulator is that it wouldn't require creating a precise CAD model of the robot to get started, and if the library of available animations is general enough, would take a user maybe a half hour to get setup and ready to test things.
The first implementation of the simulator would be in pyfrc, which is why that issue is here.
The text was updated successfully, but these errors were encountered:
Ideally, this will be driven by the simulation HAL in 2015. The dictionary containing all robot data will be pushed up to the simulation and rendered onto the interface somehow.
The easiest cross-platform + cross-language interface is a web browser, so what we do is build a web server into a special version of WPILib (or perhaps in a secondary executable that pretends to be a gazebo server, depending on how it works out), and that web server updates its webpage dynamically depending on the state of the robot.
The UI would be written mostly using HTML/JS, so that the same functionality would be identical to use in Python, Java, and C++ robots.
Users could click on the web interface to activate various sensors, and things like motor output would be shown in the interface as well. Additionally, a field would be shown, and the robot could move around in 2d space based on the motor output (I already have the motion equations working for pyfrc).
I theorize that the primary usefulness that programmers will get from a simplistic simulator is "whether or not the thing moved when I told it to move". To enable this, the simulator has a library of simple animations that you can enable, and 'attach motors or sensors' to it, and the animation will move when your robot code makes it move. All of the animations would be written using HTML/javascript, and it would be trivial for users to add their own animations for more complex simulation. The types of motion that would be originally supported would be:
There are other types of motion that should be trivial to animate, but I still need more thought on this.
The primary advantage to this type of simulator is that it wouldn't require creating a precise CAD model of the robot to get started, and if the library of available animations is general enough, would take a user maybe a half hour to get setup and ready to test things.
The first implementation of the simulator would be in pyfrc, which is why that issue is here.
The text was updated successfully, but these errors were encountered: