Background
Back in February I was undertaking preliminary sea trials of the first deployment of the DeepSouth ROV. I later also integrated on the bench the Ping 1D when it was released and ran the whole lot over web based mobile phone interface.
While the trials were successful, towards the end I noticed some control issues and later determined the CPU on the single Raspberry PI (that was controlling everything) was heating up to 90 degrees centigrade. This is well beyond recommended and likely cause of the issues. This led to a re-designâŚ
Design Considerations
The design considerations were roughly as follows:
Minimise load on CPU and add passive and active cooling
Allow for multiple cameras with minimal latency by using dedicated CPU
Allow for multiple sensors if desired including the possibility of on board (multiple) Ping 1D processing for navigation / obstacle avoidance - without the possibility of impacting on cameras or motion control
Off load PWM control to a dedicated controller with plenty of expansion capability (ESC, Lights, Gripper, Camera Orientation)
Simplify power provisioning and cabling as much as possible - i.e. off the shelf rather than custom
IMU and control is something routinely handled by an 8bit microcontroller. Have you measured the relative CPU usage? I think a whole PI for that is overkill. I think video encoding is probably the major source of CPU work here. Could this problem not be better solved by an ethernet camera module with onboard H.264/5 encoding and a small ethernet switch bottom-side?
The âsensor controllerâ Raspberry Pi does not just manage GPS and IMU - which as you say are light on CPU, but also the other sensors such as depth and ping.
You can see a need in an autonomous scenario for the ROV to be undertaking its own sonar navigation and obstacle avoidance - potentially with many ping type devices working together. This is going to be much more CPU intensive.
The approach suggested can also easily allow the CPU load to be shared across other Raspberry PI controllers with capacity at slack times. There are many options for clustered Raspberry Pi computing software (e.g. picocluster). The extra 12 USB ports provided are also potentially quite handy for additional cameras and pings!
The overall goal is to get as much compute power onboard the ROV as possible, as cheaply as possible. The distributed computing platform can easily be expanded into additional payload enclosures to suit the application just by adding more clustered Raspberry Pis. As it stands, there is much more CPU capacity and potential future capability available than the current standard BlueROV2 in the same enclosure space while still allowing for same hardware management such as ESCs etc. (no disrespect to the great BlueROV2 package and Blue Robotics team!)
If youâre trying to get more computing power onboard the ROV wouldnât you be better off with some more powerful SBCs such as: nVidia Jetson Nano or ones with a more powerful SoC e.g. RK3399 on the NEO4?
I just imagine space becoming a premium for all the Raspberry Pis and it may prove more economical to have fewer, more powerful SBCs rather than the expense (and drag) of adding extra enclosures.
This was also suggested to me privately in a PM from @Bjarte.
This looks like a really good option but I am nervous that the existing python libraries for the various hardware components are too Raspberry specific and donât migrate well.
I use 3rd party libraries for:
Camera image [probably not an issue]
PWM control (lights, thruster, gripper, and camera tilt) [probably not an issue]
IMU (heading, pitch, roll)
GPS
Internal Temp / Pressure
External Depth / Temp
Ping
Also heat is a significant factorâŚthe Jetson looks heat intesiveâŚ
I know you want to use the phone as the interface but why not put the other raspberry pis (or even a laptop) on land where they are less fragile, easier to work on, etc. All of these things would give you access to the best of modern compute horsepower while still providing you with a simple way to bridge control to your phone. I will PM you a project we worked on.
You are right that I could use a laptop to boost computing power on the surface but my solution drives everything from a web server hosted directly on the ROV.
This means that from a control and management perspective, it does not matter whether I am using a phone, laptop, or desktop at the surface (or for that matter what make, model, or software installation I am using).
I am trying to boost computing power under the water rather than on the surface as if the ROV is in autonomous mode, it wonât have access to the surface resources for real-time processing.
The Nvidia Jetson Nano was released early 2019, making the Raspberry PI look a bit sadâŚI am currently porting all my python code that ran the web-based Raspberry PI ROV over to the Nano for increased performance - there is even NodeRed for the Nano available as a pre-built install. An updated illustration of the new architecture is below. Thanks to @earthling bx10 for the encouragement!
One very interesting video is the 3D mapping using the Jetson Nano and the Stereolabs ZED camera. These USB cameras tend to come with the IMU (i.e. heading, pitch, roll, etc) already integrated - handy!. It does assume a level of water clarity but possibly worth a trial.
Just an update on progress as itâs been a while. To recap, my key requirements are:
A mobile web browser based control interface
A high amount of onboard computational power for things like AI in âoff tetherâ mode
Something that stays cool and never gets thermally throttled
Technology wise it has so far been a disruptive year. March 2019 saw the release of the NVidia Jetson Nano (potentially ideal for AI). Just 2 weeks ago saw the release of the Raspberry Pi 4B - much more powerful but with a current âfeatureâ that it runs much hotter than the previous versions.
It has become fairly obvious that using the Raspberry Pi for it computing capabilities rather than say just as a passive camera server will require active cooling with fan(s). I have also been seriously contemplating onboard water cooling within the enclosure
The desire to still fit within a standard 4â enclosure means that serious consideration of space and cooling needs to be undertaken. The positioning of supporting boards (e.g. PWM, IMU, GPS, ESC, Power regulation/ distribution) is critical.
I am currently waiting for my RPI 4 (4GB) to arrive but itâs a bit of an uncertain time right now as both the nano and RPI are still getting their bugs ironed out and becoming more widely supported.
You keep worrying about heat and have mentioned âonboard water cooling within the enclosureâ.
I assume you have an ROV with an aluminum housing which will be immersed in cool water?
Why not just machine a heatsink that conforms to the inside curve of the ROV housing and allow the aluminum ROV housing bathed in cool water to leach away any heat? Thatâs what i did with my ESCâs.
I believe there are a number of reasons why an aluminium enclosure would not be ideal due the functionality that you might want to be seen through the enclosure. Also due to the tight integration and the HAT stacking via the GPIO headers you would not have space to heat sink to the outside of the enclosure (with my design anyway ). The stacking keeps wiring to a minimum.
Also I think the body of opinion on YouTube is that with the Raspberry Pi 4, a heat sink (even a really large one) does not cut it with intense use - you need active cooling. With active cooling you can also happily work on the bench, out of the water without fear of overheating.
Below is a plan of what I am currently looking at. This could change at any time!
To be honest the idea of using a bluetooth switch to turn on the computer, and then from the computer dashboard, using a relay to power motors and lights only occurred to me tonight and requires a bit of research. Thatâs really elegant if you only want to use the computer say for configuration without using all your battery on powered up ESCs and motors.
Ok, yeah, i donât use Pi HATS, i use an SSC32 servo-controller connected via I2C. So for me, nothing in the way. A 32-channel ADC from FERCSA on Tindie connects my pots to the R Pi topside.
Active water cooling inside the enclosure is quickly going to raise the inside air temperature, unless you run lines outside to a heat exchangerâŚ
Raspberry PI 4 with integrated dual fan, aluminium heat sink case, 16ch PWM board, with GPS and IMU. On the base is quad USB power supply from battery.
). The stacking keeps wiring to a minimum.
