The 2016 Taiwan Micromouse and Intelligent Robot Contest was held on September 11th at Lung Hua University and I was there. I won’t bore you with the whole travelogue. Just some of it. Here are the results to start off.
The Classic Micromouse contest attracted 22 entries form Taiwan, Singapore, Japan, China, USA and, of course, the UK. As usual the maze was impeccably well put together thanks to the days of preparation by the dedicated team of helpers at the contest. If you have been following the micromouse contest over the past year or two, it will not have escaped your attention that the fastest mice are now those with a suction fan. That is not to say that the suction mice are the fastest. However, if you can build a fast, reliable mouse and then add a suction fan, your chances of success will be greater. Otherwise, well, your mouse just sucks.
I know – I can’t help it.
Anyway, this year’s maze was interesting with two principal paths. The longer, upper path was much longer. I believe it was about 2500mm further than the lower, more twisty route:
The winner went the long way round and second place took the shorter route. I also took the sorter route. This was a surprise because I think I would have been faster on the longer route and my desktop solver – which is supposed to be identical to the one on the mouse – indicated that the longer route was better. No point in fussing over it now. i will double check the parameters later.
The abbreviated results are shown in the table below. The winner was Utsunomiya Masakazu of Japan. He was the first to win with a suction mouse and is not letting anyone else beat him if at all possible. Second place went to Cai, Xin-Han with DiuGow 4 – another suction mouse. DiuGow only managed one speed run before mysteriously stopping and was then retired from the contest. Remember that Taiwan rules give a weighting for search time, one good speed run early on counts for a lot and Utsonomiya-san’s Siden Kai was significantly quicker.
Decimus 4E came in fifth. i chose a fairly conservative first speed run but, as it turned out, even if I had put in my best speed run first, I may not have improved my position because I still have a stupidly thorough search algorithm that took way too long to decide it had the best route.
Name | Best score | Rank |
紫電改 | 00:08.299 | 1 |
DiuGow 4 | 00:08.441 | 2 |
Excel-8 | 00:10.149 | 3 |
MIN 7.2 | 00:11.430 | 4 |
Decimus 4D | 00:13.598 | 5 |
大專第二名 | 00:15.606 | 6 |
大專第三名 | 00:15.837 | 7 |
Red-Comet | 00:16.502 | 8 |
Wa-Zai | 00:17.266 | 9 |
Zeetah VI | 00:18.001 | 10 |
Min 7.1 | 00:19.914 | 11 |
Yukikaze-5.5 | 00:22.183 | 12 |
Greenfield++ | 00:25.368 | 13 |
Barracuda | 00:33.271 | 14 |
Excel-9 | 00:33.274 | 15 |
P-Kojimouse | 00:36.367 | 16 |
Megatron | 00:36.395 | 17 |
_dbHu_ | 00:45.056 | 18 |
閃電麥昆 4.0 | 01:08.912 | 19 |
Fairy | 01:09.682 | 20 |
天津大学代表队 | x | x |
Ants | x | x |
The half-size contest had 14 entries. I have the results shown below. Note that fastest time is all that counts in this event and that, where a contestant entered more than one mouse only the fastest could gain a ranking in the results. Thus, where you see an unranked mouse with a short time, it was beaten by a stablemate from the same builder.
Since I have no half-size maze editor, I cannot reproduce the maze or its routes.
隊伍名稱 | Best score | Rank |
Kojimouse11 | 00:03.594 | 1 |
Ning6 | 00:03.723 | 2 |
翠嵐 | 00:03.767 | 3 |
Mini-4 | 00:04.525 | 4 |
Mini Diu-Gow | 00:05.387 | 5 |
U-point | 00:07.770 | 6 |
Mini-3m | 00:04.638 | x |
Kojimouse10 | 00:03.860 | x |
Ning6.1 | 00:05.060 | x |
Alexus | x | |
Japan(private) | 00:24.274 | |
Shinning | 00:29.431 | |
LoLe | 00:45.837 | |
Karakuri-Kobo A:Mac | 00:09.004 |
For full data and maze images, you should visit Green Ye’s page.
Classic contest Winner:
Classic contest second place:
Half size Winner:
Line Follower expert class winner:
For more complete details of the top entries and the rest of the contest details visit the official contest page.
I think the bottom right part of the teal path for classic size maze should go with the diagonal instead of 2 of 90L turns.
You are right. My software picks all kinds of paths and I had not noticed that was unoptimised. Thanks for pointing it out.