YousafRaja/GSoC-FinalEvaluation.md

## GSoC-FinalEvaluation.md

      
    Raw
  

              GSoC-FinalEvaluation.md
            
          
    Official Repo Link: https://github.com/robcog-iai/URoboSim/tree/master
I mainly worked on the URoboSim plugin, building on the work from a previous student's project. My first goal was to expand upon this plugin so that it could import a full pr2 robot into UE4. I began by generating a pr2 URDF in ROS which only contained the base of the robot (just the lower part of the robot with the 4 caster wheels). However this required much further refinement since the pr2 robot had many more details than the original parser expected. So I programmatically parsed the pr2 base file and removed most things that were not a link or a joint and made some tweeks to the parser to make it more flexible.
The pr2 consists of mostly meshes which are either in .dae or .stl format. The next step was figuring out how to convert these meshes to UE4's .fbx format. For this I used blender and I've written the exact steps in the URoboSim wiki.
Next I was able to load something into the game except it did not appear to be the pr2 base. The caster wheels were at the correct height but they were all in the center. This was confusing to me because the original parser had a similar example on how to handle meshes (see the Bender URDF) and all the meshes were being loaded perfectly in place. Eventually I realized that the units on the Bender example were not URDF units, they were already fit for UE4. After scaling all joint location information on the pr2 base by a factor of 100, all wheels fit perfectly in place.
However, there appeared to be some self-collision between the wheels and the base. Enabling physics sub-stepping helped reduced the severity of the problem but did not eliminate it. I went into RRobot.cpp and adjusted the collision properties for the wheels so that they would not collide with the robot but still would collide with the rest of the static world.
Now that I was able to load the base of the pr2, I added the torso (again limiting myself to mostly links and joints and making exceptions for self-colliding joints) and then finally the grippers. With the grippers I encountered a new issue; the fingers appeared to be crossing into each other. Around this time I submitted the first pull request before the first evaluation.
I thought the issue might have had something to do with the robot's transmission tags which were removed earlier while simplifying the URDF file. Eventually I realized that the exported left finger actually looked like a right finger. I exported the finger meshes again but this time flipped them and then everything in the pr2 was loaded correctly.
Although we could import the PR2, it behaved more like a rag-doll than a robot. So the next step was in seeing how I could make the joints more rigid. I enabled the angular motors for the joints inside RRobot.cpp and after much trial and error had rigid joints but not rigid enough since the robot's arms wobbled. However, angular motors will have to be disabled once the robot is being controlled from ROS so for now this was a good enough approximation. Around this time I also began merging my project with Yi Long's UROSBridge plugin and began testing it on Windows. This is also when I changed the parser from something that could parse a very simple xml file to a full URDF file.
In hindsight, my approach of importing the pr2 one small piece at a time worked out well. As I began slowly adding URDF components back in, I encountered more issues but I was able to isolate them and solve them one at a time. For example, collision tags, in particular the ones with a cylinder shape, were causing issues (which I discuss in the wiki). There were also some tricky special cases which I have pointed out in the code's comments.
Lastly, I had to modify the xml parser to handle files ending with .URDF and to handle .stl and .dae as if they were .fbx. Eventually I was able to just drag and drop the original URDF into the project. This was roughly the state of the project before second evaluation.
I then moved all the robot's links into their own collision channel and disabled self-collision by setting links to ignore this channel. This will allow the robot to collide with other objects which are not part of the static world (i.e. moving tables). Another issue that came up here was that the wheels had an octagonal shape for collisions instead of a smooth cylinder. I discuss how this issue was solved in the wiki.
The next major phase was in implementing sub-stepping and the visual interface. I explain some of the purpose and motivation behind this in the wiki. For sub-stepping, I made the RStaticMeshComponent class which essentially inherits from UStaticMeshComponent and overrides key functions. At the moment there's no input coming in from ROS with which this could be tested so I applied a simple upward force of my own just to show how it works. This is actually a property which can be tested by clicking the Enable Substep checkbox and is part of the actor and not the visual interface.
The visual interface is inside the URoboSimEd module. Earlier I mentioned how collision properties had to be adjusted on certain meshes to prevent self-collision. Now this part of the code can be adjusted from this menu. This is very important for two reasons: First, now a user can adjust these properties for any robot without knowing anything about the code. Second, with the visual interface, one can experiment much more quickly without having to restart the entire project over the slightest change. Also, the highly modular nature of the visual interface will make it very easy to extend it in future work to include more options.
In terms of future improvements, more work will need to be done inside the substepping functions to enable the use of real robot controllers from ROS, because they run at a higher frequency. Not all functions can be called from within a substep tick and substepping can only be called on components that have a rigid body. In other words, it can be called from the links but not from the joint. More details can be found in the Wiki.