team973 / 2018-inseason Goto Github PK

Add a rule to the style guide. We should use enum class where possible instead of enum. Here's the difference:

Here's some problematic code:

enum PandaType { /* these are the different kinds of pandas */
    Red,
    Giant,
    Qunling,
};

enum TulipColor { /* these are the different kinds of tulips */
    Red,
    Pink,
    Purple,
    Yellow,
};

/**
 * SaveThePandas saves pandas by preventing deforestation in China.  Saving pandas
 * is very expensive, though, so we can only save one type of panda at a time.
 * @param PandaType type: The type of panda to save
 */
void SaveThePandas(PandaType type) {
    // TODO
}

int main(void) {
    SaveThePandas(Red);
}

It won't compile because TulipColor "redefines" Red. It's also confusing. I look at SaveThePandas(Red) and I ask myself "where is Red defined? Is it defined in Panda.h or Tulip.h?"

Using enum class makes code that is easier to read and that is easier to compile. Here's the above example using enum class:

enum class PandaType { /* these are the different kinds of pandas */
    Red,
    Giant,
    Qunling,
};

enum class TulipColor { /* these are the different kinds of tulips */
    Red,    // this no longer conflicts with PandaType::Red
    Pink,
    Purple,
    Yellow,
};

/**
 * SaveThePandas saves pandas by preventing deforestation in China.  Saving pandas
 * is very expensive, though, so we can only save one type of panda at a time.
 * @param PandaType type: The type of panda to save
 */
void SaveThePandas(PandaType type) {
    // TODO
}

int main(void) {
    SaveThePandas(PandaType::Red);
    // You have to say PandaType now.  This makes it
    // easier to read because you can look for the definition of PandaType.  
}

In test mode we need a way to "Just kick the kicker" or "just kick the claw" so that we can facilitate fast troubleshooting in pits.

Add a "manual" state to clawState that does nothing

Add a ManualSetClawPosition(openState new_state) and a ManualSetKickerPosition(kickState new_state)

Add buttons in test mode that just extend/retract the claw and kicker solenoids

In order for test mode to function, we have to enable teleop first then enable test next.

Update the docs to use the SmartDashboard method instead

Allegedly the GameSpecificMessage sometimes gets sent late. Let's handle this case gracefully.

Add a value to SwitchScalePosition called NOT_YET_RECEIVED. Change the default value of m_switchScalePosition to NOT_YET_RECEIVED.

Change Autonomous::GetSwitchScalePosition so that if message is an empty string it returns NOT_YET_RECEIVED. While we're at it, change it so that it doesn't edit m_switchScalePosition... this function should return a value without any side-effects.

Change Autonomous::AutonomousPeriodic so that if SwitchScalePosition is NOT_YET_RECEIVED, it tries to GetGameSpecificMessage and figure it out. Some other refactoring in Autonomous will probably be necessary to make look clean. If SwitchScalePosition is NOT_YET_RECEIVED we shouldn't try to move. It might be worth adding some logic so that if we're a few seconds into autonomous and we still haven't seen that data we just do a GoForwardAuto but that's a crazy circumstance.

Ref @ocurr on this one.

Couple questions worth discussing before implementing this.

• Do we want to turn quickturn down all the time? Or just when elevator is high?
• If K_quickturn is non-constant, should it step down when height > X? Or should it be a continuous function?

Running the deploy script after switching robots/RoboRIOs will render an ssh key error (known_hosts), but the deploy script reports that it can't find the RoboRIO, which may confuse the user. Add an error that will tell the user to delete their known_hosts file.

Primarily needed for doing spline drive controller since Jaci's pathfinder lib generates 2*pi and 0 radians

The following things need to be done before we can make this repo public:

• add javadocs to important methods
• merge into master
• Add a section to readme.md explaining how the codebase is laid out (brief summary of what directories contain what)

Should we make a post to chief? I think there's a lot to show off in here but I don't like being showy

The purpose of RobotInfo.h is to closely mimic the wiring io doc (https://docs.google.com/spreadsheets/d/1DaA7qfedbfY7MqT84xOfW7y9QJhKsTjK7Y1HNPZIimM/edit#gid=1260314879). References to IO are stored in one place so they can be checked efficiently and so we can easily find unused Id's/slots/pins

Things that should go in RobotInfo.h:

• CAN ids
• Digital Inputs
• Solenoid IDs
• Analog ports
• Relays
• PDP slots (if used)

Things that should not go in RobotInfo.h:

• Numbers that change frequently
• Numbers that are only used in one file (soft-limits, pid constants, etc)

Grey area:

• Constants used in multiple files/subsystems

These are a few of the benefits to keeping RobotInfo.h slim

• Quicker to verify: slimmer file makes it easier to check all the ports and find unused ports
• Locality (variable declarations should be near variable uses): Something like ELEVATOR_FEED_FORWARD should go in the Elevator subsystem because if you're debugging the elevator you would probably check elevator.h before you check RobotInfo.h
• RobotInfo changes less often: When RobotInfo.h changes, every file that contains it must be rebuilt. Changing RobotInfo less often makes builds noticeably quicker

This issue involves moving some of the declarations out of RobotInfo.h and putting them in their respective subsystem header files. Deal with grey area constants on a case by case basis.

So far we've been handing out buttons first-come-first-serve. I want to figure out what low-level functionalities we want to have buttons for. Then we can fill out the button mapping spreadsheet and we can implement TestMode.

Think of some things that you want to have buttons for and throw them in this thread

These should be things you can't easily test in TeleopMode

A couple of the functions in the wrist subsystem have unintuitive side-effects.

Examples:

• Wrist::OpenClaw stops intake
• Wrist::StopIntake runs the intakes at -0.15 power
• Wrist::JustOpenClaw is somehow different from Wrist::OpenClaw which isn't obvious from the reader's perspective

Implement this in the path generator script

All the subsystems besides the forkus and hanger are implemented. Check out the button mapping document and implement that in TeleopMode.cpp. This should be relatively straightforward since the api calls already exist

We should just be able to pass starting position into the auto routine that makes it impossible to mix up

There are two things I'd like to solve with the current duel camera setup:

I'd like to continue exploring streaming to the default dash (Andrew briefly talked to me about specific camera naming schemes that might kick it to work)

I'd also like to implement the usage of Dummy Camera Sinks (as described here) to try and prevent any issues down the road with camera switching having a delay - We're not sure how it will behave with real robot cpu utilization and field network conditions.

GreyTalonSRX shall inherit from TalonSRX

GreyTalonSRX shall have a public method called FactoryReset which runs through everything that you can configure and sets it all to default values

The constructor for GreyTalonSRX calls this->FactoryReset

In the future we may chose to add more methods to GreyTalonSRX.

Champs intake has 2 solenoids in serial:

• clamp cylinder. default closed. When fired, wrist is loosely clamping
• spring cylinder. default closed. When fired, wrist is open wide

And we want to support 3 states:

• intaking... clamp fired, spring default
• clamp... clamp default, spring default
• open... clamp fired, spring fired

During the intake sequence, when the cube is seen (or when driver presses stow), switch from intaking to clamp

The state machine in IntakeAssembly is great at avoiding collisions and smoothly transitioning between manual operation, position-preset operation, and hanging operation. The intaking operation is mucking up what would otherwise be a very clean state machine.

https://github.com/Team973/2018-inseason/blob/silicon-valley/src/subsystems/IntakeAssembly.cpp#L407

It's non-obvious but calling GoToIntakePosition changes the ControlMode to one of the position control modes. This does a great job of moving the intake to the ground but it leaves us in a state where we are no longer waiting for the cube to finish intaking.

There are multiple ways to fix this. This is currently implemented in teleop as a quick hack (https://github.com/Team973/2018-inseason/blob/silicon-valley/src/TeleopMode.cpp#L80). One way to solve this issue would be to clean up the teleop implementation and store a member variable in Teleop.

• make s_intaking a member variable of Teleop
• track 3 states: VaultIntaking (on IsCubeIn, flash lights and set the wrist to holding mode), SwitchIntaking (on IsCubeIn, flash lights, go to stow position, and set the wrist to holding mode), and Idle (don't do anything... the user isn't intaking) and implement them in TeleopPeriodic

Now that we use test mode we don't need tuning joystick. If we don't have 3 joysticks plugged in then we get an ugly error every second or so. Remove references to tuning joystick so I don't have to look through error outputs

Merge #100 for now, but we need to figure out a solution to this, preferably before SVR.

Will be a pain because getElementById() only gets 1 element. You could use getElementsByClassName() but we would have to restructure a lot.

This is a thread containing all autonomous routines that we want, all trajectories with the routine, their waypoints, also discussions of misc auto stuff.

Using the python wrapper over the pathfinder lib, write a script that takes in the path to a trajectory description file and a path to a header file and writes the appropriate header to the header file.

Notice the script takes in two paths. You'll need to open these files and read/write to them.

The input file will be in JSON and will have the following fields: name (string), timestep (float), max_vel (float), max_accel (float), max_jerk (float), waypoints (list of objects).

Example input file:

{
    "name": "the_really_cool_trajectory",
    "timestep": 0.01,
    "max_vel": 15.0,
    "max_accel": 10.0,
    "max_jerk": 60.0,
    "wheelbase_width": 23.0,
    "waypoints": [
        { "x": -4, "y": -1, "angle": 45 },
        { "x": -1, "y": 2, "angle": 0 },
        { "x": 4, "y": 20, "angle": 0 },
    ],
}

Example output file:

#include "path_to_pathfinder_struct_definitions.h"

namespace generated_profiles {

TrajectoryDescription the_really_cool_trajectory {
    .timestep = 0.05,
    .max_vel = 15.0,
    .max_accel = 10.0,
    .max_jerk = 10.0,
    .wheelbase_width = 23.0,
    .length = like a few hundred tbh,
    .left_trajectory = {
        {.dt=0.050000, .x=-12.494159, .y=7.476393, .position=0.003125, .velocity=0.125000, .acceleration=2.500000, .jerk=50.000000, .heading=0.786670},
        {.dt=0.050000, .x=-12.534830, .y=7.435379, .position=0.060886, .velocity=1.155218, .acceleration=20.604360, .jerk=362.087205, .heading=0.792525},
       etc etc etc for a few hundred lines tbh
    },
    .right_trajectory = {
        {.dt=0.050000, .x=4.497976, .y=-9.472571, .position=0.003125, .velocity=0.125000, .acceleration=2.500000, .jerk=50.000000, .heading=0.786670},
        {.dt=0.050000, .x=4.556250, .y=-9.413805, .position=0.085886, .velocity=1.655217, .acceleration=30.604346, .jerk=562.086919, .heading=0.792525},
        etc etc for a few hundred lines tbh
    },
   .centroid_trajectory = {
        {.dt=0.050000, .x=-3.998092, .y=-0.998089, .position=0.003125, .velocity=0.125000, .acceleration=2.500000, .jerk=50.000000, .heading=0.786670},
        {.dt=0.050000, .x=-3.989290, .y=-0.989213, .position=0.015625, .velocity=0.375000, .acceleration=5.000000, .jerk=50.000000, .heading=0.792525},
        etc etc for a few hundred lines tbh
    },
};

}

Later we'll actually follow these in C++. I imagine we'll add a drive control and a method into Drive so that we can run the following command:

m_drive->SplineDrive(generated_profiles::the_really_cool_trajectory);

There are obstacles to avoid here. There's multiple ways to do this. Whatever we do we should motion magic the elevator and claw to minimize cube droppage

We set Wrist::m_controlMode but we never read from it. Why does it exist? Probably best to remove it

This was brought to my attention Tuesday -
There will be a monochrome 128x64 oled screen attached to the roborio,
it's very low on the priority list, but if we can get it running that would be great for debug/auto/whatever.
I've been told it will be wired up to the i2c port on the mxp (it takes i2c or spi).

We should be able to port over adafruit's arduino library.

Drive::SetDriveOutput is confusing and error-prone. Replace this with the following:

Drive::SetDriveOutputInchesPerSec takes in units of inches per second and converts them to units of RPM (sets a velocity setpoint)
Drive::SetDriveOutputInches takes in units of inches and converts them to units of clicks (sets a position setpoint)
Drive::SetDriveOutputPercentVBus takes in units of -1.0, 1.0 (sets a percentVbus setpoint)

Let's do this after the drive branch merges

Someone could hack our #programming_updates channel in slack! 😮 Encrypt configuration. Slack Notification Configuration

CTR Electronics Software Update: An issue has been identified in the interaction between the
roboRIO image and the CTR Electronics Phoenix software that can result in CTR Electronics
CAN Motor controllers failing to properly enable, and an error being reported to the Driver Station.
While the exact source of the issue has not been determined between the two components, CTR
Electronics Phoenix versions 5.2.2.0 and later contain a patch that reduces the likelihood of
occurrence. Teams are strongly encouraged to either update to Phoenix 5.2.2.0 or to learn how to
circumvent the issue by reading the additional information found in the CTRE Phoenix
documentation under Driver Station System Watchdog -63194.

We haven't seen the issue yet AFAIK

Also apparently restarting code fixes it - not that we want to do that if we're on the field.

There's no todo associated with this issue, I just wanted to make sure no one forgot that positive angles are counter-clockwise.