Skip to content

Overview Notes

Jump to bottom
IsaacWax edited this page Aug 22, 2024 · 5 revisions

7-13-2024 Notes

In the design of this stack up I am hoping to reduce the count of boards while keeping modularity. I plan to separate high risk systems out into their independent boards so if the first rev does not work out we have an isolated system to work on.

I plan to have three separate housings excluding sensors/ cameras

List of housings:

  • Main electrical box → this will hold all of the main electronics and will either be created out of sheet metal or machined out of something thermally conductive like Al
  • Battery Housing → this will house the battery and possibly a management/ status PCB. It will be a costume box machined out of Al
  • Hydrophone Housing: This will house all hydrophone signal processing circuits and mount to the hydrophones. I expect this to take a long time to develop and there could be noise problems from it crossing with the bandwidth of the ESCs, so this system will be isolated. This will be on the low priority end of the list and will be worked on last

List of sensors

Sensor Function Interface With
IMU Navigation Serial → Hardware Board
DVL Navigation Ethernet
Hydrophone Navigation Ethernet/ CAN
Cameras Navigation Serial/ Ethernet
Pressure Sensor Navigation Hardware Board
Temperature/ Humidity Status Hardware Board
Battery Voltage Status Hardware Board/ Backplane
Leak Detection Status Hardware Board/ Backplane
ESC Dshot Status/Navigation Hardware Board/ Backplane

List of Boards

  • Power/ Battery Management board → This board will will measure the voltage level of the battery and report it. Must also display this onto a screen that is viable to the operator. There should be status lights and possibly and alarm that is set off that indicates when the battery has been discharged past a safe level.

If we do a redundant two battery system, we would need a way of switching between the two using some high power mosfets. I do not think that this is a smart idea unless we find a good reason to do it like this.

I think that If we can spec a good OTS battery it would make the most scenes to just use on battery in a housing and have it connect to a management system in the main electrical box

  • Backplane Board → This board will hold all of the electronics that directly interface with hardware. The power from the Battery Management board will be converted on the back plane and there will be routing signal wires

    • Vin → 12V Power Bus
    • Vin → 9V Power Bus
    • Vin → 5V Power Bus
    • Vin → 3.3V Power Bus
    • All power buses must have capacitor banks, fusing, zener protection and status lights
    • ESC Power Bus → This power bus must me separated from the other components. It will need to be able to disconnect via mosftes witch will be used in connection with the kill switch board for an emergency shutoff
    • Must have a plugin for the ESC boards and provide power to them. Also must rout PWM and Dshot to the hardware board.
    • Routes wires from leak detection sensor to Hardware board
    • Have Backup power connection ports on all busses (must be able to plug in jetson, ethernt switch, and other hardware external to the stack)
    • Need bench testing power in port for when we are not using the batires.

  • ESC Board → This behaves as a carrier board for the 4 in 1 ESC module. This must be a plug-able module that plugs into the bottom of the backplane and connects to its power bus. Must also route signal wires to the hardware board. It would be cool to make it so this module has an RP2040 on it, but since there are two esc boards, this may add extra complexity for not good reason. I think that this would make the software architecture much more difficult and and we would be required to write a custom prototypical instead of using micro ros.

It would be nice to find an edge style connector that will allow for this to be a card style module instead of the configuration we have on the current Seahawk II

  • Hardware Board → This board will sit on top of the back-plane board acting as an interface for all hardware interfacing. It will either hold CM4 or something from the RP family. We want to avoid having to interface hardware with the Jetson board.
    • There will be an Pi that interfaces with this board that runs ros and connects over an Ethernet network. It will interface with everything on the board over UART, I2C, CAN, Dshot and SPI. It will also use GPIO pins to trigger status lights and switching circuits
    • There will be one or two MCUs on the board either the RP2040 and required peripherals or Pi Pico boards. These will be responsable for control of ESCs and Servos. For the battery management board, I am still trying to decide if we want to have a separate MCU or just route it on the back plane.
    • Switching: we need mosfet switching modules in both 12V and 5V for driving solenoids, external lights and internal cooling fans. Not sure if theses will be driven by the Pi GPIO or an RP2040.
    • Status lights
    • Extra ports for each protical labeled for easy debug. Add probing pins on literally everything
        TXD RXD CTS RTS     Board Pins
uart0   14  15              8   10
uart1   14  15              8   10
uart2   0   1   2   3       27  28  (I2C)
uart3   4   5   6   7       7   29
uart4   8   9   10  11      24  21  (SPI0)
uart5   12  13  14  15      32  33  (gpio-fan)

From Devices Listed on Pi:

raspi-gpio get 0-15
GPIO 0: level=1 fsel=3 alt=4 func=TXD2 pull=NONE
GPIO 1: level=1 fsel=3 alt=4 func=RXD2 pull=UP
GPIO 2: level=1 fsel=4 alt=0 func=SDA1 pull=UP
GPIO 3: level=1 fsel=4 alt=0 func=SCL1 pull=UP
GPIO 4: level=1 fsel=3 alt=4 func=TXD3 pull=NONE
GPIO 5: level=1 fsel=3 alt=4 func=RXD3 pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=0 func=INPUT pull=UP
GPIO 8: level=1 fsel=3 alt=4 func=TXD4 pull=NONE
GPIO 9: level=1 fsel=3 alt=4 func=RXD4 pull=UP
GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 12: level=1 fsel=3 alt=4 func=TXD5 pull=NONE
GPIO 13: level=1 fsel=3 alt=4 func=RXD5 pull=UP
GPIO 14: level=0 fsel=4 alt=0 func=TXD0 pull=NONE
GPIO 15: level=1 fsel=4 alt=0 func=RXD0 pull=UP
pi@raspberrypi:~$ ls /dev/ttyAMA*
/dev/ttyAMA0  /dev/ttyAMA1  /dev/ttyAMA2  /dev/ttyAMA3  /dev/ttyAMA4

video on how to enable uarts in ubuntu

Looks like we would either need to sacrifice the spi or i2c bus for a second two uarts?

  • Kill Switch Sensor Board → This needs to switch the ESC power plane off on the backplane board when triggered from outside of the electrical box. This could either be done with a light gate and some type of mechanical cam system. Or some type of magnetic read switch. Could this jut tie the RUN pin the the RP2040 to low or does it need to cut power?

  • Hydrphone Board → Need to do a lot more reading and will save this one for later. Will do all the mixed signal processing

cool artical

Other OTS Parts

  • jetson → TBD must setup simulation to see what are requirements are. Some boards do not have full do not have update Ubuntu support so may need to use docker, not sure how annoying this would be. It is not interfacing with any hardware so may not be that bad
  • ethernet switch → TBD would be cool to make this custom, but with limited time and people, we will probably get an OTS one
  • cameras → TBD looking at Zed and Explorer HD. This is dependent on what we want to do with VSLAM
  • IMU →
  • DVL
  • *Presure
Clone this wiki locally