ABU Robocon 2021

Synopsis

ABU Robocon 2021 was originally scheduled at Jimo, China and the game was based on the traditional game of East Asian countries pitch-pot (投壺), or throwing arrows into a pot. In this game, each team designs two robots. The Throwing Robot (TR) can pick up arrows and throw them into the five pots located on the field, but is restricted to moving along the outer area of the field. The Defence Robot (DR), in addition to throwing arrows from the outer area, can navigate through both the outer and inner area of the field, rotating pots, blocking throwing attempts of the opponent, or handing leftover arrows on the field to the first robot. Teams score points based on the number of arrows thrown into each pot; but if a team scored two arrows in each of their five pots, they achieve Great Victory which immediately ends the game.

The above image shows the Robocon 2021 game field. Each team owns half of the field.

Experience

Unlike last year's Robocon, this year's game is more competitive and dynamic. Teams can block the opponent's arrows and spin the tables in the middle, denying the opponent points.

Having gained one year of experience, last year's juniors (me included) have been promoted to seniors. We've also recruited a new set of juniors interested in the HKUST Robotics Team experience. Each year, HKUST Robocon deploys two teams: "Fiery Dragon" and "War Dragon". I joined the Fiery Dragon team again.

This year's game was held face-to-face with audience bleachers, seats for sponsors, etc. The entire atmosphere was quite competitive and heated (in a fun way), unlike last year.

Team Management

The most common leadership style I've observed in Robocon history is to appoint one leader and have him/her manage the entire team—although with some delegation, e.g. letting hardware seniors manage hardware juniors at a closer level. However, this style did not work for our team as our seniors had rather high expectations of leadership.

Instead of a single leader, we distributed our leadership among the five seniors, each taking on roles according to their strengths. Some were better regarding mechanical matters (e.g. sourcing, design) and took care of the mechanical division. One had a clearer vision and goals regarding the software aspect, and oversaw the software juniors. Another was better at public speaking and handled interviews from local media. I was better at note-taking and was more organised—well, only in some aspects—so I organised some meetings, took notes during meetings, and made announcements to the team WhatsApp group.

All seniors had some juniors to mentor. But mentoring is a struggle. Even with a clear list of tasks to complete, I sometimes need to push my juniors to complete their responsibilities.

I am not the best when it comes to dealing with people. There are many different characteristics a person might have. They might be loud. Full of ideas. Extremely enthusiastic. They might be obstinate, perhaps a bit stubborn. They might be quiet. Soft-spoken. They might dislike criticism. Some might not budge until told to do so. To work effectively, we need to keep these characteristics in mind and sometimes adjust the way we speak. To me, this is a very taxing mental process, but I think it gets things done more effectively.

Tensions occasionally spark among certain team members that have this... magnetic repulsion against each other. One member would disagree with another member's modus operandi. If the latter member is resistant to change, then be prepared for more friction and pent-up frustration. It helps to talk with them, to mediate between arguments.

Although the notion is slightly cynical, maintaining good mental health among teammates goes a long way. Put another way, caring for others is important. Since we are all students, we all face the pressures of HKUST's culture, the pressure of assessments and exams, pressure from family, etc. Again, I am not a people person, so it was tough learning how to converse and say the right things—I'm still learning as I write.

Technical Side

More learning. Yayyy. We tested some new interesting sensors and slowly moved R&D projects along. When it comes to coding the robot, initially, us software seniors did most of the heavy lifting, guiding juniors along the way. Towards the end, we gave juniors more responsibility in adding features and testing new mechanisms.

Since this year's game is a lot more dynamic, we need to be open-minded about our opponents' strategies and keep our strategy flexible as well. This year I worked on the Defence Robot (DR). This was one of the keys to our flexibility in the competition. (Another key was our dedicated gamefield members.)

In the picture above, the DR is outfitted with three main weapons:

1. A claw to latch onto the handles of a spinnable table. This allowed for precise control of the table's angle.
   • We didn't end up using this too much, since latching on and off takes quite a bit of time.
2. A bumper to smash the table handles to quickly spin it. Shock-resistant pads were added on the sides to soften blows from the left/right so that the robot doesn't tilt.
3. A "choppy" mechanism for slicing and dicing incoming opponent arrows.
   • The idea is to knock opponent arrows out of their trajectory in a horizontal chopping motion.
   • We also rarely used this mechanism, since we realised it wasn't too effective. And also, using this mechanism means we need to allocate one arrow from our supply of 20. The benefits did not exceed the costs.

So in the end, we mostly relied on our DR driver's skill and not on the complicated mechanisms. However, besides the driver's skill, having a good design was necessary. The robot needed to maintain a low centre of gravity so that it was less susceptible to tilting. Tilting would cause at least one wheel to be lifted off the ground, and the driver would need to wait for the robot to "untilt" to continue driving effectively. So tilting was a big no-no.

To an extent, the workload of a software member depends on the robot design of mechanical and soldering of hardware divisions. A poor joint design may lead to ineffective fixes via software. Poorly soldered boards or power management may lead to power cuts or shortages in the robot. Indeed, technical skills of members are important, but to alleviate the issue mentioned, proper communication and a clear vision is also required for a software member. Don't sit around when you see a confusing pin wiring configuration or loose panel. Suggest changes. Discuss ideas.

In last year's game, we relied more heavily on automation, since the situation was mostly static (placing balls in the same place), plus all the paths were the same. This year, with a dynamic game, we relied on more manual control. And this meant more practice and sweating for gamefield members.

Concluding Remarks

Through the dedication, hard work, and intense training of our team, we managed to obtain 1st place in the competition. (In fact, we tied with one of CUHK's teams... in a... somewhat controversial finale.)

In my Robocon 2020 reflection, I mentioned experiencing the team gestalt, of how a united team is greater than the sum of the individuals comprising it. This year, I had the rare opportunity in maintaining and nurturing the gestalt, or in other words, the team spirit. This doesn't mean that only seniors can nurture the team spirit. Everyone has a part in it, and it can be shown through various means (dedication, organisation, etc.).

Looking back I am grateful for the experience and opportunity of learning soft skills and management skills from the HKUST Robocon team. There were some things I might have done differently, such as talking with other teammates more in order to understand their position better and to care for them better. But working with people is tough, and can be beyond annoying >_<. It requires a lot of patience, one that I hope to steadily improve.

The Ultimate Defence Robot

As I was proofreading this piece of writing, I realised I haven't come up with any good memes. Suddenly, I received a vision for the ultimate defence robot. I propose the following blueprint: