The hard part is going to be finding some grandkids!
1 Like
hey folks,
a new kid is in the blocks: the UC4H ESC node
trying to also control the motors via UAVCAN was kind of an obvious thing, albeit a bit of an overkill. However, with UAVCAN one can get in principle also telemetry data from the ESC & motor, and this would be a real additional value. Gladly, the latest KISS or BLHeli ESCs do in fact offer telemetry, so that then paired up with an UC4H ESC node this should be something cool. I further realized that quite some times ago I bought a KISS 24A ESC, which I never used, but now gladly found in my box. So, as a late afternoon exercise, I just started.
Unfortunately, I could not yet convince the ESC to provide the telemetry data. Not sure why, maybe I have to flash a newer firmware, will have to see. However, everything else seems to work: The node digests the esc.RawCommand message at the selected esc index, and broadcasts the esc.Status command. And with a UC4H SLCAN adapter and Pavel’s great UAVCAN GuiTool one can test all this quite conveniently. Ah, the motor also turns of course LOL.
As is, it is not yet useful. One probably would want smaller pcbs. Also, it is probably wasted time to continue working with the KISS 24A, a DSHOT capable ESC with telemetry, ideally BLHeli_32 due to the lower price, should make more sense. But I don’t have any. And the selections are quite confusing, so I need to do a bit research, I guess. Recommendations?
Anyway, a start has been made, and this is on the way
cheers, Olli
2 Likes
Awesome!
Are you aiming for just a single esc per node, or more?
Re esc’s, I’ve been using Airbot recently for a side project (non ArduPilot), and haven’t had any problems (https://store.myairbot.com/).
This is a cool way to get dshot support too - which is pretty neat.
@tridge
I was thinking about it. Technically it’s well possible to support “many” escs with one unit. But I couldn’t really see a reasonable application. You do?
So, I’m currently thinking about a pcb into which the ESC can be soldered in. A bit like KISS’ carrier PDB, but just for one ESC.
I do not think that “DSHOT support” would be a valid claim, it kind of defeats the purpose of DShot. There is some additional latency+jitter of something like 250us due to the CANbus, and in addition the ESC update rate is relatively low. I don’t think that this would impress any DShot user. Any of the recent protocols, from OS125 onwards, is better than UAVCAN.
I think 2 in 1 would be nice for coax setups. I see the use case as mainly larger copters, where esc’s are often outboard with the motors, so 2 is probably practical. Other than that, it is more a size/weight consideration - for instance, 4-in-1 esc’s have become popular, and having to use 4 adapters would be impractical if someone wanted to convert to uavcan. But I’m not sure that UAVCAN would really fit that use case, as the 4-in-1 esc’s are usually in smaller quads.
The DShot support comment was more in the context of feedback than performance. Getting motor feedback would make it easier to implement failure identification and management, which is something I’d like to see make it’s way into ArduPilot.
I had seen these dual motor cases too … you’re no concerned that folks will be worried about breaking redundancy? I mean, one node failing will bring down two motors … as said, technically it would be a piece of cake to do it.
Yeah, 4-in-1’s, actually, the gpsmag node pcb, which I’m using in the above, has 4 pins and could control 4 motors … but those are popular not only in small but also in race quads, none of which will ever be dominated by CANbus. IMHO.
Feedback is NOT related to DShot! E.g., the KISS 24A I’m using offers telemetry for any protocol. Not sure BLHeli_32 does, but it too could.
Getting motor feedback would make it easier to implement failure identification and management, which is something I’d like to see make it’s way into ArduPilot.
this would be fantastic, agreed, but honestly, maybe one should first aim at getting the basics working, see e.g. Mike’s experience: MP mag calibrate does not work with EKF2 enabled in 3.6dev. I guess Mike would rather prefer that someone takes up that challenge :). There is a list of other issues.
@EShamaev
as regards the GenericBatteryInfo message you were saying in the ardupilot gitter channel that
The Olli’s reasons were documented, but I find them very unconvincing.
His message is simply a stripped down version of DSDL’s with lot of simplifications.
You also were making this point that it is just a stripped down version of existing dsdl messages elsewhere. The only way I can see this could be true is that you think that available dsdl messages carry a data field which could have been used.
So, could you pl tell me which data field(s) in which dsdl message(s) you think I could have used for the purpose?
I mean that if there exists a well though message with more parameters, I see no point in introducing a custom reduced one.
I also made points “elsewhere” what can be used.
So here it is:
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.
The parameters full_charge_capacity_wh and remaining_capacity_wh do give much better understanding of remaining flight time.
Also in larger UAVs the battery can be charged in flight from generator (my case) and thus other parameters of DSDL make sense.
What can be added to this message is “nominal voltage” though.
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. There is already get_watt_max in AP_BattMonitor and 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.
Another issue that power brick is NOT a smart battery at all. It is also a legacy that it is considered one but that’s a huge mistake and your approach with broadcasting CircuitStatus message seems much more reasonable to me and that’s one of the reasons I added that message to AP_BattMonitor. However due to high tension I removed it now from that PR for now.
1 Like
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.
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
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.
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.
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.
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
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.
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.
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.
which at minimum you then want to rename to remaining_energy_wh
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.
rename to remaining_energy_wh
That is actually a solid proposition. I should do that once the DSDL versioning support is in place.