UAVCAN for Hobbiests

ArduCopter
, ,
101

I’m sorry, you are NOT answering my question, and you are not offering an viable alternative!

mAh consumed is meaningless to me. My motors and actuators consume power and not only current. In my setup torque produced by motors is directly related to power.

This is most strange. I would like to hear the opinion of other users. mAh is THE natural quantity in relation to the battery’s charge.

The parameters full_charge_capacity_wh and remaining_capacity_wh do give much better understanding of remaining flight time.

Agreed. But a power brick is inable to calculate these quantities. You seem to ignore this fact.

Also in larger UAVs the battery can be charged in flight from generator (my case) and thus other parameters of DSDL make sense.

Agreed. Please tell me how many users have that setup in relation to the number of users which use just batteries.

There is already … capacity_remaining_pct that can be used with the parameters in existing DSDL messages.

I would rather see percentage on GCS than the arbitrary mAh when I do not know battery voltage and total capacity.

A power brick is inable to calculate these quantities. You seem to ignore this fact.

Another issue that power brick is NOT a smart battery at all.

Agreed, it is not. So are you implying that ArduPilot users must not use power bricks but only smart batteries (if they want to use UAVCAN)?

CircuitStatus message seems much more reasonable to me

CircuitStatus does not carry information on the charge of the battery. You also are not offering any viable alternative. Are you saying that accurate estimates of the consumed charge is irrelevant information?

In summary: Please tell us, the users which just use batteries, why we don’t deserve getting an accurate fuel counter?

At least I think any battery user can now precisely judge how convincing your arguments are.

Also, I still would like to hear your answer to the statement

His message is simply a stripped down version of DSDL’s

For this to be true there MUST be at least one existing DSDL which carry that data. So, please tell us which. I’ll be happy to use it.

102

Battery charge is power for the consumer. Not current. And you agreed to this later in your message.

Able if it knows voltage. Which I persume it does as it measures it and it can integrate not only current but also a product of voltage and current. The total power of battery can be set in the brick so it calculates everything correctly. More to that, having the starting voltage when system is turned on, can give you good approximation on how much power is available from battery initialy.

Yes, I explicitly say so. Unless I know exactly what was the total charge current availabe when the battery was placed in the UAV and started. But more of that what is really relevant - is the power left.

It is current message 1091. It provides data that is really valuable and make sense.

1 Like
103

Battery charge is power for the consumer. Not current.

Is this a serious comment?

charge != power != current != charge

Able if it knows voltage.

Seriously? You seem to fail to see that the power brick does NOT know about the battery capacity. Also you seem to fail to see that charge is current x time, and has no relation to voltage.

It seems you are claiming that by just knowing the voltage one could arrive at a reasonable estimate of the state of charge.

But more of that what is really relevant - is the power left.

Seriously? There is no thing such as “power left”.

Taking all three together, it is becoming increasingly clear that you just don’t understand the physical quantities.

power = energy / time = voltage x current
charge = current x time
battery capacity = maximal available charge

now guess what is relevant to estimate the battery charge.

It is current message 1091. It provides data that is really valuable and make sense.

Wrong. It does not have any field which carries the consumed charge, or any quantity related to it which could be determined by the power brick.

I think we can safely conclude this discussion. You obviously have no basis for your claim.

Thx for helping clarifying this.

104

OK, if you want to be picky about words, no problem. Thank you for trying to teach me elementary physic laws, I will be extremely specific with words.

As a user, I am concerned with how much energy I have left in battery. You agreed to this.

And yes, knowing the total battery capacity, starting voltage and discharge curve for particular chemistry of battery, I can calculate the approximation of how much energy I have left in battery.
The only thing that is not known to brick is total battery capacity and chemistry. It can be setted up in brick by user.

I do not understand why do you want to make a step towards a great new device but willing only to take a half of that step?
It is not hard to make two parameters configurable as you already have CAN connection to the brick and there is a mechanism for that in UAVCAN. Then put few most used curves in firmware, compensation for curve derating with respect to current and viola - you will have a superb product that currently will not have any alternative.

105

I’m purposefully trying to stay away from this conversation because I believe it is mostly a waste of time, but this last message from Olli warrants an intervention.

Olli, you seem to lack understanding of the basic physics here. This is OK, we’re humans and we’re bound to make mistakes every now and then.

Eugene may have used suboptimal phrasing in his earlier messages, but the idea he’s trying to communicate makes perfect sense: the integral of current over time is mostly meaningless in our context. What the autopilot and other equipment should care about is the amount of energy that is consumed from the battery and the amount of energy that is left. Energy is an integral of power over time, hence why we use watthours rather than amperehours - the latter quatity is meaningless.

We’re not going to accept messages into the standard set that duplicate the functionality of standard messages. If you want your work to be compatible with the standard, you should use standard messages as much as possible.

You seem to fail to see that the power brick does NOT know about the battery capacity.

Then make it know it. Otherwise, it would be mostly useless. And don’t shove this task onto the autopilot, because:

It was historicaly, that Ardupilot “overmanaged” the devices connected to it as it was the only one “smart” component on board. It is a legacy we have, but no one prohibits us from moving forward.

Olli, I suggest you to carefully re-evaluate the specification and make sure that you perfectly understand our goals here. Building another clone of I2C is not what we’re trying to accomplish.

106

Olli, you seem to lack understanding of the basic physics here.

HAHAHAHA

you guys really can’t be take serious any longer.

Q.E.D

EDIT: It appears that the problem rather is that I do understand physics, while you are engineers, and have invented your own wording misusing physical termina. It’s clear then that communication is difficult. But the physical termina are unambiguous and not negotiable.

1 Like
107

It appears that the problem rather is that I do understand physics, while you are engineers, and have invented your own wording misusing physical termina. It’s clear then that communication is difficult. But the physical termina are unambiguous and not negotiable.

The root of the problem is that you’re proposing to substitute energy with charge for no apparent reason. Although it’s a good thing that you decided to conclude this discussion because it clearly can serve no purpose anymore.

108

what in your opinion does the C in SOC stand for?
aren’t there fields in state_of_charge_pct or state_of_charge_pct_stdev?
good to learn that you have introduced those for no apparent reason

BTW: It seems that there is a fundamental misunderstanding as to my intentions, which may add to the confusion.

  • Fundamentally I’d be totally happy with the vendor specific messages. And except of the GenericBatteryInfo, which I had suggested several months ago I didn’t make any attempt to get any message into the standard. And for that message Pavel made his no clear, also many months ago. And concluded many months ago that the only reasonable path for me is to go with the vendor specifics messages. I mean, we also have that gimbal thing, for which can’t be a resolution along the current lines. So, only vendor specifc for me. As a matter of fact, all my codes here are now such that this message is in my vendor specific section. So, if you argue because you think that I would be “fighting” for getting this message a standard, then I can clarify that: No. Zero intentions in this direction.
  • this will btw also happen with the uc4h esc, users will like some features which will become possible which, as it stands, never ever would make it in any UAVCAN standard. Yet I presume they will be liked. So, vendor specific.
  • I have absolutely no interest to make this a product.
  • I understand your argumentation with adding additional parameters, chemistry curves and so on and forth. But, and I made this argument before, I would find this totally impractical, because whenever one uses a different battery, e.g. to keep on flying, and be it just 3300mAh instead of 5200mAh, one has to reconfigure the node. That’s the advantage of real data over highly processed data. You know what you get.
109

SOC is a commonly used parameter that is provided only for the sake of completeness. SOC could be easily removed from the definition without any harm to the application. The useful parameter is the amount of available energy, which is reported in the field remaining_capacity_wh.

110

which at minimum you then want to rename to remaining_energy_wh

111

Batteries don’t actually have a set amount of stored energy, so a power module that indicates energy used vs energy remaining as a percentage is going to be inherently unreliable.

The amount of energy you’re able to retrieve depends on current draw, with higher current draw resulting in decreased effective capacity. This is mostly due to internal resistance dissipating energy at a rate that increases exponentially with current draw.

The convention used by available power modules is not ideal, but it’s not this way arbitrarily, or because developers have ignored the issue. Unless you fully characterise the battery being used - which necessarily involves tracking it’s charge and discharge cycles - any simplified form of indication would end up being wrong some of the time, with potentially dire consequences.

112

rename to remaining_energy_wh

That is actually a solid proposition. I should do that once the DSDL versioning support is in place.

113

From Mavlink’s standard BATTERY_STATUS:
<field type="int32_t" name="energy_consumed" units="hJ">Consumed energy, in HectoJoules (intergrated U*I*dt) (1 = 100 Joule), -1: autopilot does not provide energy consumption estimate</field> <field type="int8_t" name="battery_remaining" units="%">Remaining battery energy: (0%: 0, 100%: 100), -1: autopilot does not estimate the remaining battery</field>
Good to know we are not the only ones who care about energy.

Well, from chemistry and physics point of view, batteries have exactly the amount of energy stored. But the amount of usable energy depends on number of factors.

Then I am out of this discussion as it lost any valuable meaning and also I do not see any point in adapting these vendor specific messages to Ardupilot as there will be no product in the end that will generate or use these messages.

114

@GuyMcCaldin It is understood that tracking the amount of available/used energy is hard. However, this is the only metric that can be directly made use of by the application. Knowing the amount of electrical charge is insufficient to predict the operating limits of a vehicle; you’d have to convert that into energy first, one way or another. Hence why we report energy and not charge - there is no other component in the system more capable of performing the conversion than the battery management module.

115

I do not see any point in adapting these vendor specific messages to Ardupilot as there will be no product in the end that will generate or use these messages.

Yes, I agree with that, if the current ultra-strict approach to only accept the most abstract and processed data as to be of only meaning, than yes, then there is no point in vendor specific messages. However, whether this is the best use of CANbus is highly questionable. And I’m very convinced that UAVCAN will find narrow use. Maybe one can earn more money in these narrow sections, that’s probably true.

Anyway, personally I would feel having been cheated. The standard says it’s allowed. And, I said this before, the present attitude towards vendor specific is IMHO most inappropriate.

I would find it most important to settle this as quickly as possible. That is, I want to know if I better should stop UC4H, and the earlier I would know that the better it would be.

It is understood that tracking the amount of available/used energy is hard.

This goes into exactly the same direction.

Batteries don’t actually have a set amount of stored energy, so a power module that indicates energy used vs energy remaining as a percentage is going to be inherently unreliable.
The amount of energy you’re able to retrieve depends on current draw, with higher current draw resulting in decreased effective capacity. This is mostly due to internal resistance dissipating energy at a rate that increases exponentially with current draw.
The convention used by available power modules is not ideal, but it’s not this way arbitrarily, or because developers have ignored the issue. Unless you fully characterise the battery being used - which necessarily involves tracking it’s charge and discharge cycles - any simplified form of indication would end up being wrong some of the time, with potentially dire consequences.

YES. :+1:

the charge has been proven in practice over and over again to be a highly valuable first-hand info to estimate the remaining flight time

maybe it’s time starting talking about UCAN, the you-can message set for the UAVCAN protocol layer. ;:smiley:

116

I’m sure you were able to understand the intent of my post, and we don’t need to delve into semantics to communicate :slight_smile:

Your response suggests that you’re still not quite understanding why indicating mAh consumed is more useful than calculating mWh consumed. Our industry (and most others that work with batteries) uses mAh because it consistently and somewhat quantitatively indicates remaining battery capacity, regardless of variable power draw, and without needing to characterise or log the battery.

Obviously, remaining battery capacity in mAh is disconnected from remaining endurance. As you stated in a previous reply, drones are essentially constant power systems (if you ignore takeoff and landing), as opposed to constant current systems. Given this, it’s tempting to think we could just throw a few curve models together for different battery chemistries, gather some data points to calibrate for a specific battery, and have a much better system where we accurately indicate remaining flight time as a single percentage number.

I’m working towards a solution like this, but there are a lot of complexities that make it difficult. First and foremost is that knowing the state of a battery is critical for safe operations. While mAh consumed and combined voltage are cumbersome to work with, they provide actionable information about what’s going on with a battery that isn’t abstracted.

The second issue is that the sensors in current commercially available power modules are not very precise. You need to be able to count coulombs to accurately gauge remaining charge/energy/endurance, and through a combination of calibration errors, resolution at low currents, and low sample rates, they don’t currently do this well (though it sounds like Olli’s sensor has made a lot of progress). The error is maybe only 5%, but that small error leads into the next point.

You need to know the state of charge in order to know where the battery is along the discharge curve. This is absolutely critical, and even a small measurement error can result in a significant error in charge/energy/endurance estimation. To accurately know the state of charge, ideally you need to log every charge and discharge cycle, which has the additional bonus of allowing you to monitor battery health.

Again, there might be a temptation to think this isn’t very critical. If you always use freshly charged batteries, can’t you just assume they’re full at power up? Not really. You might have mistakenly plugged in a half discharged battery, or maybe you needed to adjust somethings before takeoff that involved a bit of discharge and then a power cycle. The state of charge information is lost, and you’re back to using imperfect sensors to guess what’s going on. You feed slightly garbage information to your curve models, and they give you garbage back, but because it’s been abstracted to a single percent figure, you have no way to tell until you’re hit with a low voltage warning.

The best solution to this problem is something like a TI Fuel Gauge. 24-bit sensors that are factory calibrated, with high sample rates counting and logging every coulomb that goes in or out of the battery. Smart batteries are definitely the future, but they’re a lot less flexible, and they add significant cost to each battery.

Like I said, this is something I’m actively working on, but there’s still a lot of work to go.

1 Like
117

YES! :+1: :+1: :+1:

Good to see someone using common sense to arrive at proper conclusions. Fantastic post.

Funnily, Eugene himself pointed out that a power brick is not a smart battery, yet wants it to be one. It just takes so much more to make a (reliable) smart battery.

though it sounds like Olli’s sensor has made a lot of progress

Well, I would not say a lot of progress, when one compares with what one could do when one would pull the strings, some of which you mentioned. It is a low-level device. However, when compared to what for many of us had been the alternative so far, I think it indeed represents some significant progress (and it does it better exactly because of the reasons which you mention, one of them being sample rate).

Maybe, to avoid misunderstandings, I should add: I’m not against Pavel’s/Eugen’s approach to go for the energy. In the contrary, it is a heroic approach and worthwhile every effort. However, what I don’t like is that everything else which might be useful is plainly dismissed as “totally meaningless”. I have difficulties to understand why a standard cannot accommodate various levels of sophistication. This would not make it I2C.

118

As you are working on such system gives me a hope that we will see that soon.

Ardupilot already integrates current from other battery sensors. That can be done with any of existing DSDL messages (either battery or circuit status). I see absolutely no point in making one more message (and code to support it in AP) if it does not give any new possibilities.

What could be done to prove the point of necessity for such message is a comparison of results calculated by AP from standart messages say at 10 Hz and calculation on side of power brick during the real flight. Of course power brick will be more accurate as it has 100 times more sampling rate, but what will be the difference and will it be big enough to justify additional code in AP?

119

At the risk of offending people I respect I must comment from the “peanut gallery” “the cheap seats”. I did not know anything about RC a couple of years ago. I am just a common user. I understand that the devs job is to have vision for the future. To try and make Ardupilot as flexible and able to support the future. But when you are debating the future you can’t forget the present.

Most users are still using the original shunt 3DR power module which is almost useless. For most of us a Hall sensor is a huge leap in technology. Nobody has smart batteries and nobody will anytime soon.

Many many users struggle everyday to figure out how to attach the basic required devices to a multirotor. They don’t know the difference between I2C and serial. I answer questions about such every single day.

CANbus would be a huge benefit to the community. But at the rate you guys are going you will never agree to anything.

All I am asking is to have a little bit of pragmatic willingness to solve a problem for the greater good rather than the most elegant solution.

ESHamaev has Ardupilot gotten to the point that do-it-yourself is no longer part of the vision? OlliW’s UC4H brings CANbus to the unwashed masses. Even if he never produces a commercial product.

Just please keep in mind that users building with CANbus now may be better than the best CANbus solution a year from now. The industry moves fast and will move faster every month.

Cheers

120

I don’t think having ‘energy consumed’ as a message format makes much sense for these systems for battery management.

Energy would be logical if the effective capacity of batteries were fixed, but as we’ve established, in practice it’s not. The energy provided over a discharge cycle might vary by 10-20% between flights in regular usage. This means that using messages in terms of energy would necessitate that either the values be distorted to account for the ‘real’ state of charge, or that additional messages along the lines of “effective_capacity_remaining” be introduced to account for the information deficit. Neither option is desirable from my perspective.

mAh consumed is more meaningful/informative, because it represents a physical measurement that will remain relatively constant from flight to flight. It’s not about it being ‘useful’ for the flight controller, it’s useful via telemetry for the end user. For decentralised systems using ‘smart’ power modules, the established “battery_remaining” as a percentage is fine.