Home
In this documentation we will present all the technical aspect of our robots and the choices we took over the years while participating at Eurobot / Coupe de France de Robotique. Everything mentioned bellow can be subject to debate and only represent our experience and impressions.
Some sentences might seems hard, saying that "you need to do so", don't get them wrong, you should be able to participate with a robot that do not comply with the sentence, and you'll have a lot of fun, but robots that comply have a higher chance to do want you want, and thus make your brain deliver more of those precious chemical awards.
But first, here are videos of games were you can see how our (white) robot behaves:
| TDS Team 72 vs RCVA | TDS Team 72 vs AZBOT |
|---|---|
 |
 |
To have great level of performances, the robots should solve the following challenges:
- Displacement [MECA+SOFT]: Might seem obvious, good displacement capabilities are key to move the precious actuators to the things that need manipulation. If displacement is not reliable, there will be no usage of the other robot capabilities.
- Localization [ELEC+SOFT]:: Might seem obvious, but often too much ignored, knowing (and not guessing) the position of the robot is key to perform any action. The vast majority of team uses relative technics rather than absolute ones, but this growing error that comes with relative technics is a source of many frustrations.
- Intelligence [SOFT]:: The capacity of a robot to detect a situation and react is key. There is always a ton of things to do, so waiting for a collision avoidance, or having a too limited set of action will prevent the robot from doing what you want. The robot should be fed with a large list of possible actions, each associated to activation conditions. The robot should be able to move to the desired location even if there are obstacles to avoid.
Answering all the challenges in a single year is more than extremely difficult. We'll recommend to follow the order above in your development goals even if it takes more than a year. Once a challenge is clear you should have worked so the solution can be reused the next year, even by other people.
Software is always the limiting resource Software always have to be in the loop at some point, there is a ton of subject to cover, and actual tests with hardware (called integration tests), will come late in the project. So you should always take decisions that will simplify the software task. Saying "this encoder offset will be fixed in software" or "this sensors will be filtered in software" are feasible sentences, but will reduce more than you imagine the capabilities of your robot, due to the added complexity and the time wasted on this software fix. If the software people are resolving other issues than the challenges above, this will impact the end result of the whole team.
Some other topics might seem like important challenges but are not:
- Actuation: Great actuators are often extremely simple. Best actuators combine large tolerances and reliable manipulations. Without actuators, a robot can often still perform a lot of task thanks to its displacement capabilities and minor mechanical hacks, so actuators should not be a priority.