This is an autonomous unmanned-surface-vehicle(USV) that contended for Maritime RobotX Challenge 2014, organized by AUVSI Foundation and sponsored by Office of Naval Research (ONR).
I worked with Team KAIST in building this robot, and our team won 2nd place in the competition!!
The USV had to perform various tasks — including navigation, sonar detection, color detection and symbol identification — using various sensors.
Watch the above video to get the feel of the USV.
According to the team’s official website, the project lasted from Nov. 29, 2013 to Oct. 26, 2014; my involvement span from June 2014 to August 2014.
My major contributions to the project are solving the problem of thruster control and implementing a multi-client broadcast server.
What Did I Do Exactly?
1) Thruster Control
The biggest problem I saw with this project was the team’s failure to control the thrusters with programs. Thruster, which was provided by Torqeedo, was the only actuator in the robot that propelled the vessel into motion. The team was not able to carry out any field tests without having it in ready condition. Tests were getting delayed and people were getting really frustrated.
This situation was due to the lack of information on the internal architecture of the Torqeedo thrusters and understandings in asynchronous I/Os. The team’s frustration is clearly presented in their project site.
By the time I joined the team, they managed to obtain the information from Torqeedo. However, they still could not figure out how to programmatically control this. Fortunately, I was really interested in asynchronous I/Os and was programming Arduinos as a hobby at that time. I knew I could solve this problem and jumped right into it. Indeed, with many trial-and-errors, I came up with a solution that used both the HW and SW interrupts in Arduino Uno to properly handle 3 communication signals coming from RF module, main computer and the thruster itself.
This was such a rewarding experience: not only did I solve an important problem for others, but I did it with the knowledge that I acquired solely for my own curiosity. The connection between the two was a real thrill to me, and I believe it has guided me through my journeys in Computer Science.
2) Multi-client Broadcast Server
Another, relatively minor, issue was the absence of proper multi-client broadcast server. There was already a single-client, but this did not suffice. I still do not understand it, but they wanted the server implemented in C/C++. Rather than using multi-threads, I used multiplexing I/O to lower the pressure in the main PC. The book CSAPP, probably the best systems book out there, was very helpful in doing this.
3) Field Testing, Soldering and other HW stuffs…
Besides programming, I did field tests, soldered wires to boards, attached connectors to wires and assembled jigs for the first time in my life. I found myself really enjoying these, and it influenced me to work on other HW projects later on.
Looking back on my experiences, I think we could have done better by using ROS. It feels like the team unreasonably fixated on using bare C/C++. Most of the difficulty they faced was plumbing, and this could have been easily mitigated by using the ROS infrastructure. They could have also simply obtained GUI tools with ROS, not needing to costly implement them with MFC. Nonetheless, the team members were so nice and I really had an incredible time with them. It was also the place where I could learn hardware and new exciting problems such as sensor fusion(Kalman filters) and image recognition.
For more information visit,