This demo helps you apply the key features of Simulink that are discussed in the "Introduction to Simulink" webinar
The demo was specifically built using the features and concepts that are shown in the webinar; modeling a simple continuous system, adding nonlinearities, including documentation, using subsystems, masking, model reference, buses etc.
If you are new to Simulink, it is recommended that you watch the webinar before you try out the exercises and look to implement new strategies for the game.
Additional notes accompanying the demo. These notes have been intentionally kept fuzzy and listed in random order as it is expected that you will explore the model to understand all the components and their interaction with each other.
1. The demo simulates a 2 vs. 2 robot soccer match. The robots are assumed to be heavier than the football. Thus, any collision between the ball and the robots is perfectly elastic. The robot’s motion is not impacted by the collision.
2. Collision among robots is not implemented as they are considered as point masses.
3. Collision modeling in all cases is assumed to be as a spring contact model. When the object colliding with a boundary comes close to that boundary, a force proportional to the negative of the "penetration distance" is computed.
4. The strategy subsystems are implemented as referenced models. This was done intentionally so that competing teams could protect their strategies and run the simulation against each other. You can use the model reference protected mode to generate a mdlp file instead of mdl file (introduced in R2009b):
5. Robot dynamics are simple dynamics of a point mass. However, the mass is inversely proportional to the battery power or "stamina" of the robot. Some damping is also put into the system to avoid too much overshoot. Also, each time the robot actuates itself or brakes, it incurs a small power loss thereby lowering its endurance in the game.
6. Positional coordinates in the system are 2D i.e. (x,y). The signal dimensions have been set explicitly. Click on any of the output ports->signal attributes of the masked subsystems to see the dimensions.
7. Ball dynamics has a simple implementation- same "spring-based" contact dynamics. From the ball's point of view, there are five contact forces to be accounted for: contacts with the 4 robots and those of the boundaries.
8. Observe that the solver has been changed to ode15s which is a stiff solver. The reason for this is that there is stiffness present in the system because of the contact/collision modeling with high spring constants. This can give rise to modes with relatively different dynamics. With a ode45 solver, the faster modes will force the adaptive solver to take smaller steps slowing the simulation down. ode15s ignores some of these fast dynamics.
9. All the icon drawing commands on the robot dynamics subsystems were implemented using the MATLAB patch commands. These were taken from the flags demo by Mike Woodward:
Use other flags to customize this.
10. 2D animation was done using Simulink 3D Animation. The field was textured with a grass image and a viewpoint was so selected so that it looked as 2D. The "GOAL" text was kept behind the field. The moment, a goal is scored, this text is translated to the front giving a TV effect. Texturing was also used to paint the bodies of the robots with the flags. You will have to change the images in order to change these.
11. Play around with the strategy subsystems to see if you can come up with efficient strategies to score goals early. Note that each of the teams has full knowledge of the others' positions and those of the ball. They also have knowledge of the remaining power in their team's batteries. There is no velocity information available.
12. You need Simulink 3D Animation installed to view animation.
Exercises for you to try out:
1. How can you use Stateflow to implement a finite state machine that uses a mix of attack and defensive strategies based on ball location?
2. What block in Simulink should you use to input a new signal into these strategy subsystems so that time elapsed since the start of the game can be measured and hence be used as part of the strategy?
3. Identify the contents inside the MAT file used in the demo. What is the "type" of the contents of the data inside the file? Identify the function that loads this MAT file. Why did we need these data objects in our model?
4. Explore the possibility of using control strategies, like PID, to improve robot tracking
Although it sucks first but again it ends well. good job
I have error when I ran RoboSoccer.mdl
>>Error evaluating parameter 'OutDataTypeStr' in 'Team_1_Strategy/Power': Undefined function or variable 'Bus_Power'.
>>Error evaluating parameter 'OutDataTypeStr' in 'Team_1_Strategy/Robot Position': Undefined function or variable 'Bus_Robot_Positions'.
Thanks for such one good code.
Starting in R2010b, the Bus object specification is unified into Datatype specification. This and a stricter interface requirement for Embedded MATLAB can lead to errors when running the demo in R2010b. We updated the bus type specification of input ports in the Strategy reference models and added a Bus to vector before Embedded MATLAB processing. Also note that the Bus Power signals from team subsystems to the strategy ref. models are currently unused. Someone can use this for advanced strategies.
Please look for the r2010b folder for the version to use with r2010b.
A variety of videos on robot soccer that show similar games:
The author would like to acknowledge help and support from Parasar Kodati in improving and debugging this demo:
Starting in R2010b, the Bus object specification is unified into Datatype specification. This strict interface requirement for Embedded MATLAB can lead to errors when running the demo in R2010b.
Added the link to the recorded version of the live webinar.
Minor bug fix.
Fixed minor coding bug.