I am programming a limelight to aim at a target, and i am running into an issue that the angles and distances of solve PNP that i am using to find the distance to the target in order to adjust speed aren’t very accurate and are rely shaky so i descided that to increase accuracy that we can make some assumptions
1.The height of the target relative to the limelight is constant (the limelight is in a fixed position on the robot and flat on the ground)
2.The roll of the target relative to the limelight is constant
using this if i make my own solve PNP that plugs these numbers into the matrices we can probably get more accurate and less shaky numbers (when we are flat on the ground),
we are using just a limelight and are out of power ports to use a raspberry pi with open CV so we are going to make this calculation only right before we are shooting how do where can i get a good example of the math necessary to solve this
On SolvePNP: we were getting measurements within about 4 inches @20 ft range on a Jevois earlier this season. What resolution are you using for your solvePNP algorithm, and from what distance?
That being said: As of right now, we’re not planning to use solvePNP this year. The problem statement is different than last year. Beyond some initial testing, there wasn’t a vast amount of work done with solvePNP.
It sounds a bit like you have a solution in mind already, so I’m not sure if this example will fit. Regardless, here’s a quick diagram of a simplified vision-based distance calculation:
Here, D_{range} is the distance you’re looking to solve for. H_{robot} and H_{target} are known constants you already mentioned in (1). \theta is the angle above the horizon at which the target is observed, which is a number you get from calculations off of the Limelight info.
Note that these measurements form a right triangle. Therefor:
Using our good friend SOHCAHTOA, we can derive an equation for D_{range} in terms of known values:
D_{range} Will end up in the same units as H_{robot} and H_{target}. Use the correct units for \theta to match whatever the expectations of the math library you use in software are. Most software libraries use radians.
Before we go any further, does this align with what you were looking to do?
It should also be noted: If the numbers you’re getting are generally accurate and coming in fast enough, but just noisy, an averaging filter may be useful.
Sweet! Let me know if you have any issues. There are some nuances to getting \theta, but I think you’ll probably figure them out as you start working . Sorry we’re gonna miss you folks at both regionals this year - here’s to hoping we run into each other at Champs!
. Sorry we’re gonna miss you folks at both regionals this year - here’s to hoping we run into each other at Champs!