Stuck MonsterBorg detection code fixes

Over the last two MonsterBorg heats, we've seen a lot more accidents. A lot of this is obviously due to the faster speed, but a closer investigation showed that when a Monster class had an incident, the chances of recovering were lower than that of the YetiBorg. With the additional power of the Monster, we had thought that this would be the opposite - for example, the Monster can flip itself over easier, but being in the upside-down isn't quite as detrimental.

A bit of analysis showed a couple of interesting facts;

1. That the Monsters once stuck, seemed to go quickly to another stuck state
2. That the Monsters were more likely to flip on the walls especially later in the racing
3. That the larger size of the wheels meant more chance of sticking to a barrier (especially on the 100mm high sections)

We maintain that the best strategy is avoidance. The standard MonsterBorg code has very little in the way of detecting other robots, and favours a "flat out" approach which should give terribly inconsistent results.

So one improvement that we can easily make is in the first point - the stuck state detection code.
The exsiting code is mostly a copy from the YetiBorg code, but this doesn't account for the addtional speed. The Monsters have 300rpm motors rather than 180rpm. And the wheel sizes are larger too (from ~80mm diameter to ~100mm diameter).

So what would the stuck detection code do?

1. Realise that the camera image is not changing from frame to frame
2. Go back 75% of the track width by putting all motors in reverse for a period of time (1.5 seconds)
3. Turn approx 45 degrees by putting one side in breaking whilst leaving the other side in reverse (0.8 seconds)
4. Determine if facing right or wrong way by looking immediately below the camera for a RED or GREEN lane
5. If facing the correct way go back to standard navigation
6. If facing the wrong way, spin 180 degrees and go back to standard navigation

Here's a video of that working



So what happens when we run this code on a MonsterBorg? Well, it reverses too far and then turns too much, so it gets quite confused. See this video for example.



If we simply change the period of time to compensate for the extra speed, we get very different results. For example changing the reverse time from 1.5 seconds to 0.7 seconds, and the turning time from 0.7 to 0.4 seconds gives this sort of result:



Much better! So the code to change is in Settings.py in the override system settings section:

# Override system settings
stuckIdenticalSeconds = 1.0			# Number of seconds with near identical frames before deciding we are stuck
stuckIdenticalThreshold = 2.00		# Level at which two frames are seen as identical
stuckOverrideSeconds = 0.7			# Number of seconds to reverse for when stuck
stuckHuntSeconds = 0.4				# Number of seconds to hunt for the track after reversing when stuck
stuckDetectColourWidth = 0.5		# Position in the image along X to look for the track colour
stuckDetectColourHeight = 0.9		# Position in the image along Y to look for the track colour
flipDetectionSeconds = 0.3			# Number of seconds with frames which seem flipped before inverting movement
flipDetectionThreshold = 35.00		# Minimum gain between the background and the track
wrongWayThreshold = 10				# Number of wrong-way points before deciding to turn around
wrongWaySpinSeconds = 0.8			# Number of seconds to spin when the wrong way around
overtakeThreshold = 36				# Number of unexpected points before deciding there is a robot in front
overtakeLaneOffset = 1.0			# Lane shift away from the robot in front when overtaking
overtakeDurationSeconds = 3.0		# Number of seconds to overtake for
overtakeBrakingSpeed = 0.7			# Speed percentage to slow down to when starting an overtake
overtakeBrakingSeconds = 1.0		# Number of seconds to slow down when overtaking

Limitations:
Of course this isn't the only improvement we could make, but as this is a competition, we want people to come up with their own ideas. Some other limitations of the standard code that you might come across include:

• The detection logic for when the robot is stuck doesn't accomodate for camera shake
• The robot could keep driving into the wall and flipping, so the scene is never stationary - we've seen that a couple of times
• When driving too far from the center of the track the code fails to detect if it is drving the wrong way - this is a big problem for those taking a tight inside line who get spun around
• The overtaking logic may try to pass the robot in front on the inside / outside when there is not enough room, causing a crash into the wall
• It is possible to get beached on the inside wall if you are driving too close and get hit by another robot