2023-2024 Qubo Software Projects

End-effectors

This includes: torpedo launcher, claw, marker dropper.

marker dropper = device that releases a small object, a "marker" that is identifiable to our team. A recurring RoboSub task is dropping markers into bins.

Jeffrey Fisher: My understanding is that these end-effectors are not complete, but that we can work with prior iterations. Even if it won't go on the robot right away, it will be worthwhile to get the code in place so we are ready when mechanical finishes the new designs, and to begin testing the functionality. Testing is very important because accuracy is important for all three of these end-effectors.

New DVL (1-2 people)

We've purchased a new, much smaller DVL (doppler velocity logger). The model is WaterLinked's DVL A50. For information on what a DVL is, and about this specific model, see the BlueRobotics DVL A50 page.

Project overview

• The DVL speaks JSON over TCP. See WaterLinked's protocol documentation.
  • There is also a serial interface, but we will not use it because (1) it is slower and (2) I'm pretty sure one reason for getting this DVL was that we can talk to it over Ethernet --- Jeffrey Fisher.
• Goal: Setup communication between Qubo's main computer and the DVL.
• Goal: Make the DVL data available to the rest of the code over ROS.
• Language: Likely C++
• There are existing libraries for interfacing with this DVL. It is probably worth evaluating them.
  • At a quick glance, this one seems worth checking out: https://github.com/paagutie/dvl-a50. It's already using the JSON library I was planning to use, so if we write our own in C++ it will probably be quite similar to this one. --- Jeffrey Fisher
  • Here's a bunch: https://github.com/search?utf8=%E2%9C%93&q=dvl+a50&type=repositories
  • Jeffrey Fisher: Some things worth considering:
    • How often will we have to change this code?
    • How likely are there to be bugs?
    • Will depending on a 3rd-party ROS library make it hard to upgrade in the future? How separate are the DVL protocol and ROS portions of the 3rd-party library? How hard would it be to patch the library ourselves for a newer ROS version?

Embedded software

Electrical team is redesigning the electrical system to use a backplane. If you've ever seen a computer motherboard, that's basically what a backplane is. Instead of a mess of wires, there will be several "daughter cards" that slot into the backplane, and will communicate over wiring inside the PCBs.

Each of the daughter boards need to be programmed.

Daughter boards

WIP: This section is rough, just taken from Alex's notes from a meeting with Erik.

Thruster control board (x2)

• Each thruster control board controls 4 thrusters, for a total of 8 thrusters.
• CAN node
• UART node
• Receive heading information from Jetson (6-vector float?)

Power board

• CAN node
• UART node
• 5 Current Monitoring ICs, 1 for the whole system, same outputs as the monitors in the thruster control card
• eFuses (2 of them):
  • Communicate with outside world using digital output (whether I'm open or not)
  • Should be logged for diagnostics
• Enable pins (think power buttons for individual components)
  • 1 for the thrusters and almost everything else, 1 for the Jetson
  • Considering a shutoff for each individual sensor, great for diagnostic purposes

Diagnostics

• Polling for current and voltage information from the CAN bus (probably can be done on the Jetson)
• Home-cooked boundary scan: Do a full scan on startup, shutdown, and if serious fault detected.
  • Send a stimulus to the pressure points, and measure the response.

Jetson

• CAN: Send heading information to the thruster daughter cards
• CAN: Get power information from the power daughter card

CAN Bus

CAN bus is a protocol for communication between microcontrollers and devices. It is used in motor vehicles.

As of right now, this is the planned protocol for communication between daughter boards.