Blog
A Small Screw, A Big Lesson: Why Our ESC Board Burned Out
The ESC boards we use to control the motors in our AUV vehicle are securely housed inside an ESC case. However, a few months ago, we experienced an incident that taught us all a valuable lesson.
While our mechanical team was assembling the ESC case, they accidentally dropped a screw inside without realizing it. This small screw caused a short circuit on the board, rendering it completely unusable. At first, we assumed the issue was caused by a single component and tried replacing parts one by one in search of a solution. But no matter what we did, we couldn't get it working again.
Eventually, we discovered that the problem wasn't limited to a single component — the entire board was damaged. A screw falling into the wrong place had led to the complete destruction of the ESC board.
This experience taught us not only the importance of being careful, but also how crucial accurate diagnosis is. After identifying the issue, we redesigned the board, had it manufactured, and finally brought it back to life.
Sometimes, the biggest problems are hidden in the smallest details. We learned an important lesson from this process: "Final checks during assembly are just as critical as the design itself."
Developments in Taluy Mini Embedded Software
In this article, I will talk about the developments in the embedded software of our new vehicle, Taluy Mini.
The main board on the Taluy Mini AUV integrates all repetitive tasks such as sensor readings and continuous processing of raw data, power distribution to the integrated circuits on the board with the required voltage, and PWM generation for driving the motors — effectively abstracting these operations from the main computer and consolidating them into a single board. This allowed us to avoid using multiple microcontrollers and the additional delay caused by communication between microcontrollers. Moreover, by offloading some of the main computer's workload to the main board, we enabled the main computer to be used more efficiently for core competition tasks.
To manage sensor readings on the board, driving the brushless DC motors, sending ROS packages to the main computer via Ethernet, and executing the other ongoing tasks of the main board concurrently, we developed our own RTOS library. AUV-RTOS includes a simple round-robin scheduler and ensures that the tasks on the vehicle are performed with low latency and at the desired intervals.
In our new vehicle, we used the BNO055 as the IMU sensor. We chose BNO due to its ability to provide absolute orientation and perform sensor fusion thanks to the onboard ARM Cortex-M0+. We tested and calibrated the IMU sensor using rviz — ROS's 3D simulation tool. We also developed our own driver software to decode the messages from the Navquest Micro600 DVL sensor, which is connected to the main board. Thanks to the MAX232 integrated circuit on the main board, we converted the UART output voltage level of the microcontroller to the RS-232 voltage level required for communication with the DVL sensor, enabling successful communication between the DVL and the main board.
Another difference between the Taluy Mini main board and the Taluy expansion board is that it uses Ethernet instead of UART to communicate with the main computer. For network and transport layers over Ethernet, we used the lwIP TCP/IPv4 stack library, commonly used in embedded systems, and the Ethernet API of rosserial to communicate with the main computer via ROS packages. Due to Ethernet's CRC32 error detection and feedback features between host and client, we transitioned from UART to Ethernet communication on the main board.
Expansion Board: A Mistake, A Step Forward
In our vehicle, we use the CAN Bus protocol for communication between custom-designed boards, which we developed based on the specific needs of our system. Each board includes an integrated CAN transceiver, allowing for reliable and stable communication across the system.
However, one of the key components of our system, the Jetson, does not have built-in support for CAN transceivers. To bridge this gap, we designed an expansion board that acts as an interface between the Jetson and the vehicle's CAN network. This expansion board receives CAN signals and transmits them to the Jetson via rosserial, enabling seamless communication between the Jetson and other system modules.
Everything was working smoothly—until a mishap during pre-pool test preparations. The expansion board was accidentally inserted into the Jetson in the wrong orientation, causing the onboard chip to burn out.
Following this unfortunate incident, we not only repaired the damaged board but also decided to revisit our design. As part of this process, we are upgrading from the STM32F103 chip to the more powerful and faster STM32F446. This new chip provides us with greater flexibility in terms of processing power and peripheral support, which will better meet the evolving demands of our system.
Acoustic Localization
In this post, we are going to dive into (pun intended) one of the assignments that is given to the software team members last season. In this assignment, we tackled the challenge of pinpointing the precise location and depth of an underwater pinger (acoustic transmitter) using acoustic localization techniques. The data provided in a file called data.csv was our starting point, containing vital measurements taken with multiple acoustic sensors. These measurements include the GPS coordinates of the sensors, the depth of the sensors from the water surface, and the distances from the sensors to the pinger. Our task was to use these data points to determine the exact latitude, longitude, and depth of the pinger.
First, we dove into the data processing phase. We read the data from data.csv, adjusting the distance values by multiplying them by two for accurate calculations. We then extracted the latitude, longitude, and depth columns as centers, and the distance column as radii.
Next, we defined the Haversine formula, which calculates the distance between two points on a sphere. This formula was essential for our calculations, considering the Earth's curvature.
We then moved on to the residuals function, which calculates the sum of squared differences between the calculated radius and the known radius. This function was crucial for optimizing our calculations.
For the optimization process, we started with an initial guess, calculated as the mean of the centers array. Using the least squares method, we aimed to find the intersection point of the spheres representing sensor measurements. This process helped us estimate the pinger's coordinates with precision.
Once we had the estimated coordinates, we created an interactive map using Folium. This map allowed us to visualize the sensor locations and the estimated pinger location. We added circles and markers for each sensor location and a distinct marker for the pinger. Finally, we saved the map as pingermap.html for easy access and review.
The result of our efforts was the estimated coordinates of the pinger, pinpointed at Latitude 42.43869 and Longitude 18.58540.
Passive sonar project
I would like to tell you about the passive sonar project, which is one of the biggest projects I had the opportunity to work on this year. One of the most critical problems our vehicle faces in the Robosub 2024 competition it will participate in this year is that the mission areas are marked with devices called "pingers" that send repeated and intermittent signals at a certain frequency. In order for our vehicle to be able to achieve these tasks, it needs to be able to distinguish the mission locations by listening effectively and using the algorithm prepared for this job.
In terms of hardware, we use underwater microphones called hydrophones for this task. We pass the signals we receive from our hydrophones through our acoustic processing board (APB) and then transfer our analog signal to the digital environment, making it processable in our prepared algorithm.
In terms of software, by taking advantage of the fact that the incoming signal is in the form of a sinusoid, we divide the voltage values between the peaks into PWM-like values, and by taking into account the arrival times of the different signals between these values and the geometric angular positions of our hydrophones, we calculate the arrival time of the signal and the angle of arrival to our vehicle. Using this information, we can find our mission area by directing our vehicle to the signal source.
Motherboard Firmware Progress
I am working on developing the embedded software for the motherboard. Since our vehicle works with ROS, we are using rosserial_arduino packet communication on the motherboard. This library essentially simulates the motherboard with a python software that acts as a bridge instead of having the host computer talk to real ROS.
Currently, ping sonars are read via the motherboard. We can turn ping sonars on and off via a ROS service. Thanks to ping sonars, we can measure the distance of objects in front of us to us at 30-degree intervals underwater. We increase the accuracy of our underwater mapping by entering this data into mathematical functions.
We can also use the torpedo firing system via our motherboard. We use this feature by calling a rosservice. Right now, when a service is called, all communications except that function stop until the function completes its function. Although this period is as short as half a second, we are working on a solution to this problem.
Finally, apart from its many features, our motherboard is actually a power distribution board with power divider circuits. In this way, we can operate our sensors that require many different voltage levels.
Sensor fusion on Simulink and ROS connections
One of the projects I worked on in the AUV Software team was modeling sensor fusion algorithms via Simulink. The sensors that measure the position and orientation information of the vehicle, which are vital for autonomous movement, have a certain amount of error accumulation and noise. These errors are corrected and improved by a mathematical algorithm called the Kalman Filter, mostly by combining data from multiple sensors.
The Kalman Filter algorithm is available as a block in Simulink. After modeling the algorithm in Simulink, we can move to the ROS environment where we run the tool with the C/C++ code generation feature in Simulink. The program provides C++ code generation compatible with ROS workspaces.
Performing modeling in Simulink allows us to have a more visual and holistic view of the overall appearance of the model. The Simulink environment also makes data review and debugging processes easier for us.
Robotic Gripper Design Process
Hello, I would like to tell you a little bit about our gripper design process. Before we begin, you should know that the gripper is used to manipulate objects and change their location. Let's start...
Our first design was a system with bevel gears. In this system, there were 2 gears and a pinion gear between them. The drive power was provided by a servo motor. However, when the 3D printing was done, there were problems with the tolerances and dimensions of the claws. Therefore, we had to reconsider the design and moved on to version 2.
Gripper v2: Compared to the first version, we resized the gripper and reduced the design by 125%. A tolerance of 0.3 mm was given between the claws and the necessary gaps were left on the sides by topology optimization. However, although it was suitable for vertical use due to the bevel gear system, there were problems in positioning it in the lower compartment of the vehicle due to the space taken up by the servo motor. Therefore, we moved to version 3 for horizontal use.
Gripper v3: We followed a new design strategy, designing each component parametrically and separately. In the previous design, we worked as a unified and integrated whole, which made it difficult to fix something in the later stages. This new approach made the design more modular and flexible.
I hope you liked the challenges we faced while designing the gripper and the ways we overcame them :)
New blog page!
Hello, we decided to add a blog page to our site. You'll be able to see the development process of our vehicle here. Unfortunately, using a dynamic web page is not an option for us, so whenever we want to add a new blog post, we have to modify the code of the page directly. Hope to see you around in the future :)
