They changed the language on the KOP page. It now reads:
Instructions are also available for importing a 2017 field model and exporting robot models from Solidworks to use with the simulation environment.
I created a very poor version of the field using the Solidworks URDF exporter. I’m not certain the dimensions are accurate (I used the Solidworks field model, but I’m not sure if that has been updated with some of the rule clarifications that have been made).
I am not a CAD guy, so I barely know what I’m doing, and this is recognizably poor quality. But it seems to be working for us.
Thanks for posting this Jeremy! I am sure this helps several teams. I was able to insert (and drive) PacGoat in this world. For some reason GearsBot is not happy in this world (for me), but this world is a good start.
In other news, I started playing with Gazebo 8 (still on Linux). The latest release Gazebo roadmap shows Windows support in v9, so I setup a new VM with Ubuntu 16.04 (Xenial), Gazebo 8, Eclipse Neon, JDK 1.8, and WPILIB 2017. I did recompile the simulation tools so they will work with Gazebo 8. I got GearsBot to work with Java, but I ran into issues with C++ (which is unfortunate since this is what my team wants to use). I will make another post with some details/gotcha of my installation.
My hope for it was to test autonomous code. Even though it will not exactly map 1:1 with the real world, it should give the programmers a place to test concepts before having a physical robot to test on.
Of course, that also assumes the code is ready…and that you have a robot model that is somewhat close to real world proportions.
Exploding robots is just one of the fun challenges you are going to face. The models exported by solid works are a good start, but are usually imperfect. It took me many nights and a lot of hours to get a model that would work. I ended up having to learn SDF format in detail, and make sure I had inertias for everything, and really thoughtfully analyzing the whole model. (For the exploding robot, slow time way down; you can see when the explosion starts, and sometimes get a clue as to which part is causing it).
Not trying to be a debbie downer, but from there, you will then swiftly find that wheels are not easy to model in Gazebo. You may have better luck with that than I, but I pretty much could not get gazebo to model a drive train with realistics physics. Some googling persuaded me that is hard (there are PHDs that do that for a living).
Our lead programmer wrote a specialized plugin to inject movement to simulate mecanum wheels; it works so-so for us. He’s crazy stressed with final stuff before bag day, but I’m hoping to persuade him to release it as a paper.
But again, it is not for the faint of heart; it requires custom compiling a new plugin. It will take someone with fairly good Linux fu and a lot of patience to get you a driving simulation.
So, I think we are getting some value from frcsim, but it was only after a far larger effort than was expected. Consider yourself warned :-/.
I second Jeremy. I think there is a lot of potential here, but it takes a lot of effort to do something useful. My hope is that getting a Windows version will remove one level of installation complexity.
I was able to insert and drive the “PacGoat” model in the STEAMworks world. GearsBot did not work so well.
WPI folks did a Conference session and demo at Worlds last year, and that has inspired me to embrace FRCSIM. At the Conference session (http://wp.wpi.edu/wpilib/files/2016/05/FRC-Gazebo-Presentation.pdf), they did mention that complex mechanical systems are too much for Gazebo simulation. The example they used was that tank treads did not work well, but you could emulate their effect by having multiple small wheels than mimic the shape. And like Jeremy said, the robot models exported from SolidWorks also take some SDF tweaking to work right.