This part of the story is going to be interesting. In the first part I talked about our first attempt to participate in the competition and how we eventually lost. In this part, I am going to list a number of mistakes that I personally committed while leading the team that year. I am also going to be talking about our second attempt – our second year – and how the team was assembled, hardships we faced at the beginning, our work process and finally, about mistakes we made in that year. Hopefully, this is going to be a motivation for the last part in this story which will be about Hydrobots team itself and how all those past experiences helped in making it a better team.
So let’s begin ..
What I did wrong in the first year ..
I was the leader of Future team. I wasn’t quite fit to be a leader. This is what I can see now very clearly. You know, leadership is not about who is smarter or who knows more, it is mainly about managing people. The main target of leading people is “How to make the people you lead give you 100% of what they truly can give ?”. Leadership is about “How to affect people to follow you?”. There is a lot to say about this point.
What I want to say here is that I was novice and inexperienced, especially in dealing with people. I used to be an introvert, seldom to deal with other people; so how was I supposed to manage other people? Anyway, I did it, but of course the wrong way.
If you have ever led a team for a project or even for some volunteering activity, I am pretty sure you have met one of those people who participate in the team but don’t really want to work, or those who are lazy and waste a lot of valuable time, or those who seem very indifferent to the success of the project or activity, or those who always have excuses to be absent or late. Future team was no difference.
Firstly, I dealt with those kind of people with tension. I used to shout, be angry and make them feel untrusted. People won’t do what they don’t want to do. If your actions led your team to hate you, or at least hate your treatment with them, they will likely hate to follow you; therefore, not do what you ask them to do. What makes people do something and sweat for it is their own darn desire to do it. It is the dream that you all share. It is not your own dream if you are the one who started the team or invited others to be members .. no, it is your dream, all of you. At the core of leadership is how to affect people to do what you want, by turning it to be “doing what THEY want”. Anger, tension, shouting and blaming are the worst things to do when it comes to making people do what you want. It will only come from within themselves.
Secondly, I accepted members in the team more than we actually needed; mainly because I did not know that they were more than needed and secondly, because I was concerned about finances. Again, if you worked in a project that requires funding in Egypt, you likely know that the members themselves are the ones who cover the project’s expenses. This was a burden on the leader, because you always find that person standing, waiting for you to assign a task to him, but you don’t; so, he feels isolated and untrusted. He doesn’t feel like he is one of the team. After some time, he may not show up in the team meetings, in some occasions, he leaves the team. Assigning trivial tasks to them just to make them feel better is not a solution; because they know that the task is trivial and they feel bad about it. People are not the same, some may bravely ask for harder tasks and go for them, others may just stand watching and be shy to ask. Leadership is also about knowing how to deal with difference personalities.
Thirdly, as I said before, leadership is about getting 100% of people’s potential. So, if you want to get more than 100%, you will not succeed unless you give them a training to leverage their potential. If you are a talented engineer and it happened that you are the leader, you may find what the team members design or do – lower than YOUR expectations. You are a perfectionist – as me – and you don’t accept anything below the perfect. So, a lousy design from one of your team members, a buggy code, or an ugly fabrication can leave you frustrated. As a leader, you only have to make sure that what your team members have done – whatever it looked like – is their full potential. If it is not, your role as a leader is to find a way to make them reach that. If it is their full potential, conveying your frustration and objections to them is a destroyer to their spirits and it won’t do any good. Worse, if you decided to modify their work by yourself to fit your perfectionism, you will leave them feeling bad about themselves, unconfident and feeling bad about you as well. If you’re not satisfied with the level of your team, find another team full of professionals – and seldom will you find one – or just do the whole things on your own. The best way to deal with that situations is to show your members how the task should be done well from the beginning. This requires a great deal of excellence from you my friend; you have to be good enough to teach others how to be good enough for you to be satisfied. You have to show them how and praise them for the slightest advances on that path of learning. Otherwise you will be destroying them. Maybe I’ll be talking about this point on a separate post in the future.
Those my friend are the most catastrophic mistakes I have made as leader in Future team and will keep doing as leader of Hydrobots team as you will see in the last part.
As a result of those mistakes, a number of Future team members have left the team. I just happened to hear from one friend that some of them have left because they couldn’t bear my style. We are still friends, but they won’t prefer to work under my leadership again. Anyway, this led to a problem the next year when we wanted to form a team again to participate in the competition.
I was hesitated to compete that year. However, my friend, Omar El-Dadamony, convinced me to compete especially after we read the briefing of that year’s competition manual.
Thanks to my bad leadership practices, a number of the former team members declined our offer to compete again. Therefore, Omar took the lead to search for new team members and I just kept reading the challenges and making notes.
Assembling the team
In our first meeting, we actually did not have a team. We had candidates. Most of the people who attended that meeting didn’t know anything about ROVs or about designing or building a robot. They just accepted Omar’s invitation and came to see what is that thing called ROV competition and whether they will find it Ok to continue with the team or not. Most of them were mechanical department students – Omar’s friends and colleagues.
This method of gathering a team was just close to that of the preceding year. Thanks to it, we managed to have a team. Indeed, most of it was mechanical engineering department students but that was good; ROV competition needs good mechanical engineers. We had only one electronics engineer: Ahmed Sallam (do you remember him from the last post?), and two control engineers: Walid and me. However, that method led to some instability in the team for a while, members kept coming and going for a while until finally, a group of members chose to stay onboard and indeed participated in the competition to the end.
In an effort to make the team show better results, I decided to step down and leave the leadership to Omar. I had another reason for that, making the leader a mechanical department student will definitely help in a better understanding and coordination with the majority of the team members. I saw that this decision is for the team’s best interest.
That year, we had no place to work. Our lab in the previous year has been taken from us and gotten shut down. I talked with the Science Club in the university hoping that they will provide a place for us to work and also – hopefully – provide some fund to start with. Neither of this happened.
Our first meeting was in Co-working space called “Helm”. Our second meeting was on the stairs of the Science Club’s entrance under the rain of a cloudy day. Our third meeting was the same. We realized that this cannot continue to happen and that we have to find another place to work at. We also needed a fund. In ROV competition, the more money you have the better robot you are likely to build.
Finally, Omar came one day and told us that he has a storeroom in his house where one of his family members stores some goods and that we can work in it for the present time. One problem was solved. Omar also told us that his father has approved to give him 2000 L.E. loan that should be paid back at the end of the competition.
That helped; but funding kept to be a big problem which we tried to solve by paying from our pockets. That way, we managed to overcome two of the hardest problems we encountered at the beginning of that year.
We started that year by reading the competition’s manual. I wanted to build something especially fit for the mission that year. In our catastrophic first 3 meetings, I only presented the challenges to the team, explained what the robot should do to them and emphasized some requirements that should be fulfilled in our design. But because people kept coming and going, those meetings went in vain.
We tried to meet online. We tried Hangout and Facebook Messenger, but slow internet connection at some member’s homes was a problem. Meanwhile, we started to think about the design of the robot far from the requirements. Omar had a design in his head and most people’s ideas were not realistic. We went with Omar’s design.
Pen and paper
Every design starts with a pen and a paper, so was our design. Omar focused on a new mechanism he wanted to build which uses two crank-shaft mechanisms driven by a servo motor and rotates 4 thrusters on the sides. The idea here is to use 4 horizontal thrusters to move the robot both horizontally and vertically (by rotating the 4 thrusters 90 degrees downward).
It was brilliant; but Omar wanted more. He wanted to build his own thrusters. He designed the housing of the electric motors as well as the nozzle and static sealing. Besides, instead of sealing the electronics inside a cylindrical housing, he decided to cast an aluminium box which would be sealed by a gasket. The aluminium would act as a heat sink because the power circuits would lay inside that box dissipating a lot of heat. It would also be easy to open and close that box. The heavy metal would act as a ballast where its big size would act as a buoyancy which was roughly calculated.
We chose to use two cameras in the ROV. One camera would be a CCTV camera with a coaxial cable up to the surface. The other would be an HD USB webcam, connected via USB cable to the surface. The pilot would control the robot using a Playstation Joystick connected to a laptop on the surface. The control signals would be sent over an Ethernet cable to an Ethernet Shield mounted on an Arduino Mega inside the robot.
A lot of these concepts were drafted, designed, modified and verified on a piece of paper. The next stage was to use simulation programs – specifically, SolidWorks – to model the robot, check the dimensions, calculate the weight and volume to verify zero weight in water, and to measure the torque on the mechanism to decide on the type of servo motor we would need. Some of that was actually done, but the other was not.
Implementations and testing
Omar and the mechanical team rushed to cast the metal box without sufficient simulation or calculations. This cost us invaluable money and time. We had to remake that box twice or three times and had nothing good at the end. The sealing material was also weird. It was not rubber but rather a spongy material that I have never seen before. They were pretty sure that it will seal the box very well. But after a (late) test, it turned up that it doesn’t actually seal that well. They had to change the material many times. They also had to do machining to the surface of the aluminium box to make smooth enough to be sealed.
The custom thrusters were another headache. The team changed his opinion about the material that would be used as a housing for the electrical motors. One choice was PVC. But after failing to seal the ending cups (with that weird material) they changed their mind to using machined Artilon cylinders. They also set their minds on a specific design for the nozzles which turned to be catastrophic at our first try in water. The robot barely moved. I think it did not move at all! The nozzle was designed in reverse so that it minimizes the thrust rather than maximizing it (in the forward direction) !
The crank-shaft mechanism included a lot of problems. It required some kind of precision in the fabrication of the links as well as the locations of the motor and gears. But those things were not designed at the design stage. They were left to the implementation stage where we got surprised by problems such as not finding enough space for fixing the servo motor! The design of the robot’s frame did not have space for that! Also, the torque simulation was not correct, our first servo motor did not do the job. We bought ANOTHER servo motor (more expensive of course) and tried it many times but we faced a lot of trouble with making it working smoothly – a power problem I guess.
The frame of the robot was machined out of Artilon sheets using a CNC Miller Machine. The design was made on SolidWorks and exported to a CNC–compatible format. It was quite fantastic, but again, the thickness of the sheet was less than required for the robot’s frame to be robust and rigid. To me, it always felt weak. We did not change the frame this time though.
We managed to get a permission to try the robot in a swimming pool. We took the robot to the pool, put the robot in the water, and found for the first time that the buoyancy of the robot is way larger than its weight. The team tried to fix the problem by adding ballast. Finally, it seemed to be merely floating. We added the electronics circuits and switched the power on; however, the robot did not move! We tried to check everything and eventually found out that the thrusters were barely spinning and that they did not generate enough thrust to move the robot!
We learnt something from that. We went back to our storeroom and started working on solving our problems. We changed the nozzles of our thrusters, tested the thrusters underwater in isolation, modified the ballast system, and added safety measures in case of a leakage inside the electronics housing.
We went to the local competition venue. In our 15-minutes time of the mission, we put the ROV into the water, connected the power and voila .. the CCTV camera started streaming! However, our control system that relied on Ethernet connection just hanged. We changed the IP address of the laptop and the Gateway address to that of the Arduino Ethernet shield’s IP address (a trick to make the Ethernet shield work) but still, we did not have any response from the robot. To save the situation, we took a snapshot of the CCTV camera capturing the sunken ship in order to measure its length. Using an image processing script, we managed to measure the width and height of the ship. We submitted our calculations to the judge and we scored 7 ! Luckily, they made us pass that round without having our robot actually moving !
However, we received a lot of guidance from Eng. Amr Alawy, the leader of Caetus team who went to the international round the preceding year and ranked 16th internationally. Most of his guidance was about mechanical aspects and were invaluable to our team. The mechanical team changed the electronics housing to a cylindrical one as the previous year. They changed the locations of the cameras. They changed the frame of the robot to let the new electronics housing fit in. We tested our software and everything worked just fine.
We went to the regional competition with our new modifications. We still had the robot unfinished. We started to work on our last modifications at the competition venue the day before the missions. We had a shocking surprise, the power circuit got blown up! We didn’t have another one! We discovered for the first time a serious problem in the thrusters’ shafts alignment. They were not straight and they consequently had a great friction with the sealing causing it to stall. This problem could not be solved at the competition venue.
After hearing those two news, I got frustrated. I left the team working (and I should not have) and started wandering around, helping other teams as much as I could. My team did not give up. They tried to fix the shafts problem, and Ahmed Sallam found another team with additional power circuits and he quickly figured out a way to install those circuits in our robot.
Our mission time came. We put the robot into the water, connected the power terminal, waited for something to happen but .. nothing happened at all. The CCTV camera did not stream anything. The software did not find any response. The robot was just there in the water in silence. The 15 minutes passed away while we were trying to do anything to make it work but .. nothing worked.
Again, we lost. But we ranked 16th in the regional competition that year because of our points in the technical report, poster display and the engineering presentation (as they were called previously). The judging committee liked our robot and appreciated many of our designs and implementations. But we were speechless against some of their technical questions. They asked us : “What is the rating of this cable?”, we didn’t understand the questions so Ahmed Sallam answered with the electric specifications of the cable. However, the rating of the cable was a question about how much depth that cable could withstand ! We placed one thruster in a confined location which decreased its efficiency and they asked us about it. Those questions made me think: “There are many stuff which we don’t know anything about”, and we should know.
When I look now to what happened that year, I can spot a number of mistakes. Firstly, the team shouldn’t have formed that way. Maybe posting a “call for members” on Facebook or on the walls of the faculty’s labs was a better solution. We formed a team with no former experience and didn’t benefit from the last year’s members. We even didn’t look for any kind of qualifications, we just needed a team to compete – people who can pay the participation fees! Although the people I knew that year in the team are my friends today, working with them was full of hurdles. I didn’t practically step down from the leadership position; because I couldn’t see what was done wrong and shut my mouth. I was almost sure that we were going to fail if I left thing done wrong. I came back to use anger, shouting, blaming and conflicts. I was the worst part of the team.
Remember the 100% potential rule that I mentioned earlier, I just never noticed that, and I kept pushing on them to make something better. I wasn’t necessarily wrong, they sometimes made ridiculous wrong decisions; but I should have been wiser and more flexible in dealing with them. I should have even given up to the idea that: this is their full potential, why should I ask for better performance?
We all lacked experience. We all made bad decisions and personally, I did not pay enough attention to the control system and left almost everything to Walid who was so talented and active that he actually mastered Python, Pygame framework and a little of openCV framework on his own in the short time of the competition. There was bad coordination between the team members. Some members were almost always busy. They did not attend meetings or show up frequently as others. The mechanical team used to finish their tasks kind of slowly because they did not split the tasks between them but rather do the tasks TOGETHER ! You may find 3 members go together to receive the machined Artilon sheets while other things are needed and one of the 3 could go and finish that other important task. I objected but didn’t intrude very much because this is why I left the leadership position to Omar in the first place, they knew how to do things together better.
I was extremely bad at time and project management. I have not taken any courses in that subject. I searched the internet for tips and guidance and used what I found; however, that wasn’t enough. Consequently, no tests were done in the right time or done at all sometimes and a lot of bad decisions were made.
We didn’t achieve any advanced rankings that year either. Moreover, we made a whole lot of mistakes. I came back home that day, opened the text editor and started writing what to do for the next year. I was fed up with our inexperience, lack of good management and enough resources. I wanted to make something professional.
In the next part of this story, I will be talking about the actions I took to fix the problems I made that year. This will lead us to be talking about Hydrobots team and reveal many of its untold stories.