Sumo Robot Class Project

Navigate to and open "Library > sumo > IO > platform > init"

On line 16, change "Teacher" to your name.

Run the model in the simulator and see that your name is shown on the sumo ring in the simulator. If you need help running the Verifier and the simulator, see this guide

Your name will appear on the sumo ring (as marked by the arrow).

Reversing is controlled by a period of time. If the time period is shorter, the robot will not reverse as far.

Again, navigate to and open "Library > sumo > IO > platform > init"

On line 11, see that "retreat_duration" is set to 1.

Navigate to "Library > sumo > sumo > navigate > retreat_duration". Note in the "Properties" pane that the type of this class attribute is "integer".

Back in "IO::init" on line 11, change the value of "retreat_duration". Run the simulator and observe the difference in behavior. Experiment with this until you get a value you are happy with.

Turning is controlled by a period of time. If the time period is shorter, the robot will not turn as far.

Again, navigate to and open "Library > sumo > IO > platform > init"

On line 12, see that "target_duration" is set to 1.

Navigate to "Library > sumo > sumo > navigate > target_duration". Note in the "Properties" pane that the type of this class attribute is "integer".

Back in "IO::init" on line 12, change the value of "target_duration". Run the simulator and observe the difference in behavior. Experiment with this until you get a value you are happy with.

Time spent turning and reversing is time where the robot is vulnerable to attack. Times should be kept as short as practical in order to have a winning strategy.

In order to make the robot travel back and forth in a straight line across the ring, we will need to be a little more precise — 1 second turn is too short and 2 second turn is too long.

Navigate to "Library > sumo > sumo > navigate > target_duration". Let’s change this attribute from "integer" to "real" so we can achieve finer granularity in turning times.

Before changing the type of a model element, it is good to see where it is referenced to assure that changing the type will not cause unexpected changes in behavior.

Now that we’ve checked all the occurences of "target_duration" we can assure ourselves that changing the type from "integer" to "real" will not negatively affect the application behavior.

Navigate to "Library > sumo > sumo > navigate" and double-click to view the instance state machine. Note the 4 states:

Notice that the initial state (state with the lowest number) is resting. When the "pop" event is received, the instance enters the "attacking" state. From here the instance is in an endless loop where it attacks, retreats, and targets endlessly. The transitions between these states are dictated by timer and line detection events.

We can change the initial behavior of the robot by changing the transition from the "resting" state to any of the states in the loop. At the moment, it transitions directly to the "attacking" state.

Select the transtion from "resting" to "attacking", right click and delete the transition.

Use the palette to select the transtion tool. Click and drag to draw a new transtion between the "resting" state and the "targeting" state.

Right click the newly created transition and select "Assign Event…​". Select "pop" from the following dropdown menu and click "Finish".

Now when the robot is in the resting state and the timer pops, he will immediately start targeting before attacking. The new state machine should look something like this:

Run the simulator again and observe the change in behavior. Go back to "IO::init" and manipulate the timings to try to gain an advantage over the simulator.

Optional: try changing the model so that the robot reverses first!

In order to count the number of times the line has been detected, we must add a new attribute to the "navigate" class.

Right click the "navigate" class and select "New > Attribute". Give the attribute the name "line_detections". The default type for new attributes is "integer". We will not change the type as integer is good for counting.

With the new attribute selected, in the "Properties" pane, find the "Default Value" field and enter "0". This value will be assigned to the attribute whenever a new instance is created

Let us look at the state machine for the "navigate" class again. The instance transitions into the "retreating" state any time the "line" event is received in the "attacking" state. Here is a good place to insert our logic to count line detections.

Now we must add a way in the state machine to transition to a stopped state. We could create a new state for this purpose, or we could reuse the "resting" state. "resting" makes sense for what we will be doing so we will reuse that state. Additionally, this allows us to start the robot again if we wish by generating the "pop" event again.

Add a new transition from the "retreating" state to the "resting" state. Use the palette to select the transition tool, then click and drag.

Next, create a new event by right clicking, the blue canvas and selecting "New > Event". Name the event "halt". It is good to use a different event for each logically unique real world event. In this state machine, "pop" is always used with timers and "line" means the sensor has detected the line. The "touch" and "untouch" events are generated by the touch sensors. Now we have a "halt" event which signals an exceptional case.

Right click the new transition and assign the "halt" event.

In the "retreating" state action in the place of our "TODO" comment, generate the new halt event to self.

Finally open the "resting" state. Select the singleton instance of "drive" through R2 and stop the robot. In xtUML, the action in the starting state is not executed initially — it is only executed when transitioning into the state. Whenever we transition into the "resting" state, it makes sense to stop the wheels.

In order to alternate between turning left and right, we must add another new attribute to the "navigate" class.

Right click the "navigate" class and select "New > Attribute". Give the attribute the name "last_turn". The default type for new attributes is "integer". We will need to change this to be something more expressive.

Right click the new attribute and select "Set Type…​". Select "Orientation" from the type picker window.

Due to a limitation in the code generator, we cannot use default values for enumerated data types — we must initialize them manually. Navigate to "IO::init" and add this statement on line 13 under the statement which assigns "target_duration": n.last_turn = Orientation::left;

Now we must make use of this attribute in the state machine. First, nagivage to and open the "retreating" state action in the navigate state machine. We no longer want the robot to stop after 3 line detections, so let’s increase the number to 300. Now the robot should go for a long time.

Open the "targeting" state action and notice on line 4 that the "left" event is always generated to the steering instance. We want to generate "left" if the last turn was right, but we want to generate "right" if the last turn was "left".

Add a conditional statement here which reads the new "last_turn" attribute to introduce this new behavior. Remember that you must also update the value of "last_turn" to accurately represent the last turn that has occurred.

Now we will add some behavior based on the touch sensor input. For this demo we will simply cause the touch sensors to behave like sensing the line — the sumo will retreat, turn, and continue attacking.

In the "navigate" state machine, use the transition tool to draw two new transitions from the "attacking" to the "retreating" state. Assign "leftBumperPress" to one of the transitions and "rightBumperPress" to the other transition.

You can demonstrate the behavior by executing the interface signals "touchLeft" and "touchRight" in the "IO" port while the Verifier simulation is running. Injecting signals in this way is a good way to black box test applications without the need for hardware or a simulator. Important note: you must execute the signal on the "sumo" component and not the "Simulator" component.

Notice in the following animation how the navigate instance state machine changes when the signal is executed.

This particular behavior is not very strategic, but it helps you to understand how to use and test the bumpers. Explore with this to see if you can come up with behavior that does increase the odds of winning.

Now that you are familiar with xtUML modeling, Verifier, the Sumo Simulator, and the sumo application itself, it is your task to use what you’ve learned to create a strategy that wins. Be creative!

Here are a few tips:

In your commit message, describe your strategy.

Implement a sequence of moves (a "dance") that your robot goes through when he has won. This is meant to be a fun exercise so be creative!

Hint: detecting when you have won may be difficult. Consider the case when the bumpers are depressed and the line is detected. If an object is pressing on the bumpers and the line is detected, you can be relatively certain you just pushed the other robot out of the ring. This is a good way to detect a win.

In your commit message, describe your victory dance.