Hello all - I’m an electrical engineer excited about working on products and systems for the underwater robotics industry and I’m thinking of creating a system of smart batteries. In particular, I was thinking the BlueROV would really benefit from them. The current process for charging and working with the BlueROV batteries reminds me of the early days of drones when you had to use balance chargers and also kind of guess as to the State of Charge (SoC) of the battery, ending flights early, damage due to over discharging, etc. I’ve previously worked in the drone industry for 10 years and developed a series of batteries for drones and learned a ton!
The battery I would like to create would be a cutting edge smart battery with the following key features:
State of Charge (SoC) accuracy of 2% or better
Protections for under voltage (over discharge), over voltage (dangerous charge level), short circuit current, over/under temperature, etc
Charging via a standard USB C laptop power delivery charger
Rugged charging cable attached/detached without tools
Auto cell balancing internally
Sends status values back to the BlueROV navigator computer for display in QGC.
Internal heating system to allow the battery to run optimally in cold water
Deep rated (600m+)
I created a quick survey here to gather what specs the community would most like to use here:
I’ve also created a quick diagram to show the architecture:
Depending on specs, the battery might cost around $1K and the charger around $300.
I would really love to hear what the BlueROV community wants. Is this something you would find helpful? I would love to hear more about what features people really need and which they don’t and be able to come up with a super helpful solution. Thanks in advance!
I am always interested in new power solutions for the BR2 because I currently swap batteries more often than required due to the limited battery monitoring and protection available.
I have also experienced battery fires and overheating of the power distribution system, so safety is paramount!
Since the OEM batteries get the job done, would it be more cost-effective to create a new BMS that helps operators manage power and battery usage? In my circumstances, running the heavy version along transects in strong currents with DVL and UGPS requires careful power monitoring so this would be a feature I would like to see introduced.
It is good to see you working on different Wh ratings to help with logistics. Someone else was looking at parallel systems a while ago however this work seems to have fallen by the wayside.
Cost-benefits would also need to stack up. Surface power becomes the most effective solution if batteries become too expensive or operationally challenging.
Hey Jason, thanks for the info. Yeah I was considering just doing a add on BMS but I think there are a number of reasons it is better to just go with a full on battery:
Most important is safety. Having to periodically access the internal battery chamber to charge, with lots of exposed conductors is risky. If we added an external connector and BMS to the existing enclosure, the only difference is that you would be able to reuse some parts. Then you effectively have an end user assembled battery, with highly variable quality.
I also don’t think you could probably add a BMS with the features I am shooting for to the existing enclosure - there wouldn’t be quite enough space. My design relies upon high electro-mechanical integration to fit it in.
I think external quick disconnect connectors is also crucial. If you are cycling a critical seal (the battery enclosure O-ring) every charge then that increases the likelihood of failure over time.
I feel like surface power is not always the best option too. The cost of those Outland technology units is really high. $6200 top side unit + $2200 tether + $6400 vehicle side unit = $12800. So this battery setup could be an order of magnitude less expensive. If you need a very thin tether that could be an issue too. Or if you don’t have a generator.
Yes, I agree, opening the battery enclosure to replace batteries at sea creates a lot of risk that I would love to avoid.
Some members of the BR2 community (and other ROV manufacturers) have already created quick-change batteries and I often think about creating a similar system myself however I just never get around to doing it.
Hey all - I’m working on finishing up the overall system and mechanical design. I’ve switched from the concept of using multiple connectors as shown in the posts above to now just using a single 4 pin Cobalt 14 connector for power and communications. These are big enough to handle the current for BlueROV and also the data pins are large enough to be very robust for tons of mating cycles.
To charge it you will just unplug the Cobalt connector and plug in the USB charger cable.
There will be a very small PCB added to the BlueROV electronics enclosure that contains a protocol converter board that converts from communications available in the battery pack to other options such as I2C, UART, CAN, etc. I think the best option for getting the data into the BlueROV will be via SMBus (I2C) which is one of the standard interfaces for smart batteries available in Ardusub. I haven’t done a full vetting of this yet though. If anyone on the Blue Robotics team has advice or would like to partner on this that would be fantastic!
The red rotary switch is a method to force power states on the battery.
Now targeting a price of about $750 for the battery.
Would love to hear feedback and suggestions especially before prototyping to make sure this thing works for as many people as possible.
Hi @finfish -
Love to see you working on this!
Ardusub does not use I2C for voltage current measurement - the Navigator or Pixhawk (or whatever autopilot) reads an analog voltage output from a voltage and current sensor output… if you’d like to do digital comms, I’d think serial (3.3V TTL) would be best!
Also, the 4 pin cobalt connector is great! However, You’d have to use all 4 pins to get enough current to run an rov - one pair, at 35A, isn’t going to be sufficient (even using all 4 pins may have issues with high-gain long duration operation…) I don’t see an option on the BlueTrails website for a 4 pin “hybrid” connector, only 10 pin?
10Base-T1S is amazing and definitely something the Blue Robotics team is considering for future communications protocols…
What diameter enclosure is that? 3" ?
From a safety perspective, the most critical thing for charging multi-cell lithium batteries is balancing. This requires a balancing circuit to have access to each cell voltage, so if this is external, like the connector on the H6 charger, you’ll need 5 pins (4 voltages and ground.) This is very important’! You’ll also need to charge with the constant current, followed by constant voltage charge cycle, at the 16.8V nominal 4S battery voltage…
As far as I can tell, BlueROV is configured to use an analog voltage output type sensor for both current and voltage by default, but the core Ardupilot code has many other options for battery monitoring, including SMbus. This is edited via the “BATT_MONITOR” parameter. I’m thinking I can use the option “SMBus-Generic” and set the associated “BATT_I2C_BUS” and “BATT_I2C_ADDR” to match the I2C bus that is physically present on your navigator PCB? I can’t see how this would not work?
Regarding your suggestion for 3.3V serial - do you mean an actual UART or I2C? I didn’t see an option for a UART battery monitor but I could consider that if you think that would really be the best fit for your navigator PCB.
Regarding the Cobalt connector - I have discussed the ratings with Blue Trail Engineering and they have said that the ratings they publish are very conservative. There are really two considerations when it comes to current ratings in connectors and wiring: voltage drop due to resistance and the thermal heating associated with this. the cobalt 14 - 4 pin uses approximately 3.5mm bullet connectors internally, which are the same as the well known and characterized XT60 connector, which is “rated” for 60A continuous. The cobalts also use high temperature PEEK insulation plastic around the contacts vs the nylon used in the XT connectors. Additionally, the rating of the cobalts I believe is for all 4 conductors conducting 35A simultaneously vs the two in my proposed use case, so the heating will be much less. Blue Trail sells a Blue ROV Cobalts standard series connector battery conversion kit that uses the smaller size 4 pin cobalt connector and does use two wires each for ground and battery V. They rate these at 20A each, so a total of 40A is the published rated value. I assume people have been using these kits without issue so that is a nice existence proof as well.
The right thing to do is do a test: I’ll try to run current through the proposed connector and take some thermal images or thermocouple readings of the pins.
There is a helpful post where the max current of the BlueROV is discussed by Adam from Blue Robotics here:
It sounds like typically BlueROV uses around 20A, and peaks around 60A to 90A for a few seconds. I would love to see some more data if anyone has it for very aggressive maneuvering?
Yes, my batteries will be using T1S ethernet natively. If you’re next gen ROVs are going to use that it would be awesome! I’ve love to help with a standard spec development too.
Yes, I’m planning on matching the enclosure dimensions of the existing 3" battery enclosure.
Regarding safety - yes, the charger will perform the standard CC-CV charging method and cell balance will be handled by the BMS that is inside the battery enclosure.
Hi @finfish -
The I2C monitor should “just work” if the autopilot knows how to communicate with the sensors you’re using. Let us know what you find! You will indeed need to edit the parameters as you mention - this I2C bus is already in use by the autopilot to read the pressure / temperature from the Bar30. I wasn’t sure if you were using an off the shelf module, so thought UART could be a development path potentially.
I’d recommend testing the Cobalt connector with the actual load of the ROV - the transient, short term currents the system can pull may be in excess of 100A, at least for a heavy operating aggressively at 100% gain…
It seems you’re thinking of all the right things otherwise!
By the way, in ArduPilot we’re working on an open source BMS software based on the AP_Periph software which is basically the ArduPilot flight code sensor drivers running on smaller STM32 based boards which normally don’t include IMUs and other sensors that an autopilot would have.
VimDrones is helping me by creating a BMS development board which could be the basis for various manufacturers to create smart batteries.
