I get a voltage reading that makes sense, but even a fully charged battery only shows at 23%, also a flat battery shows at 23% when I first connect xbee.

It doesn't make a difference if I plug in a 3s 3000mah battery or a 4s 6000mah battery.  Same results.


Assistance would be appriciated.  I saw someone else post the same problem under the 2.6 Released topic but has had no replies.


Thanks in advance.


Views: 1015

Reply to This

Replies to This Discussion

have you set the voltages in the planner? sometimes it takes a few goes hitting enter and clicking in other boxes to get the voltages saved.

Hi Chris,

The parameters inserted into APM seem to be ok.  I did a few screenshots to assist with the troubleshooting of my problem.



Any further input would be appricated.




Because the numbers in terminal make sense with regards to the battery, I am starting to think that the fault lies with the way that APM Planner is calculating the percentage.

Ok ignore the last topic.  When I manually uploaded 2.5.5 through Arduino, I now get the correct battery voltage and the mission planner starts at 100% capacity.


Going to try an manually upload 2.6 and see what happens...

Uploading 2.6 via Arduino brings back the same fault.

OK, change the sensor code written in 2.6 for the battery back to the 2.5.5 does not change anything.  My assumption is back to APM Planner as the only difference I can actually find is that 2.5.5 uses mavlink 0.9 with apm planner 1.1.92 and 2.6 uses mavlink 1.0 with apm planner 1.1.93.


Anybody ready to comment at this point?

when you change to 2.6 are you changing to the MP for mavlink 1.0? there is a different exe file in the folder for mav 1.0

I agree, I came past it after my last post.  I edited the GCS_mavlink file and changed the * 1000.0 to * 100.0 which then starts the battery at 10% which is atleast accurate if you muliply it by 10.  Apparently an overload and scaling issue depending on which mavlink you are using.

The 23% even "makes sense".

1000 in hex is 3E8.

Keep only the bottom eight bits to simulate it coming over as a uint8 and you have E8

E8 in decimal is 232

Divide 232 by 10 the way it should be if it was scaled at 1000=10% and you get 23.2 

It needs the change in the arducopter gcs_mavlink.exe from 1000 to 100.

Arduplane gcs_mavlink.exe looks like it is O.K. (from looking at the code only, I haven' tried it).

Probably needs  _battery_remaining = value / 1000; to become  _battery_remaining = value / 1000; in CurrentState.cs in the APMPlanner code. Will try this later today.

Confirmed,  I changed 

Arducopter - gcs_mavlink.pde


      uint16_t battery_remaining = 1000.0 * (float)(g.pack_capacity - current_total1)/(float)g.pack_capacity; //Mavlink scaling 100% = 1000


      uint16_t battery_remaining = 100.0 * (float)(g.pack_capacity - current_total1)/(float)g.pack_capacity; //Mavlink scaling 100% = 100

ArdupilotmegaPlanner - CurrentState.cs


       _battery_remaining = value / 1000;



       _battery_remaining = value / 100


Works fine now.


Will update the issue list



Silly mistake - it is gcs_mavlink.pde, not gcs_mavlink.exe in the post a couple up the thread.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service