team973 / 2018-inseason Goto Github PK
View Code? Open in Web Editor NEWPower Up code of FRC Team 973: The Greybots
Power Up code of FRC Team 973: The Greybots
This is a thread containing all autonomous routines that we want, all trajectories with the routine, their waypoints, also discussions of misc auto stuff.
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
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);
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.
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 TeleopPeriodicThe following things need to be done before we can make this repo public:
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
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.
We set Wrist::m_controlMode but we never read from it. Why does it exist? Probably best to remove it
There's no todo associated with this issue, I just wanted to make sure no one forgot that positive angles are counter-clockwise.
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:
Things that should not go in RobotInfo.h:
Grey area:
These are a few of the benefits to keeping RobotInfo.h slim
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.
Implement this in the path generator script
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.
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.
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.
Ref @ocurr on this one.
Couple questions worth discussing before implementing this.
K_quickturn
is non-constant, should it step down when height > X
? Or should it be a continuous function?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
Someone could hack our #programming_updates channel in slack! ๐ฎ Encrypt configuration. Slack Notification Configuration
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
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.
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
In order for test mode to function, we have to enable teleop first then enable test next.
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.
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
Primarily needed for doing spline drive controller since Jaci's pathfinder lib generates 2*pi and 0 radians
A couple of the functions in the wrist subsystem have unintuitive side-effects.
Examples:
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.
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
Champs intake has 2 solenoids in serial:
And we want to support 3 states:
During the intake sequence, when the cube is seen (or when driver presses stow), switch from intaking to clamp
We should just be able to pass starting position into the auto routine that makes it impossible to mix up
Update the docs to use the SmartDashboard
method instead
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.