Servers by jDrones

Thoughts on distance/altitude based intelligent battery failsafe

(Chris Olson) #61

They just use a hall effect sensor in it.

I don’t know that it would be all that practical for telemetry to the ground station because it’s not going to work on multi-rotors with numerous ESC’s. For helicopter or plane it would. But with more and more radios supporting telemetry these days, it makes more sense to feed the data to the RC radio, and not the ArduPilot ground station (to my way of thinking).

It is really the only logical method to use for high-power, high-voltage helicopters for power system telemetry data. The AttoPilot modules can only solder 12ga wire and I got 10ga coming out of the packs on my 12S heli’s.

(WickedShell) #62

The castle engineers we spoke with basically made the comment that it was calibrated against being reasonable near the upper end of the range, and that if you are pulling 3A or less (which is what we do) that it just won’t be close to accurate anymore, particularly with the sampling rate that is used.

The autopilot definetly should be sent this information. With the information it becomes possible to improve a large number of failsafe conditions/sensor error detecting. (IE on plane knowing the power output on the motor, would let us correlate the airspeed reading with the throttle and evaluate if the airspeed sensor is blowing out). On a copter it would give you definitive reporting on which ESC is stopped/not spinning correctly, which allows you to handle mechanical failures with more confidence (IE loss of prop/bad power connection is now detectable, outside of just pushing the outputs to max)

(Sergey) #63

By the way, @Pedals2Paddles did you had a chance to make any progress with the subj task?
What is the status at the moment?

(Matt) #64

The Open Solo project has diverted about 120% of my attention. I plan to come back to this once I get that done and released.

(Chris Olson) #65

The ESC I took that log data from is a ICE-2 HV120. Using my RC power meter on the charger after a flight to measure actual power returned to the battery, the Castle’s logging seems to be about +/- 5% at the typical hover to cruise power for that helicopter (700 - 565 watts). Which is about on par with the various power modules in common use. The problem with the power modules is that more and more aircraft are going to 8, 10 and 12S power, and stepping down 12S to 5V is nuts. I haven’t been able to get the 10S rated ones to hold up on 6S in helicopters where you might pull 75-80 amps continuous for a few minutes with a heavy payload. They just burn out.

So Castle Link Live does present an alternative to the rather fragile power modules. I just assumed it would not be possible with multi’s due to the number of ESC’s. It’s fairly easy to do on RC telemetry systems - simple hookup to my receiver’s SPI port with a Castle Serial Link and program the radio for what telemetry items I want to display on the screen, and set alarms for the ones that should have a nominal operating value in flight. The Castle Serial Link also supports I2C, so I suppose it’s possible to get the data into Pixhawk as well.

(Christian Labeck) #66


Have you tried one of the Mauch Electronics HV power modules?

They are rated to measure 200A at 12S at least… and by default it comes with AWG10 wires, but you order an upgraded version with 8AWG for 5$ extra only.

I have one in the basement waiting for assembly… to be used in a large octo still so can’t comment yet on reliability.


(Chris Olson) #67

No, I have never tried one of those. Using the ESC’s built-in features provides a lot of extra information such as rpm, temperature monitoring for high-load conditions, and watts for power levels. With the ESC telemetry I have all the data right on my radio screen with Castle Link Live even if I’m flying without the ground station. I would find it kind of hard to go back to using inline power modules with just voltage and current readings, and only being able to use it in flight with a ground station at this point.

(James Pattison) #68

great! Look forward to this. Will you have a tie in to SmartRTL, rather than just distance to home?

(Matt) #69

SmartRTL wasn’t a thing when I started pondering this. But now it is. So when I get back to it, I will have to investigate that. If there is a status I can read that reports the travel distance to home, I will certainly use that. However at the moment, SmartRTL is not part of the failsafe options, so not critical yet.

(Matt) #70

Here’s my first stab at this. This is not nearly as complex as some of the discussion here. I kept it pretty straight forward for now.

(Sergey) #71

Using a Matt’s PR as a reference I did a custom FW that calculates and log power (Watts) and used energy (Watts-hour). My goal was to see what will be the difference between mAh-based and wattage-based estimation approaches.
Today I did some real flights and collected logs. Here are my results:

As voltage decreases current is slightly increases. The power is excpectingly stays the same all the time (though it is noissy because it was windy).

CurrTot is the mAh used and EnrgTot is the Wh used. No much difference though.

Above is the log when hovering. Pwr is the copter power in watts, AvTime is the available (estimated remaining) time. It is calculated as [battery capacity in Wh] / [power in Watts]. This calculation provided pretty linear and accurate remaining fly time.

In same way we can calculate available (remaining) distance copter can fly.

(James Pattison) #72

Awesome. Looking forward to seeing this find it’s way into the main codebase.

(Matt) #73

@sergbokh what did you do to make the running total watts. My attempt at this is resulting in outrageously high numbers.

(Sergey) #74

@Pedals2Paddles I did my power calculation within the AP_BattMonitor_Analog::read() function, so I don’t know what are the units in your version. But anyway there is a simple Volts * Amps formula so in your case voltage unit may be in millivolts, or current in milliamps. You should divide your result for example on 1000.

(Matt) #75

I’m doing (watts / 3600) * (elapsed microseconods / 1,000,000) to come to the watts used in the last loop. But I think I had some poorly placed datatype conversions making it go haywire.