Implemented power supply status estimation

[ahrastnik]

This adds the ability to estimate the charging status, which is necessary information for autonomous charging.

Implementation details along with simulation, research data / measurements and limitations can be found here.

[mjstn]

I suppose you could use this but any of our batteries alone at 12V is 'low'. I do see later you use 2.175 sort of number that would be 13V. A nominal 12V gel cell is near 12.6V actually.
I leave this up to you to think about and you can leave this if you like except the 2.175 factor should be a factor to come out to more like 12.6 but again batteries brand new fresh totally charted can read 13v so up to you.

[ahrastnik]

If you are referring to SLA_AGM_CELLS, this number only indicates the number of cells in the used battery bank - and is not used directly anywhere in the code, but rather only to determine voltages levels with factors as seen below.

Perhaps my choice in variable names wasn't great, but these three constants below are used only to determine the charging state and I found that these factors work best for that purpose alone.

[mjstn]

I would say this is ok as long as you convert the printf to be a ROS_INFO call because if you don't we don't see this message in the log. Now maybe that printf was debug code, up to you. If it is debug code then use of ROS_DEBUG would be used if you want that debug code to be seen in the future. keep in mind that if you hammer this routine all the time ROS_INFO is bad and so is printf because it will 'spam like crazy'. In the past I have used other more tricky things like have some static counter and only do the ROS_INFO every 5 seconds worth of time or something like that.

[ahrastnik]

I don't think that is necessary. This code gets executed at about 7 Hz and it will spam and fill the logs if viewed at a debug level. Although, perhaps it would be wise to output only when the charging state is changed - I don't have the time to implement this, unfortunately, but it's easy enough to do for whoever picks up the code next. V V sre., 11. okt. 2023 ob 10:15 je oseba Mark Johnston < ***@***.***> napisala:

…

I would say this is ok as long as you convert the printf to be a ROS_INFO call because if you don't we don't see this message in the log. Now maybe that printf was debug code, up to you. If it is debug code then use of ROS_DEBUG would be used if you want that debug code to be seen in the future. keep in mind that if you hammer this routine all the time ROS_INFO is bad and so is printf because it will 'spam like crazy'. In the past I have used other more tricky things like have some static counter and only do the ROS_INFO every 5 seconds worth of time or something like that. — Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLQXPCPEZ5LNJRVNBPKF2DX6ZITJANCNFSM6AAAAAA5YZ6AXI> . You are receiving this because you authored the thread.Message ID: ***@***.***>