pymavlink
pymavlink copied to clipboard
DFReader: add a get_latlon method to DFMessage
@shancock884 this seems to fix a problem whereby we were no longer populating the multiplier field in the format object.
OTOH, I think it will also screw up the whole units-are-prefixed thing.
Perhaps I'm missing something?
I'm trying to remember what I learnt when getting my head round this before....!
There are 2 types of multiplier: ones attached directly to the message format (characters L, C, c, E, e on FMT message), and ones attached to the unit via MULT and FMTU messages. What has been done so far in tools such as DFReader and UAVlogviewer is that the format multiplier affects the value, and the unit multiplier does not, and instead adjusts the unit, e.g. for BAT.CurrTot: Ah*0.001 => mAh. So, DFFormat.msg_mults is intentionally not set based on the unit multiplier.
I think changing this to provide data in base-units would be a can of worms, as it would probably confuse and/or break anything that assumes things about the units of incoming data!
As for the general aim of your PR, providing lat/lon tuple should work as you want without the change to the unitmult bit, as the format multipler "L" will be applied to give the value in degrees. ... it seemed to work when I tried your code, but with lines 175-179 reverted...
mlog = mavutil.mavlink_connection(filename)
mlog.rewind()
while True:
m = mlog.recv_match(type='POS')
if m is None:
break
print(m.get_latlon())
As for the general aim of your PR, providing lat/lon tuple should work as you want without the change to the unitmult bit, as the format multipler "L" will be applied to give the value in degrees. ... it seemed to work when I tried your code, but with lines 175-179 reverted...
mlog = mavutil.mavlink_connection(filename) mlog.rewind() while True: m = mlog.recv_match(type='POS') if m is None: break print(m.get_latlon())
Ah, thanks! Looks like I was trying too hard!