Add status topic #406
Add status topic #406
Conversation
|
This is related to #149. In addition, it allows to look at the connection quality for both unicast and broadcast, for firmware versions that have bitcraze/crazyflie-firmware#1341 applied. |
|
Hi! So we need to get the Crazyflie PR merged first for this though (hopefully soon). Usually with the cflib link, I try to wait until the firmware release is out before merging new stuff for stability. Is that perhaps we can consider for the cpp link as well? I do see that you have some backwards compatibility functionality in there already so that might be enough as well. |
|
I tested with old and "new" firmware, so I think it's safe to be merged. On older firmware versions, there will be just a warning printed and the numbers remain 0. |
|
Gotcha. bitcraze/crazyflie-firmware#1341 has been merged and I will now review this PR |
crazyflie/src/crazyflie_server.cpp
Outdated
| // general status | ||
| uint16_t supervisorInfo; // supervisor.info | ||
| // battery related | ||
| // TODO: would it be better to use pm.batteryLevel? |
There was a problem hiding this comment.
For the sack of 'easier understandability' I would say yes, but it might send the wrong message. Since there is no linear relationship between how fast discharging on the crazyflie or bigger bolt/BQ devices this might be tricky.... on the other hand, perhaps that won't be that much of a problem if the user is aware of this.
There was a problem hiding this comment.
What would the proper bolt support look like? We would either have "batteryLevel" or vbat and extvbat? Was there a reason why "pm.vbat" doesn't "point to" the external value on a bolt-based build?
There was a problem hiding this comment.
Using BQ-deck one can actually have two batteries at the same time. On the Bolt this is also in some sense true but maybe not practical. It makes it a bit complicated and perhaps having one variable representing the "flying" battery level would be preferred.
No description provided.