S.O.N.I.A. AUV TECHNICAL DESIGN REPORT, ROBOSUB 2021 COMPETITION 1 S.O.N.I.A. AUV Technical Design Report Franc ¸ois Cˆ ot´ e-Raiche, Team Leader Camille Sauvain, Admin Team Leader Alexandre Leblanc, Treasurer Alexandre Lamarre, Mechanical Team Leader Francis Alonzo, Electrical Team Leader Alexandre Desgagn´ e, Software Team Leader Karine Blier, Electrical Team R´ emi Blier, Software Team William Brouillard, Electrical Team Onur Cocelli, Electrical Team Florent Cˆ ot´ e-Normandeau, Mechanical Team Martin Gauthier, Software Team Olivier Juteau-Desjardins, Electrical Team Lucas Mongrain, Electrical Team Antoine Pelchat-Fortin, Software Team Pierre-Yves Vincent-Tremblay, Software Team Abstract—S.O.N.I.A. is a Canadian student club from ´ Ecole de Technologie Sup´ erieure that involves 16 members who dedicate their knowledge to engineer an autonomous underwater vehicle (AUV). The guidelines of the club are innovation, efficiency. For our club, innovation goes particularly through the autonomy of our submarine. This is what makes our project so interesting and what sets us apart from others. The efficiency of the submarine is very important. However, we must not forget the efficiency of the processes. Therefore, in S.O.N.I.A., we place particular emphasis on the accessibility of our research. The club is divided into four departments: business, electrical, mechanical and software, each of which contribute to the achievement of the project. To facilitate the development of our submarine and the testing of our new technologies, we put a lot of effort into our development process. We believe that this strategy will allow us to perform in competitions in a more consistent way over the years. Since last year, team members want to bring both submarines to the competition, first to get the experience of sustaining two submarines in one competition and secondly to give us more training time and run time during the competition. Index Terms—Autonomous Underwater Vehicle, Tech- nical Design Report, RoboSub, RoboNation. I. COMPETITION S TRATEGY T EAM S.O.N.I.A.participated in the RoboSub competition for 21 years and look forward to compete for several more years. Therefore, our general strategy is based on the durability and the constant progression of our team. We put a lot of effort into the development of sustainable and flexible processes that will allow us to have constant improvement year after year and to avoid falling back.We understand the complexity that we add to certain tasks by using flexible systems. Choosing to use Deep learning as the main image detection technique instead of conventional vision or dead reckoning is a good example of that mentality. We consider that this choice allows more adaptability to the different hazards of the competition and will allow us to be more consistent in our results. Also, we think those complex systems give us better knowledge to carry over for the next competition year. A. Mechanical Team strategy This year, the mechanical department is a very good example of the consistency of the results we are looking for. Looking at the rankings of previous competitions, we found that some points were easily obtained by paying particular attention to the weight of our new submarine. Fig. 1. AUV-8 & AUV-7 We estimated a gain of 188 points which could be de- cisive in a tie-break sit- uation. An indirect way of increasing consistency is the new dynamic model that allowed us to create a new 6-DOF model based controller and new simula- tion environment. This will give us a reliable way to test missions before the competition and to prepare for testing day. Finally, during the weight relief process, the department made sure that the maintainability of the platform would be optimal with the newly designed rack system. In short, assured points, reliable testing
S.O.N.I.A. AUV Technical Design ReportFrancois Cote-Raiche, Team Leader Camille Sauvain, Admin Team Leader Alexandre
Leblanc, Treasurer Alexandre Lamarre, Mechanical Team Leader FrancisAlonzo, Electrical Team Leader Alexandre Desgagne, Software Team Leader Karine
Blier, Electrical Team Remi Blier, Software Team William Brouillard, Electrical TeamOnur Cocelli, Electrical Team Florent Cote-Normandeau, Mechanical Team Martin
Gauthier, Software Team Olivier Juteau-Desjardins, Electrical Team LucasMongrain, Electrical Team Antoine Pelchat-Fortin, Software Team Pierre-Yves
Vincent-Tremblay, Software Team
Abstract—S.O.N.I.A. is a Canadian student club fromEcole de Technologie Superieure that involves 16 memberswho dedicate their knowledge to engineer an autonomousunderwater vehicle (AUV). The guidelines of the clubare innovation, efficiency. For our club, innovation goesparticularly through the autonomy of our submarine. Thisis what makes our project so interesting and what sets usapart from others. The efficiency of the submarine is veryimportant. However, we must not forget the efficiency ofthe processes. Therefore, in S.O.N.I.A., we place particularemphasis on the accessibility of our research. The clubis divided into four departments: business, electrical,mechanical and software, each of which contribute to theachievement of the project. To facilitate the development ofour submarine and the testing of our new technologies, weput a lot of effort into our development process. We believethat this strategy will allow us to perform in competitionsin a more consistent way over the years. Since last year,team members want to bring both submarines to thecompetition, first to get the experience of sustaining twosubmarines in one competition and secondly to give usmore training time and run time during the competition.
Index Terms—Autonomous Underwater Vehicle, Tech-nical Design Report, RoboSub, RoboNation.
I. COMPETITION STRATEGY
TEAM S.O.N.I.A.participated in the RoboSubcompetition for 21 years and look forward
to compete for several more years. Therefore, ourgeneral strategy is based on the durability and theconstant progression of our team. We put a lotof effort into the development of sustainable andflexible processes that will allow us to have constantimprovement year after year and to avoid fallingback.We understand the complexity that we add tocertain tasks by using flexible systems. Choosing
to use Deep learning as the main image detectiontechnique instead of conventional vision or deadreckoning is a good example of that mentality. Weconsider that this choice allows more adaptabilityto the different hazards of the competition and willallow us to be more consistent in our results. Also,we think those complex systems give us betterknowledge to carry over for the next competitionyear.
A. Mechanical Team strategy
This year, the mechanical department is a verygood example of the consistency of the resultswe are looking for. Looking at the rankingsof previous competitions, we found that somepoints were easily obtained by paying particularattention to the weight of our new submarine.
Fig. 1. AUV-8 & AUV-7
We estimated a gain of 188points which could be de-cisive in a tie-break sit-uation. An indirect wayof increasing consistencyis the new dynamic modelthat allowed us to createa new 6-DOF model basedcontroller and new simula-tion environment. This willgive us a reliable way to test missions before thecompetition and to prepare for testing day. Finally,during the weight relief process, the departmentmade sure that the maintainability of the platformwould be optimal with the newly designed racksystem. In short, assured points, reliable testing
platform and easy and fast maintainability is whatwill give us an edge in the competition from ourmechanical team.
B. Electrical Team StrategyThis year, the electrical department had one goal.
Doing more with less. The main challenge for ourelectrical team was the major size reduction ofour new submarine. The strategy to create the newplatform was to adapt existing working design thatproved its worth during the past years and optimizetheir size to use them in the new submarine. SinceS.O.N.I.A. adopted enclosed submarines, we hadsome issues with our forward maximal speed. Thenewly improved power management will permit usto improve the overall speed of the submarine whichshould give us more time to execute tasks during thecompetition. Also, this newly gain of power coupledwith lower inertia gives us the opportunity to getmore style points with a rotation around the rollaxis. Lastly, one of the most awarding point tasks inthe competition is the random pingers which makeit an attractive task to complete since it basically as-sured a spot in the final stage. The electrical depart-ment tried to develop a more accurate hydrophonesystem which will give us greater chances to detectthe task with our deep learning system. We thinkthat with the time saved during each movement ofthe submarine and a better chance of success at bigpoints task, the electrical department will give us allthe chance we need in the competition.
C. Software Team StrategyThis year, the software department’s strategy was
to normalize the development process. Starting withthe continuity of the last year objective to dockerizeour software platform. The goal was to make thedevelopment, the testing, and the learning of oursoftware team as easy and efficient as possible. Withour experience from previous years, we know thatevery task demands some kind of image recognitioncapabilities and a way to align to a target. Therefore,we put our main effort on making sure we makethe control system and the recognition system asflexible and as efficient as we could for our futureteam members. For the testing of missions and newsystems, we have made a new 3D simulation usingUnity which will give use a more accurate testingenvironment when we do not have a pool available.
Since activating a torpedo or closing a mechanicalarm is basically the same for the software depart-ment, we think that focusing on the common coreof every task instead of an individual one will giveus more ways to adapt to a competition situationand to our recognition capabilities. This flexibilityshould let us choose the best options to adapt ourstrategy during the competition.
II. DESIGN CREATIVITY
A. Mechanical
1) AUV8 Outer shell: DINA is the 8th submarinedesigned by the SONIA team over the last 20 years.It features a single compartment hull with a slightlymodified cross shape compared to our previousprototype. The watertight hull is composed with 7-part sealed with BUNA-N O-ring to ensure a sealdown to at least 10m depth. The composition of hullis mainly in made of hard anodized aluminum andit also has four customs acrylic cap including onewith an integrated dome. The cross shape allowsquick access at each end of the vehicle to directlyaccess the problematic component by minimizingthe components to be removed. It is also a symmet-rical shape which also allows us to keep the centerof mass very close to the geometric center.
2) AUV8 Inner shell: In the inner shell, thecomponents are grouped by their functions. Thiscreates a certain electrical workflow to reduce de-bugging time. Also, our AUV is equipped with a 3Dprinted clip rack system. This way all the elementsare easily secured in place. It gives the possibilityto take out all the components without any toolsrequired. The only elements we did not use clipsare the DVL and IMU because we need them tohang tight, we the submarine frame. Without these2 components, assembling and connecting all theelectronics takes less than 15 min compared to ourprevious one which could take up to 2 hours toassemble.
B. Electrical
1) Leak Sensors: Water ingress is one of themain dangers facing underwater vehicles. Leak sen-sors stand as the last line of defence against waterintrusion. Their role is to detect a small quantityof water leaking inside the submarine, allowing thesystem to abort the mission before the water reaches
critical systems. Off the shelve leak sensors alreadyexist (notably BlueRobotics’s SOS probes).
Fig. 2. Leak Sensor
However, we want sen-sors that offers us moreflexibility in their physi-cal form and that could bereused after having beentripped (as opposed to theSOS probes that are oneuse only). For the designof the sensor, we choose tomeasure the resistance be-tween two electrodes.If theelectrode were to meet water, the resistance shouldbe greatly reduced. To measure the resistance, weput the two electrodes at the bottom of a voltagedivider. If the resistance between the electrode isvery low (i.e., the probe has been tripped) 0 Vshould be read across the electrode. When theresistance is very high, almost 3.3V should be readacross the electrode. The voltage is measured byan operational amplifier in comparator mode toprovide the output. We chose to add hysteresis tothe comparator by having a positive feedback. Thisway, the resistance of the two electrodes needs tobe higher for the comparator to reset. As a result,the output of the comparator will stable even if theresistance oscillates around the initial setpoint of thecomparator.
2) Backplane: The first time we assembled oursubmarine, we found out that the space was notbig enough to fit all the cables that were needed.We found that the power management was speciallytaking a lot of useful space. Since we already hadthe idea to give more power to our thrusters to giveus the possibility to mark style points and travelfaster to the different objectives giving us more timeto do them, we used this opportunity to redesign thepower management system.
The goal of this redesign was to free space inthe submarine and to support a max current of 90%of the rated current of our thrusters. We used tohave a desktop processor in our submarine thatwould only use a voltage of 12V. Now, with theNvidia Xavier, no component in our submarinerequires a single voltage input. That allowed us tocompletely remove the unnecessary converters andat the same time remove 4 printed circuit boardsfrom the submarine. To reduce the cost withoutcompromising the performance, we have chosen
to remove the solder mask on the printed circuitboard allowing us to add solder on the high currenttraces to reduce their electrical resistance. We arestill using some thicker plating of the layers of theprinted circuit board, but the removal of the soldermask gives us a possibility to improve our currentratings.
3) Direct Current to Direct Current: Modernelectronic systems often require voltage regulationto work. In the case of SONIA’s submarine, the volt-age of the batteries (normally around 16 V) need tobe decreased to a value more suitable for electroniccomponents, for example 3.3V. In the past, DC-DCconverters were integrated directly with the differentPCBs, meaning that a module had to be redesignedfor every project. With the addition of a FPGA(which requires multiple voltage to operate) theteam decided to take a different approach by usingboard-mounted DC-DC converters. We originallyintended to use off-the-shelf modules.However, wewere unable to find a product that would meet allneeds. Specifically, we were looking for a regulatorwith good efficiency, variable voltage output andlow ripple voltage.
Fig. 3. DCDC Design
Additionally, we wantedthe ability to turn the out-put on and off to meet thepower sequencing require-ment of our more complexprocessors (such as ourFPGA). We also wanteda small board since spacecome at a premium in our submarine. To achieveall those goals, we decided to design the moduleourselves. For a good efficiency, we decided to use aswitching regulator as the efficiency is considerablygreater compared to linear regulators. To simplifythe design, we chose a controller with an integratedMOSFET, allowing us to reduce the number ofcomponents on the board. Thanks to the differentsteps we took to tightly integrate the converter, wemanaged to create an 11,3 mm X 20,04 mm board.
4) Hydrophone: The hydrophone is an importantproject for our submarine. We value this projecta lot since it is a huge learning experience forour members and the acoustic source locations is awell rewarded task at the competition. At the 2019competition, the hydrophones were not working,and we had a lot of noise issues on the signals.Those issues came from the noise of the thrusters
at 35 kHz. Sadly, the documentation of our oldacoustic system was not sufficient to maintain theproject running.
Therefore, we had to redesign completely thehardware and software for the hydrophones. Theobjective for the hardware was to have a newerplatform and an easier method to test the differentcomponents. For the software, the objective wasto reduce the learning curve imposed by the com-plexity of the mathematics used in the algorithm.Also, we wanted to upgrade the precision of thehydrophone’s detection to be around a meter fromthe exact position of the pinger.
To improve our hardware testing and revisionprocess, we have implemented a quick replacementsystem for our filters that are made with two 20 pinsconnectors. The hydrophone main board has its ownpower converters, FPGA and UART communicationwith the on-board computer. Each filter has its owndedicated communication bus to make the mainboard design adaptable. Another advantage for theseparate filter is that the layout is going to beidentical for the 4 filters. We also updated theSpartan FPGA with the newest Spartan-7 series formore flexibility on the software.
To reduce the learning curve on the software, wehave used Matlab and Simulink to generate someHDL code for the algorithm Time Difference of Ar-rival used to locate the pinger. We still had to createthe core of the FPGA ourselves, but the learningis much easier. Also, by working with Matlab, weare certain that the code will be compatible betweendifferent versions of FPGA since we can choose thetarget FPGA when generating our HDL code.
C. Software
1) 6-DOF Model Based Controller: [4]During the competition, all tasks require aligning
the submarine with visual data obtained from thefront and bottom cameras. These images or shapeswill provide information on the orientation andposition the submarine must take to line up. Properalignment of the submarine is essential to completethose tasks. This requires that the submarine mustmove a long distance quickly without accumulatingtoo much error. For the torpedoes task, a badcontroller could mean the complete failure of thetask and a big loss of time. For the octagon’stask, it could be disastrous if we surface outside
the octagon, which would end the run. Trajectorieswould also be used for movements between tasks.To perform this kind of task we need a suitablecontroller.
True to our philosophy, we wanted to innovatewith our new controller. We also believe that knowl-edge sharing is very important and that is why wewant to make this project an open-source project.The aim of this project is to design a modular con-trol that can be used for our two current prototypesas well as our future prototypes. This control can beadapted by giving specific constants that representthe AUV. We also want to design a control that iseasy to use and modify to allow other members aswell as the next generation of S.O.N.I.A to use itas it should and that is why it will also be highlydocumented. We find it very important to documentthe development and the operations, but it is alsovery important for us to share our thoughts to leavea good traceability of our choices in relation toour project. The next members will then be ableto get involved in this project in turn and continueto innovate in terms of control for the benefit of theS.O.N.I.A club as well as the community of creatorsof autonomous submarines.
Fig. 4. Controller in MatLab
Attitude’s Representation: [7] To represent theorientation of the submarine, we decided to optfor the unitary quaternion instead of the Eulerangles as much for mathematical reasons as forimplementation reasons. Even if the quaternion isnot as intuitive as the Euler angles, it has some bigadvantages which explain its popularity.
From a mathematical point of view, since thequaternion has four parameters instead of three, itcan define any rotation without any singularity. Thisphenomenon is better known under the name ofGimbal lock. In addition, the quaternion does notcontain any discontinuity. With Euler angles, thisproblem is better known as wrap around. Regard-ing the implementation of our model, we have anadvantage to use the quaternion, because it is morestable numerically.
Controller: [6] By default, the MPC commandis a linear command. However, several tools areavailable to work with nonlinear systems. In ourcase, the submarine is a nonlinear system. However,the non-linearity does not vary greatly over a shortperiod. It can therefore be said that the system isnot highly nonlinear. In addition, the number ofstates and the sampling time will not change overtime. In a case like this, we can usually use anadaptive MPC. This variation uses the Jacobiansof the linearized model at the current operatingpoint. However, we tested this method on our modelshown with the quaternion, but the use of a Kalmanfilter with the quaternion was inconclusive. Theerror in the estimate was too great. To overcomethis problem, we can use an external extended typeKalman filter (FKE) which better estimates the non-linearity. The estimation of states is nonlinear, butthe control is linear. Although this type of MPCwith an extended Kalman filter is more resourceintensive and, our tests have shown notable results.To implement the MPC as part of our project, weused the MPC toolbox in Matlab and Simulink.This toolkit offers several tools to design MPCcontrollers (linear or non-linear).
Software Implementation: To do the softwaredevelopment of the submarine control, we optedto use Matlab and Simulink. We made this choicegiven the multitude of tools that Matlab andSimulink offer to develop complex software suchas a specific ”toolbox” for robotics. This tool al-lows you to develop ROS nodes to communicatedirectly with all the modules of S.O.N.I.A. Another”toolbox” also allows us to design an MPC that weused to make our controller. Finally, using Simulink,we can do a lot of simulations to test our physicalmodel and the entire controller.
Another reason, less technical, also influenced ourchoice. Given the small number of members withinS.O.N.I.A, we believe that using software such asMatlab and Simulink can simplify the developmentof an algorithm as complex as our controller. Also,most of the members who have worked on controlin the past are enrolled in the Automated ProductionEngineering program at ETS and have used Matlaband Simulink in some of their courses. Such devel-opment directly in C ++ would have taken muchlonger to develop without the use of Matlab andSimulink. With these tools, we can directly deployour code in C ++ for use on the submarine.
To generate the nonlinear state model of thesubmarine, we proceeded in several steps. First,we symbolically wrote dynamic equations usingMatlab’s Symbolic Math Toolbox. Next, we sub-stituted the submarine-specific physical model con-stants with the numerical values. Finally, we wereable to generate Matlab functions from the symbolicequations for use in Simulink. We generated afunction for the nonlinear equation of the submarineconsidering disturbances, another function withoutconsidering disturbances and a function to generatethe Jacobian matrices at an operating point. TheseMatlab functions could therefore be used insideSimulink to perform simulations.
Desktop Prototyping and Deployment: Wewant the deployment to be quick and easy to beable to make changes in our Simulink during pooltesting and then directly test those changes. Thefirst method that we present gives us precisely thesecriteria. Simulink, using the ”ROS Toolbox” [5]library, allows us to connect to our submarine via anSSH (Secure Shell Protocol) connection to directlydeploy the generated codes and then execute it. Thisfeature also makes it possible to see in real time theinformation in the ”Scopes” that we have placed inSimulink to know the information coming from thesensors. This feature is called “Monitor and Tune”.When our tests are done and we want to deploythe ROS nodes on the submarine, we will proceedwith what we call going into production. We willparticularly use this method to generate code testedusing ”Monitor and Tune” and which is functional.The C / C ++ code generated by simulink willthen be put in a Docker container provided for thispurpose that can be used on the submarine to runthe controller we developed.
Trajectories: Trajectories are a great way to giveour controller a reference to get to a given positionor positions and that is why we have opted fora trajectory generation system to ensure desiredtrajectory is followed. We wanted to allow anyonewho uses the control to be able to give a list ofpoints to generate a trajectory passing through thesepoints, but also to give parameters to be respectedfor each of them.
2) Dockbox: One of the challenges of the pooltesting is to be the most efficient as possible andit all starts with a good setup of our differentdepartments. We found that the software team havethe longest and the more hazardous one. There-
fore, we decided to ease the deployment of ourdepartment with a new dockbox. In the past, weneeded to bring an old laptop to use it as a networkbridge to access the internet and it was always abit too long. We wanted a plug and play, easy touse dustproof, waterproof, and shockproof box tobring everywhere we needed that would protect ourelectronical devices.
This new dockbox is driven by an NVIDIA JetsonTX1. When powered on, this computer is used tobridge the network inside the dockbox to provide theinternet to the software team and the AUV if needed.Also, a router and a network switch are installedinside the dockbox to allow the team to connectto the AUV and the internet. We installed manywaterproof ethernet connectors and a waterproofpower connector to keep the box, made from aPelican Case. The team also use the dockbox asa file storage server using a Samba share whichallows to store and access files during the tests.To access the internet, the network Eduroam [2]is used. Eduroam (education roaming) is an in-ternational roaming service for users in research,higher education, and further education. It providesresearchers, teachers, and students easy and securenetwork access when visiting an institution otherthan their own. Authentication of users is performedby their home institution, using the same credentialsas when they access the network locally.
3) Proc Image Processing: [4] Part of an au-tonomous submarine’s challenge is to be efficientin the usage of the resources of onboard equipment.This includes the power drawn by the onboard com-puter of our submarine. One of the data processingmodules we run on our Jetson AGX Xavier isperforming basic transformation and detection fromthe cameras video feed.
Those algorithms based on the OpenCV2 libraryare presently running on the CPU of our onboardcomputer. Thus, to improve our efficiency, we canuse advantage of the Jetson’s GPU to run OpenCVimage transformations on it instead of its CPU.Doing so, our submarine will use a more appropriatepart of the hardware to compute images efficiently.To implement this change, we need to use a ver-sion of OpenCV with CUDA3 [3] enabled in itand incorporate it with the rest of our softwarearchitecture. This part of the project came with itsown challenges. In the first place, the version ofROS we were using had its version of OpenCV
shipped with it and was not allowing us to useCUDA. To solve that, we had to rebuild it with theproper configurations, and we took the opportunityto update the versions of the OpenCV used. Inthe process, we encountered another blocker whenbuilding the library OpenCV with CUDA. Sinceour workflow to build Docker images passes by theGitHub CI, the task would take over 6 hours andbe shut down by GitHub for taking too long. To getaround this one, we modified our workflow for thisexception by building it ourselves and publishingthe resulting image afterward. This was conceivablesince we will need to rebuild the image only whenwe want to update the version of CUDA or OpenCV.
4) Deep Learning Training Automation: Duringthe past years, a lot of effort has been put on thedevelopment of our deep learning and the processof training became increasingly complex. In fact,most of the project became a practical task whichis difficult for newer members since it requiresmore than basic deep learning knowledge. Focusingonly on external aspects of training, like identifyingthe most favourable neural network from Tensor-Flow, tuning hyper-parameters, and choosing theright dataset, allows for better results since moretraining jobs are completed as the workflow geteasier. Giving access to this project to the first-yearmember will give us a massive advantage over theyears as they will carry their expertise through morecompetitions. Therefore, the process of acquiringthe data, preparing the data, preparing the model,and training the model was automated.
We used Apache Airflow to create pipelines thatprincipally extract, transform, and load the databut also train the model. The groundwork for thetraining is carried out by multiple DAGs (directedacyclic graph), which are a collection of tasks inAirflow, who all have a key role in the orchestrationof a machine learning job. The DAGs are separatedentities but the process as a whole extract imagesfrom ROS bags, export images to Labelbox wherethe team labels them manually, build the necessarydirectory structure for training and import Labelboxprojects into those directories. The model can thenbe trained with GCP and use their GPUs, or it canbe trained locally. Depending on the training methodlocal directory or GCP buckets will be used. EveryDAG can also be run independently of the others,so certain steps do not have to be repeated everytime we train a different model.
5) Web Telemetry: [4]For many years, we used a homemade teleme-
try based on a ROS framework named RQT. Ourtelemetry had strong dependency with ROS. Withour new software architecture, we had problems ofportability because the implementation of the oldtelemetry inside a Docker container was hard to do.Therefore, we decided to create a new telemetry appusing React, Typescript and Roslibjs.
This new web telemetry is portable and allowsthe team to connect from any device they want.(Windows, Mac, Linux, IOS and Android). Thistelemetry gives us a lot of modularity that fit everyteam member’s needs since each user can choosewhich module to add to their web page and howmany of each they want. To properly monitor thesubmarine’s pose and speed in his environment, wedecided to create a PFD (Primary Flight Display)inside our telemetry. It will take some time to getused to, but we think that it is a more efficientway to get the information about the submarinemovement. To create this telemetry, we used Reactand Typescript to ensure portability of the code andROSLib JS to communicate between ROS and theweb app via an intermediate of ROSBridge. We usedMaterial UI, an open-source project that featuresReact components that implement Google’s Mate-rial Design, to design our UI component modules.The architecture of our new telemetry uses a layoutsystem that support module integration and ensuremodularity and maintainability.
6) 3D Simulation: Testing is an important partof any development, especially when you try toinnovate using less known technology like in oursubmarine. With the opportunities to test our phys-ical platform reduced this past year, we realizedhow much important it is to have an accurate andfast way to test our work. Using our old telemetryon RQT, we had ways to test single modules byusing RosBags, but it required recorded data priorto testing. Since they are recorded, this data cannotbe changed. This can be problematic. For example,if we wanted to test a new alignment algorithm, thevideo feed used as input does not replicate the newmovement asked by the tested algorithm and youneed to analyze your output in your terminal whichis not efficient at all.
We wanted to create a way to simulate the sub-marine that would permit every member of our teamto test their advancement in a single environment.
To do that, we decided to create our own simulationenvironment. This simulation needed to be the mostaccurate as possible for testing to be effective.We specially had two systems that we wanted tofocus on which are the submarine controller and thecameras. We knew that gazebo had a very powerfulbuilt-in physical model and that the unity one ismore on the arcade side, but the visual rendering ofunity with its post-processing capabilities is whatmade us choose Unity.
One of the challenges using Unity is the con-nection to ROS. We chose to go with the 2020version to use the new Unity robotic package [1]which includes a ROS integration. This package letsus create our own message and communicate withthe ROS master to listen or publish messages andservices like our submarine would do. By usingUnity, we prioritize the visual rendering to thephysical model knowing that with the new controlwe were developing, we already had to create ourown physical model. By using our own model, wecan use positions output by our controller to givethe position we want the submarine to be in Unity.One thing that can be overview is the portability ofUnity. Since it can be compiled for any platform,anyone can use it without being on Linux or needingto have ROS installed.
III. EXPERIMENTAL RESULTS
A. Mecanical
1) Rigid body constant: We have decided touse a more theoretical approach to define mostof the constraint needed because we can not havea proper feedback the small pool. For the rigidbody constraint, we weighed all the components,and we entered the results in the properties of therespective cad in Solidwork, then we can use themass property feature of solid work, to determinethe Mass, the center of mass, the volume, and theinertia tensor. To make sure our data makes sense,we then weighed the assembled sub to make sure itmatches the mass calculated by solidworks and weare less than 500g away. This is mainly caused bythe fact that the cables are not modelled. Therefore,we were able to check if we have respected theconsideration and the strategies that we have definedpreviously. If we start with the volume, comparedto our previous submarine, Dina is half the volumewith 27L compared to 55L. Next, if we look at the
inertia tensor and more precisely at the main inertiamoment and compared it to our previous prototype.Data has shown that we have succeeded in reducingthe inertia about roughly 72% around surge axis,15% around sway axis and 47% around heave axis.
B. Electrical
Fig. 5. Heat testing result after 1min
1) Backplane: Wehave done a stress testof the components ofour first revision to de-tect potential thermalissues. With a currentof 15 amps, we haveseen a temperature riseto 83.1°C after a fullminute of load. To get90% of our thrusters, we would need new partswith a lower internal resistance and a better thermalmanagement.
2) Leak Sensors: The circuit has been simulatedusing MicroCap. The result of the simulation is pre-sented below. The upper graph presents the outputof the comparator, and the graph below representsthe resistance of the electrodes. From those graphs,
Fig. 6. Leak Sensor
we can see the hysteresis of the comparator asthe output switches to high when the resistance isaround 13.15 Mohms and the output resets onlywhen the resistance is around 44.32 Mohms. Thoseresistance values are much higher than those thatwe expect to use in our final design. We intendto find better suited values experimentally once ourfirst prototype is done.
3) Direct Current to Direct Current: In ouroriginal design, we had grounding problems whichresulted in higher-than-expected ripple voltage. Byreducing the size of the ground loop, we managed to
reduce the ripple voltage from 122 mV to 64.8 mV.Although this is a stark improvement, we are stilllooking at refining the layout and the componentselection to reduce the ripple voltage.
Fig. 7. Ripple Voltage Testing
4) Hydrophone: Since we only have one workingfilter for now, we could not test the localizationalgorithm since the full four filters are needed tolocate the source. On the other hand, we were ableto test the reception of data from our pinger inminiature pool environment. For future pool tests,we would want to start defining the threshold ofthe signal to separate the desired ping and theunwanted noise. This process has been estimatedin the simulation, but we found inconstancy in theresults produced so far. After defining the threshold,we will be able to focus on the accuracy of thealgorithm. For now, we have done some simulationwith the algorithm used on the FPGA and we haveachieved the precision of 0.79 metres when thesubmarine is at 15 metres of the source with aGaussian noise with a variance of 0.01. The dataused to generate the signal was the data collectedat the TRANSDEC during the 2019 competition.
C. Software1) 6-DOF model based controller [4]: Follow-
ing, we will present the results of a simulationthat we performed using Simulink. To create thetrajectory used for this simulation, we proceeded inseveral steps. First, we plotted this path in the Solid-Works modelling tool. This is what the modelledpath looks like. As you can see in the followingfigure, we have chosen to raise the submarine whileturning. We wanted to generate a trajectory wherethe submarine moves on 4 degrees of freedomsimultaneously. Then, we chose some points on thetrajectory to give them to our trajectory generatorusing a Python script. Here is the trajectory thatwas generated by our trajectory generator. In thefigure, we can observe the points generated as
well as the orientations for each of them in a 3Dperspective.The Figure 8 shows the generated pointsand orientations that will be sent as a reference tothe MPC. The Figure 9 are the graphs of the linearpositions and the quaternion of the trajectory thatwe generated. The Figure 10 compare the outputs(the states in our case) to their respective references.The Figure 11 shows the command of the motorscoming from the MPC.
Fig. 8. First Trajectory Generated
Fig. 9. Linear Positions and Quaternion Generated
Fig. 10. Output States
Fig. 11. Command from MPC
According to those results, we can notice thatthe controller is able to follow the trajectory thathas been imposed on him while respecting theconstraints that we have imposed. We also noticethat we have a zero error in steady state and thatif an overshoot is observed, it is negligible. The
points that we sent to create the trajectory resultedin a trajectory as we wanted it. The generatedtrajectory is not completely smooth and has someimperfections, but it will be improved in the future.
Although we had the opportunity to run simula-tions with Simulink as well as in our simulator, wewould have liked to be able to perform tests in thepool. As soon as the sanitary situation allows us,we will be able to perform more realistic tests inthe swimming pool to see our work in action in thewater and do the work necessary so that our controlcan be officially deployed on the submarine.
2) Dockbox: During the year, we had the op-portunity to test the dockbox many times. Each ofour mini pool test, we tried to connect multiplepersons on the box without any issues. We madelarge downloads and uploads to test if all was goodtoo. We are confident with our new dockbox to be areliable way to improve our deployment efficiencyand we are using it every test we have.
3) Proc Image Processing [4]: We will be ableto measure the gain in performance by looking atthe number of frames per second we can processwith our solution. A reduction of the CPU load ofour onboard computer should be noticed. We couldalso measure the difference in power consumptionbetween the old execution of filter chains on theCPU and now on the GPU.
Furthermore, we looked at the modifiability ofthe module at the same time. Since we need tomodify this module often by adding, modifying oreven retiring filters following the tasks needed to beperformed in the competition, we wanted to be surethe effort required to do so was minimal. To helpus keep track of this important quality attributes,we integrated a new tool to our workflow namedSonarcloud. This tool will help us keep track of thequality of the module’s code and will help membersidentify fixes for bugs, vulnerabilities, code smells,code duplications and test coverage.
4) Deep Learning Training Automation: The im-plementation of Airflow pipelines has already beenuseful. The newest members interested in artificialintelligence have been able to train models and im-prove their abilities on this subject without externalhelp of the most experienced representatives.
5) Web Telemetry [4]: We recently tested ourtelemetry with AUV8 during one of our tests. Wewere able to test the image viewer and the PFD.We will certainly add more modules inside our
telemetry and improve the ones already created.Each time we modify a module, we will make sureto do the proper tests with the submarines to validatethe new functionalities added.
6) 3D Simulation: Testing the testing environ-ment is a crucial step toward its development. Sincewe could not do it in a pool big enough to getcredible data, we cannot be assured that the physicalpart of our simulation is accurate. On the other part,we used the 2019 competition recorded RosBag totest the visual rendering of Unity. We are happywith the result between the simulated environmentand the Transdec footage, but we know it can stillbe improved for more realism. We were not ableto test a newly trained AI in unity since we hadsome performance issues with the image publishermessage, but this is the next step of testing. Welook forward to the end of the testing because wewould want the simulation to be part of our newweb telemetry giving us 3D representation in realtime of the submarine action during the pool testing.
Fig. 12. Vampire in Unity vs Vampire at Transdec
ACKNOWLEDGMENT
We wanted to highlight the involvement of Mr.Alain April. For several years, he has been helpingour team members with their projects. He also al-lowed us to undertake the deep learning automationproject thanks to the external GPU that he offeredto our club.
We wish to thank Mr. Rachid Aissaoui who super-vised us throughout the new controller project. Hegreatly helped us in our reflections, our choices aswell as the acquisition of technical knowledge. Heoffered us invaluable support for the full realizationof our project.
We wanted to thank members that dedicated acourse to help our team:
To start the Docker projet: A special thanks toMarc-Antoine Couture, Martin Gauthier and KevinCharbonneau supervised by Alain April.
For our new Web Telemetry: A special thanksto Laurent Boisvert, Herve Carol and Anthony Frez-zato supervised by Alain April.
For our new Controller: A special thanks toAlexandre Desgagne and Alexandre Lamarre super-vised by Rachid Aissaoui.
For the new proc image processing: A specialthanks to Pierre-Yves Vincent-Tremblay, GuillaumeTremblay, William Tang and David Sauvageau su-pervised by Alain April.
We wanted to thank the club ReflETS for theincredible photos of our submarines as well as ourteam photos. We also wanted to thank the clubCedille for hosting and maintaining our server.
We wanted to thank our sponsors:Diamond: Bruel & Kjaer, Altium, SolidWork and
Cegep du Vieux MontrealPlatinium: Lojiq, Lenovo, AEETS, Cegep
St-Jerome, Usinage Villneuve and Fond dedeveloppement ETS
Gold: Teledyne Marine, Labelbox, Caisse Des-jardins and Drillmex
Silver: Travis CI, Parc Jean-Drapeau, Vectornav,Tritech, Samtec and Digi-Key electronics
Bronze: Nvidia, Connect tech In., Blue robotics,Laser AMP, Anodisation Expert, Groupe Rivest,Simplify 3D, General Dynamics, Attaches Richard
[3] CUDA ToolKit, Nvidia Developer,https://developer.nvidia.com/cuda-toolkit
[4] S.O.N.I.A, Special project and Capstone project,https://wiki.sonia.etsmtl.ca/en/software/projects
[5] Castro, S., (2017). Getting Startedwith Matlab, Simulink, and ROS,https://blogs.mathworks.com/racing-lounge/2017/11/08/matlab-simulink-ros/
[6] Islam, M., Okasha, M., Sulaeman, E., (2019). A Model Predic-tive Control (MPC) Approach on Unit Quaternion OrientationBased Quadrotor for Trajectory Tracking. International Journalof Control, Automation and Systems: KIEE and Springer, 14p.
[7] Fjellstad, O., Fossen, Thor I., (1994). Position and AttitudeTracking of AUVs: A Quaternion Feedback Approach. Nor-wegian University of Science and Technology: Department ofEngineering Cybernetics, 15 p.
While having a second online edition of RoboSubkeeps our mind sharpened and focused on producinga good work for a competition and fully understand-ing the decision of the organization, we still hada feeling we would be missing out something ifwe could not have a physical experience with otherteams. Most of our team members had the chanceto participate in the 2019 RoboSub competition sowe know the kind of experience this event providesand we know not many of us will have the chanceto come back in San Diego next year. We did notwant to leave the team unprepared for the nextcompetition. We are also missing the communityambiance that can only be found at the Transdec orthe hotel with all the other teams. All these reasonsled us to organize our own small competition withteams from Quebec.
We will have this competition between McGill,Trois-Rivieres and us. All these teams have alreadyparticipated in at least one RoboSub competition.We knew McGill team from previous collaborationssuch as pool test sharing and we had met TroisRivieres in 2019 when they came in San Diego forthe first time. We want to use this competition as away to create stronger bonds between our teams andstart to collaborate more with each other. We intendto recreate a format like RoboSub with test runs anda final run. The tasks will be similar to RoboSub aswe also want to create this competition in previsionfor the next years. The long-term goal is to have thiscompetition a few months after RoboSub in orderto show to the new members what will be required,fix what went wrong at the Transdec and share whatwent right to the other teams so everybody canimprove.
The fact that it’s a local competition will help uswith the sanitary rules, for now the evolution of thesituation lets us think there won’t be a problem thisautumn when we want to have the competition. Wewere thinking of having the competition in a naturallocation to recreate the environment of the Transdec,specially for the water color and the shining of thesun which are two influent components when weare in San Diego. But finding a perfect spot withall the facilities close is a hard task and we had toresolve ourselves to pick an indoor diving pool. Atleast we’ll be safe from any unpredictable event.
The competition is set to happen this fall so we
don’t have any result to provide yet. But as forestablishing stronger bonds between the teams, wecan proudly say it is already a success. We had morecontact with these teams in the past four monthsthan in the last three years and we are all eager tomeet each other at the competition.
B. Data Sharing
A recurrent situation when using Artificial In-telligence is the lack of data. We are all facingchallenges in multiple departments of our teams andwe don’t have necessarily enough time to get all thedata we need to train or test our models, and thiseven more true for new teams. When we enteredSONIA, one of the first lesson was that we all dothis for the community and being open source is apride. This is why when Hitesh and Julianna cameto us talking about starting a Data Sharing Platform,we accepted immediately.
On the Data Sharing Platform, any team regis-tered in RoboSub, RoboBoat or RobotX competitionwill be granted an access to the data uploaded by theteams in the previous and present year. This is notjust about training and test data for AI models, theteams can also share their mechanicals, electricalsand software designs to help the community.
The Data Sharing Comity has been gatheringalmost every week for one year to design the rulesand the organization of the platform. We made teston who could share, who could only downloadand we decided that the teams could upload anddownload files from there generic account. And theycould share the access to the platform for theirmembers that would get an access to just downloadthe files. This is in order to make sure the platformremains as clean as possible. The comity will behere to maintain the platform and help the teamswith their problems. The comity is composed ofmembers of teams interested in data sharing andwill be renewed as members leave so this is reallya community driven effort.
The platform had a beta testing phase in theFall, based on the returns from the participants andmake the adjustments needed. We are now in thesoft launch phase because this is a year without acompetition in person and with limited testing anddata recording opportunity. This is not a bad thingsince this will let time for the teams to visit andget comfortable with the platform. We have already
seen some requests for data so this is encouraging.The real test will happen next year before thecompetitions season.
C. Team building activitiesWith the pandemic and the remote school, it has
at times been difficult to connect with other mem-bers of our club outside of work on the submarine.It was important for us to keep the atmosphereof our club even from a distance. To do this, weparticipated and organized several small activitiesallowing us to keep in touch and have fun together.
1) Strava: Some of our actual and old membersdecided to form a Strava group to encourage mem-bers to exercise. It’s a great way to keep in touchand to feel together even from a distance.
Fig. 13. Strava Group
2) Multi-Gaming Competition: At our school, agroup organized a multi-gaming competition in 6stages. We decided to participate with a team madeup of members of S.O.N.I.A. It was very nice tohave a little competition every month. We are in abattle for the top position and we are waiting forthe latest results
