Questions of operator control.

[harshilgarg]

For this please refer to the CodeNotes file that you had sent me, underneath the operator control section.

1) I have yet to implement a manual click set, but I see the necessity of such a function.

2) Yes, that is the current number of clicks and the target number of clicks are printed to the SmartDashboard, as seen here.

3) See this.

4) It might be quite a challenge to pass the ball. Do you think that if the ultrasonic rangefinder calculated distance to that robot, the same shoot command could be used to pass the ball as well? If so, we might considering having two rangefinders, one for goal shooting and the other for passing.

5) We would have to implement a camera distance calculation, and at that point, what is using the ultrasonic rangefinder in the first place? If a robot moves in front of us, the winding motors will only change for a brief second if it passes in front of us, and then change back. I really recommend installing the rangefinder at the height limit if possible, and securing it well.

6) Why would we need this? Please give an example of the situation.

7) A way to wind up without shooting? Did you understand what I meant by "constant winding"? As the robot moves around the field, it controls the winding mechanism based on how far the goal is. See this

8) All of these are SmartDashboard fields, and editing them into appealing JavaFX widgets is a completely design-oriented task and requires no real knowledge of programming. It is done for you in SmartDashboardFX - it would be a matter of setting it up once competition time comes around.

[harshilgarg]

Look at the latest commit when possible - I have changed from constant winding to default of no winding. The constant winding option can be toggled on and off. The start wind button takes the target click number, winds it until that (not constantly re-updating the target range) and times out. Finally, the operator control takes a value of input from the SmartDashboard, and winds it until that. In the start wind and operator set winding options, the robot should not be moved after the call of those commands. There will most likely be quite a few logical bugs, but I think I have the basis of a solution worked out.

[harshilgarg]

If this code works, however, then the only thing left would be implementation of a camera. I have started researching that already. The logic for integration of the camera would function as such. There would be an enabler boolean: true for the rangefinder and false for the camera. The operator can choose which one to use via the SmartDashboard, or even a toggle button on the joystick (much easier to code). Each function, upon assessment of these values, would conduct calculations from there. This would be beneficial in three ways - camera is always a cool way of calculating distance, we have enough off time in the season, and most importantly on my side, it would not require the editing of any commands. Basically, the getDistance methods of the ultrasonic rangefinder is the basis for the rest of the code's functionalities. In order to get the rest of the code to work fine for camera distance calculation, all we have to do is change the way of attaining the distance - and the rest of the code would stay the same. So if we can establish a reliable way to get distance from a camera, we can quite easily use a camera for shooting into goal purposes (not passing), since unless alliance members want to put reflective tape on their robot. I have a good idea - are we allowed to coat our robot in reflective tape so that all other cameras fail when we go and cause disturbances? :)