Add default option to choose smallest target about vision_landing HOT 6 CLOSED

Problem with this approach is that pose estimation requires target size to be specified. Options are:

• See if size can be encoded into targets
• Split recognition and estimation into multiple levels, do a first level 2d recognition and order by area/size, then attempt pose estimation in ascending order of size. Smallest target with successful pose estimation wins, as this will be the physically smallest (and hence most accurate and reliable) target.

from vision_landing.

Add a capture threshold to debounce transition from one target to another.

from vision_landing.

Refactored code to do ordered pose estimation by marker area (size) order ascending, so smallest marker first. A static size mapping added, so:

// Temp declaration of marker sizes
map<uint32_t,float> markerSizes = { {12,0.5}, {36,0.24}, {85,0.11}, {161,0.11}, {166,0.11}, {227,0.11} };

If a size mapping exists for the marker id it uses that to perform pose estimation, else it uses the generic markersize config value, but it chooses the smallest marker with a valid size mapping as the active marker.
Chosen marker bounces a lot during transition, needs a threshold/debounce applied so marker transitions only happen when smaller marker is consistently captured across multiple frames.
Also need to add markerSizes mapping as a config variable and to somehow decode into c++ map.

from vision_landing.

Added --sizemapping (or -z) config setting that allows setting marker_id:size mappings. This allows the use of multiple markers with different sizes.

sizemapping=12:0.5,36:0.24,85:0.11,161:0.11,166:0.11,227:0.11

This is after parsing within track_targets:

Info['Size Mappings', '12=0.5, 36=0.24, 85=0.11, 161=0.11, 166=0.11, 227=0.11,']

from vision_landing.

Working nicely now, still need to add a debounce/threshold mechanism to stop fast transitions between markers that might upset flight control.

from vision_landing.

First attempt at adding a mechanism to stabilise the transition between markers. It tracks the history of each marker over the past 10 frames, and will only activate a new marker if the marker history shows it has been detected and estimated for >50% of the frame history. It helps but needs refinement, in particular the frame history size and threshold need to be configurable parameters, tracked in a separate issue.

from vision_landing.