rbmj / 612-code Goto Github PK

Use the PID controller class to make it so we can set a speed, wait until the speed is within a certain tolerance, and then shoot.

Hopefully we'll have the encoder on the shooter wheel by Wed/Thurs. As soon as we get this we need to test, changing the PID gains until they work. Just some boilerplate code that has a few different buttons that sets the RPM, and some debug printfs to output the current speed and the setpoint. Remember to slowly increase the P value (and when it says slowly, I mean slowly. Like start at .05) until you get a small constant error. Then make a tiny I value (tiny like .01). The I component really makes it unstable if you go too high. Then tweak with a D value. You can see some sample theoretical response curves at wikipedia.

We need the same thing for the potentiometer on the launch deflection angle. This is next priority after the launch angle speed. The pulleys should be wired very soon. Figure out what the voltage should be (remember to use oversampling).

We also need some PID gains for the drivetrain in case we need to go back a certain distance. We need to talk with Mechanical people about this. Find the gear ratios (note that this will change when we change the gear, so remember to change the SetDistancePerPulse() whenever we shift), and figure out what the theoretical distance per pulse should be for each gear. But this is lower priority.

PID Controller Class Reference Doc:
http://rbmj.github.com/612-code/doc/html/classPIDController.html

Note that all of the sensors multiply inherit from PIDSource, and Jags multiply inherit from PIDOutput. So just a &sensor, &jag should work.

PIDController::Enable() spawns its own thread to handle updating, so no need to have a .update() for that. ::Disable() will also set the jag's output to 0 to stop the motor

Remember to call SetTolerance! This needs to be small enough to remain accurate while big enough to keep the system from oscillating.

Turret has to rotate until the center of the target is located at the center of the image. (Compares X values)

Take the state loops out of main.cpp. Create a new file for each state. This should make main.cpp easier to use.

For some reason, the shifters like to move to neutral. I don't know why. I'm going to run it on guillotine and see if it's a code issue or something with the mechanics of how the shifters have been installed.

The problems seem to be primarily focused on the left shifter.

To diversify the code base and to avoid having giant functions, can we move all of the code logic to some callbacks that are registered with the state? The two easiest ways to do this are with the state_machine type construct in hex43 and the registry. I don't care how you do it, but we need to make this easy and extensible. I see state machines running inside of state machines... :)

Has to lower angle deflector until it's at the right angle. Set it straight DURING driving mode- this way the driver gets control back faster.

Assigning this to myself, but if someone else wants to tackle it, be my guest.

I have vision_alt code working. However, I was thinking that the heuristic might fail. In that event, we want to make sure that vision_alt still works.

Instead of identifying targets, what if we just kept track of the four largest particles that fit the criteria? Then, we just find whichever one is the highest up

We need to test the particle analysis in vision_alt to see if the heuristic is working well. We also need to make more targets. TEST TEST TEST TEST TEST!!!!

Gets the vector of targets, decides which one we should shoot at.
Sort targets array by Y value, look for the highest target.

Option to try once we're done with everything else: turn LEDs off, take one picture, turn them back on. Get the targets from that picture and delete any targets that show up in both vectors from the original one- this should eliminate any of the lighting that passes as a target.

Anirudh, I assigned you cause I can't seem to assign Jeff. But you two need to work together to implement shooter::ballspeed_to_rps() in shooter.cpp. This shouldn't take too long.

shifter.cpp This code may be making the servos warm
Because of the update(), the servos are being set 50+ times a second
These appear to be a set once objects, and does not need an update() function in the registry.

Suggest the servo be set in the shifter::set() using the code from shifter::update()
and remove update() and associated code.