8. Advice from past leads

This page is separated by lead because not all leads agree. Antoine and I had many differences of opinion during our leadership together so I thought it would be best to organize thoughts separately in case there are contradictions.

I thought it was important to have this page because valuable advice is slowly lost as leads come and go. Leads also typically lead in a way that is fundamentally different from their previously lead to address their short comings. This is fine, but if they over correct then their successors might over correct the other way back to square one. For example, lead A is too hands off, lead B decides to lead more hands on but over corrects and is too hands on, lead C takes over and takes a hands off approach repeating the mistakes of lead A. Having the lessons learned from all past leads could avoid this issue.

2023-2024 Anthony:

Working on the AUV was a once in a lifetime experience I will never forget. My inbox is always open to AUV members.

• Euler angles are trash. Quaternions get the job done.

• Don't bother giving lectures if members aren't either taking notes, or are going to be engaging with the material in the foreseeable future. For example, its best to teach PIDs if you plan on tuning PIDs at the upcoming pool test. I tried giving many lectures at the start of the year about important topics, but relating to problems the new members were not working on. The information went in one ear and out the other, and I don't blame them. People don't have photographic memories, they don't remember if they don't study or practice.

• If the business team asks for something, do it right away. Do not procrastinate.

• If the business team is not getting enough done, work with them, not against or around them.

• During pool tests force new members to take control. Doing this with Nathaniel and Raina at comp 2024 was the quickest I've seen new members learn. Even if it slows productivity down during the test they will learn so much more that it will payoff ten times.

• Do be too trusting of what people say in interviews. Everyone will say they will commit 5+ hours a week outside of meetings. Odds are none of them will. Consider yourself lucky if they commit 3. Its better to accept someone who is honest and realistic about the work they can put into the project. The people we hired who said they would do 7 hours did zero. The people who said they would do three, did three.

• Don't reinvent the wheel. Writing our own controls package from scratch was fun, but ros_control might have done the trick (not too sure). robot_localization was for sure a better choice than what we were doing before in state estimation.

• Keep things fun. Making pancakes for everyone before Saturday work sessions always goes well. Bonding among the team is important.

• Don't keep things too fun. If non-dedicated members have a reason to stay other than the project they will. Applying a little pressure to members goes a long way for productivity and also eliminating non-committed members.

• Patiently explain how things work to non-software members when they show curiosity, especially at pool tests.

• Forgive all technical mistakes and errors. As long as they are trying their best and are putting in effort to learn, then be thankful for their work. Everyone here is volunteering their time after all.

• Have a zero tolerance policy for bad behaviour. Bigotry, discrimination, picking fights, back talking are unacceptable behaviours.

• Invest in your tools. Keep version of ROS, jetpack, packages, etc up to date. Master git, docker, bash etc.

• Make sure the robot is not out of commission for more than two weeks. If you plan to redo the tether make one around the extra subconn instead of breaking the old tether subconn. Only get rid of it after the new one works.

• If the thrusters are making weird noises they need to be spun in water. Don't use oil. Like cars, they are designed to be moved, not sitting around.

• Don't forget how expensive everything is. If you carelessly break the DVL then that's the end of the AUV project. I can't imagine a realistic way to recover from that.

• I suspect that recruiting people who keep reapplying is a good idea. I wanted to do this in February 2024 but was overruled.

• Don't recruit too many people at the start. You can always add more later. It's really challenging to narrow the list down, but find a way to limit yourself to 8 max.

• During recruiting, it might be a good idea to ask people to do the git tutorial to qualify for an interview. This risks cutting out too many candidates but would be a good sign for those who remain.

• Windows sucks for development because it is not POSIX compliant. Consider dual booting linux.

• When placing the robot in the water, do it slowly and check for bubbles every time. Thankfully there have not been any major leaks with Dougie as of yet. With Clarke there were 2. The first one was caused when the epoxy from the back end cap broke. The second was caused by human error. In both cases the AUV flooded majorly. Somehow we were still able to compete that year and not do that bad, but I consider us extremely lucky.

• The pre-covid code is archived here https://github.com/mcgill-robotics-archive/ [Antoine edit] Also there are ARCHIVE branches which are snapshots of the codebase at different points in time.

• Automatic integration testing will save you so much headache. Github actions saved us from merging bad code on many occasions.

• Gazebo sucks ass. Unity is way better. The major downsides of Unity are that it is closed source, heavy weight, and works terribly with version control systems. Godot is better at these things but worse at others. I'm hopeful that in the future the ROS integration with Godot will be good enough for it to be a first choice sim. If a new sim is needed for AUV or another mcgillrobotics project, consider Godot (but probably go with Unity).

• When promised money from an organization, especially SSMU sign a contract. Verbal agreements don't work.

• Don't forget during pool tests you can have multiple people ssh-ed into the jetson at once. Someone can be running code, while another is echoing, another bagging, and another visualizing.

• Don't buy expensive equipment too far in advance. Warranties typically last one year.

• Simple nodes should be written in cpp.

• Don't forget how dangerous the AUV can be. No matter how confident you are in the software its always possible for imu to come loose and for the AUV to freak out,

• It's possible to get credit for your work on the AUV if taken as COMP 400/396. However, you would need to reserve a large task only for you and it would need to be sufficiently researchy.

• Don't let any one person swim too much. This gave me a terrible ear infection and I almost missed comp 2023. I went on that flight against doctor orders.

2023-2024 Antoine:

AUV was very fun and I learned a ton. My inbox is also always open to AUV members. Also, I'm not going to repeat points Anthony said so make sure to read those too lol.

• Pool tests are insanely important. Every year its a battle (software wants more pool tests, electrical/mechanical want to focus efforts on the new components and don't want to spend time fixing the old stuff so software can use it), so make sure you really insist on the importance of early and consistent pool tests.

• I second what Anthony said about re-inventing the wheel. However, it's also important to know when to ditch a tool. We used Gazebo for a few months for simulation, but (thank god) decided to ditch it and move to Unity. In general, if the tool you use has little documentation, or little customizability, be on the lookout for an alternative. Don't be afraid to implement it yourself if necessary.

• Make design decisions carefully. On software, it's easy to sink hours or weeks into work that does not end up being used. Make sure that if you are deciding to use X programming language there is a valid reason. You can make mistakes, and that's fine, but I would warn against motivating design decisions because of what's "shiny" or "cool". The age-old (amical) battle I had with Anthony was Python vs. C++. I personally think that trading development time / needing to re-compile code for small code changes / the pain of debugging C++ is only worth it if the speed increase is equally or more beneficial for the project, because Python is indeed very slow. Same thing applies to ditching ROS, using other languages like Rust, etc.

• Similarly to the previous point, it's very important to have a points-centric perspective on software efforts. It's very tempting to add more features to the sim, or to make workflows even more seamless, but at the end of the day that work does not translate efficently to points at competition. I would recommend to always always focus on building, testing, improving on the fundamentals first.

• Don't hesitate to reach out to other software leads, or alumni. Oftentimes they have a lot of insight and knowledge that you would otherwise spend lots of time figuring out on your own. Not only that, but everyone I have reached out to has been extremely welcoming and excited to help out (people love to be flattered, so saying "you're so smart please help" works well).

• Document consistently and try to share knowledge as much as possible. A lot of time can be wasted if only one person understands a particular package, and they happen to be sick, absent, or just leave the team. As an example, Anthony was the state estimation / reference frame / controls guy. Even though he still is, we would make efforts to catch up every once in a while and have him explain how things worked. It helped a lot over the Summer when he was working his internship with a time difference, and we were still able to make changes and debug code we hadn't written.

• Always raise an eyebrow if you hear "we can just fix it in software". That's a recipe for failure, since Software is essentially the last line of defense for the entire robot. Always always try to encourage electrical and mechanical to make designs which make Software's life easier, not harder. There will have to be compromises of course, but those compromises should be educated decisions as much as possible.

• During pool tests, having several members with computers makes it so much smoother. We (for whatever reason) would always have one software member designated as the person who ran commands. It actually goes way way faster with two or more people running commands from different terminals. Also, it allows two people to learn things (and potentially bond a bit) which is better too.

• If possible, try to get a designated "pool test" computer set up. It should run on Linux and have the dependencies (docker, git) set up. Too many times we've been stuck because no one had a laptop with Linux installed. Also, pool water often splashes near the computers so it's nicer if that computer does not contain someone's whole life inside it.