southeugeneroboticsteam / deepspace-2019 Goto Github PK

Use encoders to drive straight, proportional to driver's input.

It'd be bad to climb accidentally before we're ready, so we should make sure it's only activated if some confirmation button is held, too:

({ getButton(12) && getButton(14) }).whenTrue { Climber.runClimbSequence(ClimberState.LEVEL_3) }
({ getButton(12) && getButton(15) }).whenTrue { Climber.runClimbSequence(ClimberState.LEVEL_2) }

Maybe?

Current, LiDAR values, leg state

Lift needs to be tuned so it can go zippin up and down real fast

Should just completely stop the climber from running at all, letting it drop down to the ground using gravity in case something goes wrong. @Jamdan2

Would be awesome to use Kotlin Script for our Gradle build. Several teams are already doing it so you should take a look around!

Abort, but stay level as we descend

If we have a game piece, align with vision target. If we don't have game piece, put claws out, align with vision target, and close claws.

This might live in the intake directory, we can decide/refactor later.

Will make it marginally quicker to lock on to target.

There are several fairly large changes, notably that use contains a CoroutineScope.

At 30fps, this should be sufficient time to process 8 images. Ideally, we should get rid of any outliers, or maybe just take the median for each measurement (x, y, robot_angle, target_angle).

https://github.com/SouthEugeneRoboticsTeam/DeepSpace-2019/blob/development/src/main/kotlin/org/sert2521/deepspace/util/Util.kt#L45

We could also add a kinematics util, eventually.

Allow switching between Joystick and Controller mode for driving, configurable through Shuffleboard.

Right now we're wrongly using internal. Instead, we might want to move the constants to be a private object at the top of each file?

Now that enable is called before teleop/autonomous in meanlib, we can safely remove:

The control spreadsheet has been updated in the Team Drive

Align using vision tape + white line on the carpet

This subsystem will be in charge of raising/lowering the lift.

Will probably be cleaner to access them this way from outside, e.g. in the Controls init.

We should have another selector for whether we want to do Hatch Panel or Cargo auto. If Cargo, run conveyor while doing first path.

Would be good to know when the DS disconnects if we're having difficulties in a match

A subsystem's reset() function will be called after every use() {} completes, and is nicer than having to remember to add a try/finally around every block.

https://docs.google.com/spreadsheets/d/11HlDqy3Rztu65bJi8EYcCalCQZJgqZy0AT4IPjYylow/edit#gid=0

Ideally it will auto-abort when driver starts to drive. Maybe can cancel the current coroutine context if joystick input > 0.05 or something? Worst case scenario, just add an abort button (click in on left thumb stick?).

There were some people on Discord saying that logging to the RIO/USB drive was really intensive due to the RIO's CPU not handling IO operations very well. We're recording logs at 10Hz and everything's done in its own coroutine so it likely isn't a huge deal, but we should asses whether it's worth the risk, or if removing the logging improves performance at all. Worst case scenerio we just record the telemetry values through Shuffleboard instead of the USB drive.