T200 pwm vs current graph

Blue Robotics Products Thrusters and Motors
1

Hello there,

So i have bought 2 pairs of T200 thrusters for my marine robot. I am using a 14.8v (4s LiFePo4) 45Ah (yes, Ah) battery along with blue robotics basic ESCs 30A. When driving the motors, i checked the power characteristics in my GCS using the power sense module (Message: Sys_status). The graphs in the technical details of the T200 shows that it can draw upto 17A at12v at full pwm (1900 microseconds). But during my observations it was taking very less than what was shown in the graph. Not only the peak, but even at lower pwms (1700, 1800) it was drawing much less than specified.

I have also verified the drawn current by using a regulated DC power supply, there was no change.

Am i doing something wrong or it is supposed to work like that? Below i have shared a few observations

PWM Current at 12v
(rated- graph)		 Current at 14v
(rated- graph)		 Current at 13v
(Observation)
1700 3.3 A 3.9 A 2.9 A
1732 4.8A 5.6 A 3.5 A
1776 7.2 A 8.7 A 5.3 A
1800 8.9 A 10.6 A 6 A
1835 11.62 A 13.72 A 6.25 A

Does this affect the thrust of the motors too, like in low current = low thrust??

2

Hi @Jarvis1310, welcome to the forum :slight_smile:

There’s some nuance in the measurement and reporting of these values. For reference, the technical details on the product page are for static bollard thrust, which is a measurement of the maximum thrust that can be generated at a given input command (and corresponding maximum power draw), under ideal conditions for thrust generation.

From your description I suspect you may be measuring the values at some speed, which covers a whole space of values that we don’t currently have data for.

I’d also recommend measuring the supply voltage at the ESC, to ensure there are no significant drops along the way (from an insufficiently strong power supply, or through wire/connections resistance) - there’s some related discussion in this thread.

There’s some kind of correlation there, but the causation is the other way around. There is some baseline of current required for the motor to spin itself at different speeds, and then additional current required to push water (thrust) using the propellers. In environmental/setup conditions where the propeller cannot engage as effectively with the water (e.g. because the water is slipping past by itself) the motor spins more freely, resulting in (generally) less current draw.

3

Thank you @EliotBR , it was good to hear from your side. Now I’ve much clarity on what exactly the graphs depict.

Does the relationship between pwm and rpm of the motors static, or it might again depend on environmental factors?

I just wanted to design a control logic such that i can control the differential speeds of 2 thrusters by bypassing the rc channels.

4

Hi @Jarvis1310 -

There is definitely not a static relationship between pwm and RPM. For a given PWM, the resultant RPM depends on the battery voltage, and the choices the firmware of the ESC makes given its own temperature, the sensed rotation rate of the motor, and naturally this varies by ESC firmware!

When testing in a tank, the test only runs for a very short period - after that the water gets moving in the tank, and the thruster actually loses thrust, rpm increases, because the incoming water already has velocity!

If you’re trying to control the heading of a vehicle with two motors, using a heading sensor to “close the loop” and adjust PWMs to each thruster to correct heading error is the typical approach. The thrusters in general don’t have a linear speed response - so opposite pwm does not result in opposite thrust! The force produced by propellers in water is typically asymmetric - they can push harder in the forward direction than reverse.

5

Hey @tony-white , good to hear from you.

I am using a 13.3v battery along with the blue robotics basic esc (30A). Now from the given data, can i use the graphs given in the “Technical details” in the page of T200 thrusters?

By graph i mean the median of 12v and 14v, would it give me an approximate (but static) pwm vs rpm ratio?

I understand that the thrust would differ in opposite directions, but i am planning to correct any drift by using the DVL data as feeeback. Would it work?

6

Hi @Jarvis1310 -

For an approximation of the RPM at a given PWM value, that chart is indeed the best reference point. However, it’s worth asking an LLM to explain how ArduPilot handles PWM outputs to control position or orientation - while velocity from a DVL, heading from a compass magnetometer, or position from a GPS can indeed be used as feedback to correct positional drift, it is certainly not a 1:1 mapping! Knowing how RPM relates to PWM should be unnecessary…

7

I think it would be helpful if you take a step back and describe what you’re actually trying to achieve. If you have a position estimate and a feedback controller that’s using it, trying to estimate motor RPMs feels quite useless, given even the RPM-thrust and RPM-power draw correlations are dependent on the speed of the water, along with the electrical and software dynamics involved when a PWM request is sent to the ESC to change its set-point.

As an example, if you’re trying to reduce power usage when it gets too high, you can scale down all the PWM values dynamically, and then increase/restore that scaling when the current usage decreases. That is reliant on your system having some capacity to handle short spikes of current while it adjusts, but you can use the current estimates in the technical details to get an expectation of how large that maximum current draw might get.

8

Heyyy @EliotBR ,

My basic idea was to control the thrusters based on the following static graph manner:

PWM->Current->Thrust

Initially the idea was to get the current feedback from each thrusters to determine the thrust and therefore dynamically change the PWM.

Now as the current-pwm graph is the *Max current @pwm*, then it wouldn’t be useful in this case.

Then i thought of using: PWM->RPM->Thrust. But again measuring rpm in water would be hell of a work.

Now i am working on dynamically generating pwm by taking DVL velocities as feedback and integrate them to get position estimate. Also as you mentioned, the magnetometer could be used to get heading estimate. I could use those position and heading estimates to correct any drift.

Just to be sure, do you think it might be a good idea?

9

There are ESCs that report the RPM the motor is currently at, but because the generated thrust depends on the existing flow properties (speed, turbulence, etc) of the water, the motor RPM is not a great estimator of thrust anyway.

It can potentially be used together with independent measurements of vehicle groundspeed or speed through the water (to estimate one or the other), but that doesn’t seem to be what you’re trying to do.

These calculations and control algorithms are the job of an autopilot. Are you intending to write your own autopilot (in which case you’re considering good questions), or would it make more sense to use an existing one (like ArduSub/ArduRover) and focus your efforts on your higher level goals/use-case?

If you’re open to describing what you’re hoping to achieve with your marine robot, and which parts you specifically want to focus on developing yourself (vs just using existing solutions for), we can give more relevant advice and suggestions.

Integrating sensor measurements always suffers from drift, and require externally specified/estimated initial conditions, so DVL velocities can only provide reasonable position estimates relative to some starting position, and for a limited period of time before the drift error becomes excessive for the application.

For a DVL to be useful for positioning you typically need a source of occasional ‘absolute’ corrections for the integrated position deltas from the DVL, like an acoustic USBL or SBL system (which can be used underwater, but requires the vehicle to remain in range of the acoustic transducers/beacons), or an aerial GPS (which is much cheaper, but requires resurfacing to get the corrections, assuming your vehicle is intended for use underwater).

A compass can often be considered as globally ‘absolute’, though it does have its own sources of error (from electromagnetic noise of nearby electronics, and magnetic noise of nearby metallic structures, along with larger scale magnetic declination differences around earth) which increase the need for absolute position corrections when using a DVL for positioning (because even if the heading estimate doesn’t drift further over time, any heading error still gets included in the integration and causes progressive drift in the position estimates).

10

Hey @EliotBR, So coming on to the project that i am working on is a ROV being used for underwater survey and explorations. Its just a hobby project that i am working on in my free time. But i am planning to make it slightly autonomous so that it can just simply navigate to the desired location, which in our case would a certain LAT and LONG.
So yeah, surfacing and using GPS input would be a good idea, but i want to be submerged most of the times. For that i want the navigation to be accurate, for which the desired motor pwms are required along with the correction in pitch, roll and yaw. Which further requires proper position and orientation estimate. Therefore the DVL and IMU fusion would work well, but as you have mentioned, DVL gives us relative position from the starting point, it needs to fuse up with an absolute position sensing unit.
And coming to autonomy, i do not want to depend on ArduSub for the self-navigation. I want to create my owm navigation stack with certain failsafes.
Tell me now, how can you help me with this, because i need a lot of guidance to make my project come into life.

11

That’s not necessarily true - if you have accurate sensing then a feedback control system can compensate for a lot, but there are still limitations to that approach so it is easier on the control system (albeit often more complex to implement) if you have accurate modelling of the vehicle/thruster dynamics built into it (allowing a combination of feedback and feed-forward control).

If you want to linearise the motor thrust outputs as much as possible then you’ll need to account for things like:

  • asymmetry between the forward and reverse direction of each thruster
  • the relative increase of thrust at higher PWM commands (e.g. the roughly quadratic shape of the thrust output curve)
  • the central dead-zone where there is no thrust output
  • the thrust reduction from voltage drops during operation, including instantaneous drops from high usage of one or more thrusters (or other high power electronics), and the longer term drops as your battery runs out of energy (assuming you’re powering with a battery)
  • the thrust reduction from water speed through each thruster, and tangentially the drag from the vehicle and tether at different orientations and water speeds
    • we don’t have good data for the dynamic thrust or vehicle drag, and water speed can also be difficult to measure accurately, so this would definitely be challenging

If you want accurate feed-forward control you’ll also need to model the response dynamics of the thrusters+ESCs to changing input and environment, as well as the buoyancy of the vehicle based on the temperature, salinity, and pressure of the water around the vehicle, and likely several additional factors that aren’t immediately springing to mind.

Note that none of those are required for being able to move the vehicle around, I’m just attempting to describe some of the relevant factors to the approach you’re saying you’re hoping to take.

I’m curious if you have particular reasoning for this. Are you very interested in developing your own autopilot, or do you just feel like ArduSub isn’t capable of what you want to achieve (in which case maybe modifying or augmenting ArduSub would be a more efficient use of your time and resources)?

In case it’s relevant, ArduSub already has various failsafes built in, and you can add extra ones using Lua scripts without needing to modify the firmware itself.

This forum is here to facilitate community collaboration and understanding, and to that end we can discuss ideas with you and try to provide guidance with problems you get stuck on, assuming you’re able to explain them in enough depth, and someone has the relevant knowledge, motivation, and time to respond.

From a Blue Robotics standpoint, we can’t put resources into custom engineering or development work unless it’s clearly to the benefit of the broader community, and aligned with our other priorities at the time, but that also doesn’t seem to be something you’re asking for anyway.