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.
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)
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.
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.
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.
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.
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:
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.
@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.
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.
Unfortunately there are many many vehicle specific variables impacting accuracy of time and “fuel” to return home. Combined with the current unpredictable nature of the leash, I found it virtually impossible to make a universally acceptable solution.
At this point, I think AP_Scripting will be an easier way to accomplish this on vehicle specific basis. A basic script template can eventually be made, which users could extend to meet their specific vehicle and condition requirements.
Hello Mat, I just read this posting today and I think this is very important issue. I have been thinking this scenario:
I send the drone for a mission with many way points, and based on “conventional” calculation it will take about 60 minutes from take off to land. My battery capacity is enough for that mission. However during flying the drone may have to struggle against strong wind. This is dangerous situation as it needs more energy to fight against the wind, that may end with a crash because of not enough energy to fly home.
To avoid this situation I think we need a warning system that the drone may not be able to accomplish the mission due to the strong wind. So it may re route the mission waypoint automatically (smart routing system) or RTL.
Any idea to solve this problem will be very useful.
Regards,
Tony
