Kevin M.

Feb. 17

• Recreate the function for pixel density as a function of distance using the bigger images for added precision, but then scale back down to 1/4 resolution

The encoder units for drive train rotational PID (previously called "lateral PID") are a measure of angle, however pixels are NOT. To get pixels to encoder units, one must take the frustum of the camera (top-down view) and add an arc at the end of the far view plane. One must then make a line between the vertex and the pixel point on the far frustum plane, then extend this line to the arc. The arc has encoder units, the far view plane has pixels. To get the actual number for encoder units, one must first find the angle, in degrees or radians, between the center of the window and the windage adjustment point. This will create a triangle inside the frustum. One must then find the angle created within the frustum by (HOW). This angle can then be directly converted to encoder units via a configurable ratio.

Feb. 18

After doing work to solve the equation for Theta (the encoder units) based on lateral control, I have discovered I do not know what is labeled as C1. I also do not know what is labeled as X. I know the length of ONE of the legs of the Scalene triangle connecting the vertex to the window on the plane. There must be further thinking about this to solve for theta. One assumption I made was the distance labeled X mattered. IT DOESN'T. No matter where you intersect the frustum, the ratio of the side lengths will be the same. Is the same true about angles? IDK

Also, the distance from the camera to the BASE of the window should be a config item, not hard coded into "OzMath." (the number is OzMath is wrong anyways).

The configuration for the new drive train is NOT updated, that needs to be updated in the .cfg file, which has not been tested on the ANT transfer

Use of the git repo is becoming increasingly difficult with multiple users due to the path dependencies of the workspace committed. Is there any way post build-season to get these files out of the repo (EXCLUDING the build.xml file to upload the .cfg file)?

Most of the drive train class appears to be done, including some stuff which is used for auto-aiming. I got a little bit out of scope when working on that math problem. It is NOT necessary unless we are using the PID control on the DT for aiming. For the next few days we need to focus on getting the baseline done and tested. The multi-pid controller is still necessary for auto, but perhaps the design of the MultiPID Controller module can be changed to have settable outputs (i.e. multiple inputs and outputs for each module, which can be set from the MultiPIDSubsystem class).

This new design would unify spinning and moving forward for the purpose of crude movement into one PID controller, but just with flipped outputs. Getting the right encoder units for spinning should be as easy as getting half the distance between the drive train, using that as the radius, and solve for the angle from the arc length (the value returned from the encoders since it looks for linear motion). This can also be used in the Auto-aim PID control to convert encoder units to angle units instead of tediously testing the drive train rotation. Would this be precise enough for window aiming though?

Tolerances should be percentages, because askew angles Don't matter. We don't care about the ACTUAL width of the window, we know that; all we care about is the PERCEIVED VIEW OF WINDOW. Going along this, converting the viewed window width into inches, we can decide if the ball will go in AT ALL based on the diameter of the ball and the width of the window. Tell the user that they CAN shoot, but the rate it will go in is significantly lower b.c. it must bounce off the rim even when it is as close to centered as possible. Also, tolerances might be able to be more than 3 inches, because if it hits the side, it still might go in (even a straight on shot). It is not that important, but still keep in mind the tape we see is WIDER than the window (perhaps subtract a constant percentage based on a ratio)