Blog
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 :)
