search

mavlink / qgroundcontrol

Cross-platform ground control station for drones (Android, iOS, Mac OS, Linux, Windows)
http://qgroundcontrol.io
3.19k stars 3.53k forks source link

Increase altitude resolution to 0.01 m #7352

Closed jaxxzer closed 5 years ago

jaxxzer commented 5 years ago

The altitude readout reads only to the nearest 10 centimeters, however many messages provide centimeter resolution, and there are vehicles equipped with sensors that can provide this resolution.

Antiheavy commented 5 years ago

I suspect the topic of displaying significant figures and sane number of decimals would have a large number of different opinions. How much precision is useful, how much precision is actually correct, how much precision is just visual pollution? I certainly have my opinions, but they likely aren't the same as others'. Also, don't forget us idiots who still measure distances according to some old king's shoe size.... i.e. it probably would not be appropriate to display 0.01 ft. :-)

DonLakeFlyer commented 5 years ago

This is a tough one. In reality what is wants is a configurable resolution for this sort of thing. But that is going to be a non-trivial change since the precision is currently specified on a field by field basis with altitude just using a common practice of 1 decimal precision.

I think for most people going beyond one digit of precision will end up being annoying from a ui noise perspective. Hence I don't think I can change generically across the board. As well as the rarity of the vehicle being able to be that precise.

jaxxzer commented 5 years ago

I'm in agreement we shouldn't do it if it doesn't generally suit users. The pressure data underwater is rock solid compared to the air pressure sensors. Our standard sensor has 2mm resolution, and we can get centimeter level precision with no problem. I'm not sure of the real state of things with gps, but I've seen things like centimeter level accuracy advertised, so I generalized the issue.

I think going off whatever precision the vehicle reports (mavlink spec) would be a good rule of thumb, because that should qualify as interesting data rather than noise/pollution. There are also other things we could do no our end to make it more presentable like a low pass filter to smooth the data. Just thinking out loud here, I don't think this needs to become a burden.

The adjustment is probably small, so I can make a branch to try it, and attempt to collect some feedback among different vehicles.

DonLakeFlyer commented 5 years ago

You have control over COMMAND_LONG parameters using MavCmdInfoCommon.json overrides which allows you to set them to whatever you want.

But that won't cover everything. There are other altitudes in the ui which come from both settings and mavlink values. Custom builds are set up to allow overrides on most of these things. But not currently for Vehicle facts. That would make sense but not currently implemented.

But this is another case where the QGC custom build architecture is set up to handle these sorts of things. ArduSub is currently a bit of a strange case since it uses generic ArduPilot support and some qgc plugin stuff but in reality it is a specific locked down commercial vehicle which is what custom build architecture is set up for.

jaxxzer commented 5 years ago

ArduSub is currently a bit of a strange case since it uses generic ArduPilot support and some qgc plugin stuff but in reality it is a specific locked down commercial vehicle which is what custom build architecture is set up for.

ArduSub is absolutely generalized and applicable to other submersible vehicles beside the Blue ROV. This is just the same as the rest of the ArduPilot vehicles and ecosystem. There is nothing locked down about it.

Generally (not in regard to this particular issue alone), I want to concentrate on improving the firmware and autopilot plugin side of things (and ardupilot support generally) rather than covering all my bases with a custom build.

DonLakeFlyer commented 5 years ago

Ah, sorry. I thought it had things like motor testing and so forth which were specific to the BlueRover setup.

That said, it still fits the custom build model. For example the fact that your specific vehicle has sensors which have that high of a resolution for height values is specific to a vehicle as opposed to a class of vehicles. So QGC can't really make assumptions about that sort of thing since it is coded to generic common case.

I get what you are saying though. Just not sure how to handle it without things getting more complicated in generic QGC. Hence we tend to bail out to the custom build case for things like this.

jaxxzer commented 5 years ago

For example the fact that your specific vehicle has sensors which have that high of a resolution for height values is specific to a vehicle as opposed to a class of vehicles.

I think it could have something to do with the class of vehicles, water is so much denser than air and incompressible that the data from water pressure sensors is that much more precise. For other vehicles it would be difficult to guess though, so you're right.

I think the only appropriate solution would be for Facts to derive their display resolution from the mavlink spec (is a particular field reported in mm, cm or m?). I think this is more trouble than it's worth at this point.