deepbluerobotics / robotcode2018 Goto Github PK

https://trello.com/c/1NRZCgWx/166-implement-talonvelocitypidcontroller-too

We were having problems at SFR where the lift would not completely make it back to the ground during auto. After auto, the lift would often not completely be able to reach the ground. Needs investigating. Is this just tuning PID???

Test that proper commands are executed and the arguments are passed correctly.

controllers.txt says what each button and joystick does. (it's not up to date yet, but we will make it so.) there should be an alias to it for easy access.

maybe create a universal constructor for both

Establish a standard for length unit and angle unit in the code, and change the code to reflect that. If a standard is already established, make sure all programmers know about it and it is easily accessible, and fix code anyways.

i talked to rafael and he said he and maya practically never use the switch drive type button because they're always in arcade, but rafael said he'd prefer switch to low gear to be the right joystick's button 3 and switch to high gear be button 4. your mission, if you choose to accept it, is to make this a reality. be careful of merge conflicts and be sure to also update controllers.txt.

At the moment there does not seem to be a way for the operator to stop the intake motors after they've been started (in either direction). The only time they appear to be stopped is when a cube is in the intake.

@lhmcgann was this an oversight or was it desired behavior from the operator's perspective?

The fix might be as simple as changing whenPressed() to whileHeld() for the current intake commands.

This should be done after PR #78 is merged.

The idea would be to use low gear when holding position and high gear when changing positions.

This is based on the analysis which determined current draw necessary to hold lift in a given position without a counterbalance.

If the script can't be parsed, something is wrong and the user needs to take action to correct the problem. As a result, this condition should be logged as an error instead of a warning.

The tests should also verify that the appropriate logging occurs. It's not critical that the tests verify the full text of the error message, but they should verify that the message is logged as an error instead of a warning.

The code associated with moving a particular distance or turning a particular amount is currently spread across several classes. It should be centralized, probably in the associated commands. For example, the moveController and turnController objects should be moved out of Drivetrain and into the commands.

We should try using these formulas:
Turn Velocity: V = 4r √((TGθ) / (Rm))
where r = half of' distance between wheels
T = max torque of wheels
G = gear ratio
θ = rotational distance to end of turn
R = radius of wheels
m = mass

Move Velocity: V = √(8TGd) / (R*m))
where T = max torque of wheels
G = gear ratio
d = distance remaining
R = radius of wheels
m = mass
G = gear ratio

rafi and maya (as drivers, although idk if they're the actual drivers) have a feature request. the robot should move slower while they hold the triggers. preferably, forward-and-back movement would be slower while holding the trigger on the forward-and-back arcade joystick, and turning would be slower while the trigger on that joystick is held. this would probably be a coefficient of maybe .5, probably changable on shuffleboard so they can try different things, that gets turned on on trigger down and turned off on trigger up.

I think we are running into this bug: kauailabs/navxmxp#29

As far as I can tell we aren't running "[Update: 1/13/2018 – Version 3.0.346 has been released, which is compatible with the 2018 FRC release version 2018.1.1.]"

Download the latest from here: https://www.pdocs.kauailabs.com/navx-mxp/software/roborio-libraries/java/

And install in lib folder.

Mackenzi, Alice, Josh and I noticed this at Maker Faire. We could intake one cube and eject it, but then could not intake a second cube (the wheels would not spin in the intake direction when pressing the associated button). The problem would go away if we restarted the code though, so it was clearly a code problem. My theory is that it thinks a cube is still in the intake even after it has been ejected.

https://trello.com/c/7OOvkOJG/167-implement-pid-on-lift-encoder

We need to be able to read the distance and rate from the encoders when they are connected to the Talon instead of the RoboRio. Create a class PIDSourceFromTalon that implements PIDSource and can be used to read the rate or the distance from an encoder that is attached to a Talon.

The Drivetrain subsystem should be responsible for moving the left and right side of the drivetrain at requested speeds. That implies adding velocity PID controllers for each side and using those controllers as SpeedControllers passed to DifferentialDrive. To that end, the velocity PID controllers should implement both PIDControllerInterface (so that they can be tuned and monitored) and SpeedController (so that they can be passed to the DifferentialDrive constructor). Two implementations should be developed -- one which uses wpilib's PIDController to do the control and the other which uses the TalonSRX's internal PID features.

Per Team Update 14, we should uprgade to Phoenix 5.2.2.0 to reduce the likelihood of CAN-based controllers being disabled on startup with a "Driver Station System Watchdog
-63194" error logged to the console.

If the error does occur, the Phoenix docs errata says we can workaround it by restarting the code.

https://trello.com/c/NJLTZaSx/175-figure-out-and-set-the-input-output-ranges-for-all-pid-controllers

https://trello.com/c/q4VdqxPs/174-look-into-and-actually-do-removing-all-statics-from-code

If the lift is in holding position and the manipulator button is hit to tell it to go to the ground, it will not do so unless it has jiggled out of tolerance of holding position. It needs to be able to go to the ground from any other position. Everything is in the UpdateLiftPosition command.

These should not need to keep setting the solenoid value for any period of time. If they do, it's probably a symptom that something else is wrong and should be fixed.

getRate() is supposed to be degrees per second, we thought it was really radians per second, turns out it's neither. probably use getRawGyroZ() instead. you could just change the variable names so they don't make it seem like the units are radians per second, since the code basically works using getRate(), but then if they release a fix to the getRate() bug, we have to change the code.

I'm referring to methods like this one:

Consider what happens if there is already an entry with the requested key but it is of a different type.

The output should not be empty in test11():

Ditto for test13().

Most importantly, "(4, 20)" should be allowed since putting a space after a comma in a common convention and would be a particularly common mistake.

See: https://github.com/DeepBlueRobotics/RobotCode2018/pull/5/files

At the moment, these commands finish if onTarget() is true for just one cycle. However, this can happen while passing through the target value (i.e. overshooting). The result is that PID is disabled while still in motion and the final resting position/orientation can be significantly different that requested.

@Gabe-Mitnick suggests only letting isFinished() return true if we are onTarget() and the rate (e.g. ahrs.getRate() or encoder.getRate()) are sufficiently small.

Is there a reason that's in there or is it just by mistake?

Add try-catch to other default commands to avoid NullPointerExceptions.

In shuffleboard

In order for scriptupload.py to succesfully upload the script, it currently waits for 0.1 seconds after putting the script into the NetworkTable. This should work, but might be unreliable.

Instead, we should investigate whether calling NetworkTables.waitForEntryListenerQueue(None) can be used instead. It seems to be intended for this purpose.

https://trello.com/c/CpbgyDUk/173-add-a-dead-zone-ie-threshold-to-joysticks-so-the-velocity-pid-doesnt-go-crazy

On the practice bot, we did this via the webdashboard. We should change the code to do it programmatically, so that it happens automatically on the comp bot.

https://trello.com/c/zTvvaVgv/172-implement-current-limit-on-dt-motors-so-doesnt-exceed-40amps