I can imagine that once the race starts, cars will end up hitting each other. When that happens, cars will be pointed in all different directions or even possibly stuck together. How do you handle those situations? Is it just luck for the winner that they do not contact others?
We expect a fair amount of contact between the robots over the course of the race.
The robots should try and recover from problems and keep on racing :)
The best examples will try and avoid collisions as much as possible.
The YetiBorg itself is also designed to take some bumps and bruises.
They are rather robust and we have even seen one drive over the wheels of another to get by.
To keep the robots going our standard example has some features to help with this already:
This will reverse a bit and try again when the YetiBorg cannot move forward.
It should handle getting stuck on a wall or on other robots.
This is explained in our How can a robot tell it is stuck? blog post.
This will realise the robot is flipped over and do two things:
A. Flip the camera image for the image processing
B. Reverse the controls (left/right and forward/backward)
The YetiBorgs are designed so they can run upside-down.
Alternatively you could intentionally drive at the wall to flip yourself back again.
There is a simple level of avoidance code in the example to try and steer around obstacles.
Ideally a proper overtaking routine can be written, but the standard code will avoid a large amount of possible collisions.
This will see that the track colours are the wrong way around and try to spin the YetiBorg 180°.
Without this the robot gets confused and drives into the wall by mistake :(
Even if the detection fails here feature #1 should get the YetiBorg up and racing again.
We believe this will allow competitors to have different strategies for winning, such as:
We have some more detail about detecting and handling flipped robots in our latest blog post: How can a robot handle being upside-down?
Add new comment