Altimeter Counting Wrong Intermitantly about altipi HOT 18 OPEN

Thanks for reporting this! You wouldn't happen to have the debug_altimeter.txt log as well for those orders, would you?

from altipi.

No this is on a old altimeter without the new firmware. That may be the issue. We need to get the rest of the altimeters up to date. I am going to plug one into the server now.

from altipi.

Okay a blank SD is in there now.

from altipi.

Sorry didn't mean to close that! :/

from altipi.

altimetry_1.txt
altimetry_2.txt
altimetry_3.txt
altimetry_4.txt
altimetrydebug_1.txt
altimetrydebug_2.txt
altimetrydebug_3.txt
altimetrydebug_4.txt

from altipi.

Here are some altimeter logs with some problems. This is with the new altimeter firmware. It looks like most of the readings are legitimate but some of them read 130.00m which is clearly wrong. I think this may be due to the altimeter not receiving a signal back. We may need to contact the manufacturer again to see why its doing this.

from altipi.

Interesting--it's definitely a problem with the data we are getting from the altimeter itself. In the case of the 130.0m we get several of those readings, which throws off our smoothing algorithm to have so many wrong readings. And those are coming directly from the altimeter.

If it turns out that the manufacturer doesn't have an explanation, I can play with the smoothing algorithm some more to throw out huge jumps that are consistent over several readings (ie, getting 130.0m 14 times in a row.) I do worry a bit about how we don't actually have a good reading for the altitude at that point and are just making one up. I'd prefer to understand why we get such unreasonable readings in the first place.

from altipi.

@tkollmorgen Can we get the corresponding drone logs for those altimeter files? It'd be good to cross check the agl and pitch/roll values for any correlations.

from altipi.

2019-06-04 15-30-46.log
2019-06-04 15-50-21.log
2019-06-05 08-12-12.log
2019-06-05 08-33-20.log

from altipi.

We will add a checklist item to wipe the altimeter clean every flight. Its possible dust is causing some of the problem.

from altipi.

Re: altimeter count being off: Could this be related to us not taking an official reading unless the flash goes off? We don't actually take a reading with every image taken, but every strobe of the flash. Let us know if you see that with the new firmware.

I think that and the 130 reading are two separate issues, as well.

from altipi.

More on the 130.00 reading--the docs for the altimeter say the altimeter sends that whenever it drops signal. However, we can tell the altimeter to resend the last good reading instead. This may help with this issue. Going to test on a altimeter once I get one here.

https://drones.altigator.com/docx/SF11-Laser-Altimeter-Manual-Rev8.pdf

from altipi.

from altipi.

A middle option is that the altimeter will let us set a timeout so that after a set number of milliseconds, the 130.0 value is sent. If it a transitory issue with the readings, that would eliminate us getting the bad value. If it's a long term problem, we would still be able to see and react to it.

from altipi.

from altipi.

Do you think that'll produce better results than interpolating a value using the debug_log?
The more I think about it, the more I do like the idea of being able to log when we see the out of range value, since that gives us information on potential hardware problems. I do want to play with the settings though, because if using their last value stuff "fixes" the altimeter issues we see, then we would know to copy that solution in our code. If it doesn't fix it, then repeating what they've already implemented won't fix the issues, even if we get more debug information.

from altipi.

Moving to backlog until we understand the rate at which we get the extra reading counts. If it happens often, we will fix in software.

from altipi.

Roger. We will keep track of issues on our side and let you know how it goes.

from altipi.