You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Speed controllers have a bit of NVRAM to persist config including invert
and brake/coast. They don't write the NVRAM unless you explicitly ask them
to though.
Anything you send at runtime overrides whatever is in NVRAM.
I highly recommend explicitly initializing the invert and brake/coast
settings so that we're never surprised when we have to swap a speed
controller on the fly.
Ask King whether we want brake or coast for the drivetrain. Arm, climbers,
and indexers should probably be on brake, and the shooter flywheel on
coast. Flywheel could go either way, but I figure actively stopping it is
just extra mechanical stress and wasted power. Particularly if we decide to
spin it back up again quickly.
Worth noting, because you can set the state a runtime, we've been known to
toggle it strategically. For example drivetrain on coast mode for smoother
driving, but switching to brake mode for "anchor" behavior.
On Fri, Mar 18, 2022, 15:37 Victor Chen @.***> wrote:
While driving the robot today (running code off of master), the wheels
turned as if the robot was trying to turn right with forward joystick
input, and the wheels turned as if the robot was trying to turn left with
backwards input.
A potential culprit is the system identification routine that I ran on the
drive train yesterday, where the right motors were inverted but the left
were not. I suspect that the the inversion setting in the Spark MAXes is
sticky across reboots. @BowlesCRhttps://github.com/BowlesCR—does this
sound right? Since the inversion of the right motors is not explicitly set
every time the robot program starts, but the left motors are set to be
inverted every time the robot program starts, this would explain why it
appears that both sets of motors are inverted.
A potential fix is to add the following line to the DriveTrainSubsystem
constructor:
Speed controllers have a bit of NVRAM to persist config including invert
and brake/coast. They don't write the NVRAM unless you explicitly ask them
to though.
Anything you send at runtime overrides whatever is in NVRAM.
I highly recommend explicitly initializing the invert and brake/coast
settings so that we're never surprised when we have to swap a speed
controller on the fly.
Ask King whether we want brake or coast for the drivetrain. Arm, climbers,
and indexers should probably be on brake, and the shooter flywheel on
coast. Flywheel could go either way, but I figure actively stopping it is
just extra mechanical stress and wasted power. Particularly if we decide to
spin it back up again quickly.
Worth noting, because you can set the state a runtime, we've been known to
toggle it strategically. For example drivetrain on coast mode for smoother
driving, but switching to brake mode for "anchor" behavior.
On Fri, Mar 18, 2022, 15:37 Victor Chen @.***> wrote:
Originally posted by @BowlesCR in #22 (comment)
The text was updated successfully, but these errors were encountered: