First off, let’s briefly define what a simulation is. In regard to Microsoft Robotics Studio (MSRS), a simulation is a mathematical computer model that is used to represent one or more physical objects. Data is fed into the model, and the result may or may not be rendered to create a visual three-dimensional (3D) image. Sounds complicated? Well, in some ways, it is. But if you have played any recent software games, then you already have experience using a simulation. Today’s high-powered video games are nothing more than elaborate simulations involving characters that the player is able to control. This chapter will assume that, although you may have played a game or ran a simulation, you have not actually created one yourself.
If you skimmed through Chapter 2 and thought none of it was very important, think again. In fact, you might want to go back and review it so you will not get lost in this chapter and the chapters that follow. Even though this chapter deals with a visual tool, it is not similar to the chapter on Visual Programming Language (VPL). VPL primarily involves dragging and dropping blocks onto a design surface. This greatly simplifies the process of creating a robotics application because the majority of code is generated automatically through the tool.
The main component of simulation is not a tool but rather an engine; an even more accurate description is that the simulation engine is a service. To create a simulation, you first create a Decentralized Software Services (DSS) service (like the ones created in Chapter 2), and this service will use the simulation engine as a partner service. This chapter will cover how to create a simulation and work with entities. This will include working with the graphical editor provided with MSRS and also creating a simulation using a DSS service.
The biggest benefit to using a simulation tool for robotics is that everything is virtual, and you do not need to have an actual robot. For programmers working with expensive robots, this can be a huge advantage. This is especially true when work is done by a group of programmers who each need time with the robot. With the simulation engine, each programmer can create his or her own simulation service and work with the robot independently. The programmer can carry out experiments and see how the robot reacts to different scenarios.
This can also be an advantage for students or hobbyists first learning about robotics. In the past few years, there has been a shift toward including robotics classes, not only in colleges, but at the high school level. Not all of these educational institutions can afford a robot for every student. The institution might be forced to work with a simple robot just because it is more affordable, but it may not be what the instructor would prefer. By using the simulation engine, students can work with a wider variety of robots.
One last benefit to consider is the opportunity to prototype a new robot design or experiment with a new scenario. Robots can be very expensive, and, rather than risk damaging the robot, a programmer can first experiment with a simulation rather than working with the actual robot. Some of today’s robot competitions require robots to navigate through a complex obstacle course. These obstacle courses can involve multiple levels, and robots can fall off platforms or run into objects or other robots. The simulation engine can be used to design a navigation path for the robot before it attempts to navigate the actual course. After the code has been stabilized, a simple manifest change will enable a programmer to use the same code with an actual robot.
Now, I would be remiss if I did not mention the drawback to working with a simulation. Oddly enough, it is the same reason that it is a benefit. Because the simulation is virtual and does not involve a robot moving about in the real world, it is not always representative of an actual environment. The real world is messy and full of unknown variables. A simulation involves predictability with known constraints, and this is not always the case when working with real robots. Consider, for example, an infrared detector, which robots commonly use to measure distance. This simple sensor can easily be triggered by fluorescent lighting in a room. Therefore, when bringing a robot to a new environment, it is advisable to first test the sensor within the room to ensure that it is not triggered by an overhead light. This is the type of noisy data that simulations do not take into account.