Prox Sensor Logic

[bcontino]

Optimize logic in proximity_sensing.cpp Condense/remove if statements Naming conventions on sensor vars

[QuentinTorg]

The current proximity sensor logic is a very bulky chunk of confusing if statements. There is probably a more elegant solution that makes things easier to visualize.

Right now all of the proximity pins are numbered. They should be renamed by location so it isn't so confusing. The named pinout is posted in a spreadsheet on the google drive

[QuentinTorg]

We should also keep our options open as far as sensor logic. Do we always want to be centering the other robot on our sensors? Do we want to have the ability to quickly alter which sensor we want to call the center so that we can have a secondary maneuver to skirt the ther robot, spiral in to make a hit, or intentionally hit them off center

[aftersomemath]

Could you please explain the current algorithm in more detail? Is it possible to assign a weight to each sensors reading and sum the result? The result would then be used to determine the direction to take.

[QuentinTorg]

That might work.

If the current layout is named Left, front left, front, front right, right

Errors are assigned to each sensor, so assuming one sensor sees it at a time, Left = -2 Left front = -1 Front = 0 Right front = 1 Right = 2 (We can weight sensors more by choosing different gaps between errors. Eg, right and left were 3 and -3 error

These errors are then used with a multiplier, like Kp in a PID loop, to determine how much our right and left wheel velocities should be offset to cause a rotation that would make our robot face the other

2 sensors next to each other that both see the robot will have an error that is an average of each

So I think you're right Levi, if we just take the average of our error from all 5 sensors it should give us an appropriate error.

[aftersomemath]

Could we then do this with an array of pins instead of naming each sensor pin. So our algorithm will look like this:

float average = 0; //Read in all sensor pins and place them in an unit8 unsigned int sensors[NUM_SENSORS] = //Read in all sensor pins place there outputs in an array of an unsigned int for speed for(int i = 0; i < NUM_SENSORS; i++){ if(sensors[i] == 1){ average += sensor_error_weight[i] } } average = average / (float)NUM_SENSORS; return average // average will then be used

I can't figure out how to fix the formatting.

This does not handle the case where we choose whether to move backwards or forwards however, I think we should just ignore the back sensors if the front sensors are picking anything up.

[bcontino]

The current new design, found in the ProxSenseClass branch, ProxSenseClass.cpp and ProxSenseClass.h, creates an object for a grouping of five prox sensors. For the sumo revamp application, this enables two classes to be instantiated, one for the front set of sensors and one for the rear.

Inside this class, the above logic in the thread is utilized where an int proxPin[5] creates an object with 5 pins corresponding to the sensor. Internally, bool prox[5] stores the sensor high/low and a second int weight[5] stores weights for each sensor.

There are two main functions, update() and generateAngle() as envisioned by Xavier. update() refreshes the sensor read values for each pin, and generateAngle() averages the sensor values with the weights to create a single int to represent the opponents location.

TO DO: In the generateAngle() function, the error values still needs to be calculated into a directional angle for the sumo bot (the easiest way to do this would be to alter the weights so that the resulting number is equivalent to the resulting angle).

The weight values need to be calibrated properly and the overall functioning still needs to be verified through testing.

[aftersomemath]

ProxSensor has been merged for initial setup of the entire program. It can be broken back out though for future revisions. Some slight changes have been made to how it is initialized.