longmetal-robotics / infinite-recharge Goto Github PK

Using the Wiring Plan, create a new class org.longmetal.Climb and create two CANSparkMax objects and two Solenoids for the drum spinner.

Right now, enabling and disabling subsystems through Shuffleboard isn't working - regardless of the value of the SendableChooser, they will throw SubsystemDisabledExceptions.

What I know about the problem:

• The SendableChoosers are working. When you change its value, the boolean sent to Shuffleboard updates to the correct value.
• It could be a problem with SubsystemManager, but far more likely is the Subsystem class not handling the updates correctly.

How to troubleshoot:

• Try enabling different combinations of subsystems. My theory is that the enabled variable belongs to Subsystem and is not being inherited to belong to other classes and it gets overwritten with each update (the last subsystem determines whether or not everything is enabled).

For this upcoming season, we should work on writing unit tests for our code (automated tests to ensure that critical components are working as expected).
This would automatically integrate with the current build process (gradleRIO, GitHub Actions) and allow us to fix problems before they even arise

I already did this for the shooter, intake and transporter, but we need all of the methods to make the climb actually work.

Create a DoubleSolenoid object for the rotator and a CANTalonSRX for the spinner. Also create a ColorSensorV3 object for the color sensor.
You will need to import the library from http://revrobotics.com/content/sw/color-sensor-v3/sdk/REVColorSensorV3.json.

The limit switch works as intended... but the .delay() function freezes the entire robot for that period of time, not just the transporter. So during those 3-5 seconds that the transporter should be running (and does), we cannot drive the robot or interact with other subsystems. This needs to be fixed.

I just finished wiring and coding the limit switch... and it works! We will want to do a bit of fine tuning in the code, but I can do that in my free time. I just wanted to create an issue for this to document it.

The Mechanical team requested the following:

• [-] Virtual end stops for the winch motors (stop the winch from reeling in too far and over-tightening the ratchet, added in 56f50d6)
• [-] Winch delay (start the winches half a second after the ratchet releases, added in efad5fe)

I was thinking the other day and I'm not convinced the subsystems really need to be instantiated as objects. It would work just as well to create static methods for them and might clean up the code significantly.

I'm gonna try to write some test code for the shooter before tonight's meeting, but we will also need to write some proper shooter code with values from the limelight and the proper controls that are in the google doc.

I spent a lot of the day yesterday (2/20) writing the code for the pneumatics. I did a little bit of testing (didn't work) but that was before I finished writing it. At this point, all of the code for the compressor, the 2 climb solenoids, and the DoubleSolenoid for the Control Panel should be written, it's just a question of whether it works or not. Hopefully I can test it tonight, but I will be potentially looking for help from @i-am-gizm0 if I can't seem to get it working, as I have pretty much exhausted my online resources.

SubsystemManager was originally meant for testing only certain systems when the robot wasn't completed, but it has been broken for a long time, so we should just get rid of it.

Sometimes, the shooter will rev up to over 5000 RPM and won't stop until we restart the robot code. This is kinda a big deal.

I realized earlier this week that we were missing a motor controller and motor in the wiring diagram. It is the NEO/SMAX combo for the transporter. So, we need to get our hands on another Spark MAX from somewhere, and get it flashed and give it a proper CAN ID.

We need to come up with a direction we want to pursue for auto code. I am plenty happy to write it, but I'm not good at coming up with ideas. Think of this like #22 , as a thread for ideas, conversations with the rest of the team, etc.

So if y'all could comment some ideas here, I can get to writing it :)

This is a low-priority thread, mostly so we can brainstorm ideas for LED stuff.
Don't work on this if you have something more pressing to do.

A pretty simple fix, one which we did on the x360 yesterday, but never committed. We have to remove parts of all of the .init() method calls in the subsystem classes. I'm not exactly sure the correct syntax, but if @i-am-gizm0 could inform me of such, that would be wonderful. This is basically just a minor issue for documentation (and me not forgetting) purposes.

Along with #73, to help avoid problems with multiple methods attempting to control the motor at once, the shooter should behave like a state machine and either update its state when methods are called (which wouldn't do much for preventing control collisions but could clear things up a bit) or require defining what state it should be in before calling it (it would throw an exception when you didn't).

There are a couple of things we need to fix:

• Shooter idle: the shooter should idle at 1000RPM when it isn't doing anything else but currently it just stops
• Singulator idle: the shooter should idle spinning backward slowly to keep the power cells out of the shooter
• At some point, we should also try to increase the speed of the robot because it's a little slow right now.

I have zero experience with Shuffleboard, so I have not been able to get the enabler boxes to show up in Shuffleboard. Instead, I commented out all of the getEnabled() statements so that I could test the shooter, intake, and transport motors without Shuffleboard. They all work, but now we need to add the enable/disable ability back into the code.

Currently, we write all telemetry to SmartDashboard, but Shuffleboard gets super clustered and we can't show everything we need to. We should use the Shuffleboard class to send values to different tabs in Shuffleboard.

To simplify reading the code, we should create wrapper classes for the different types of controls.

Gamepad

• getX/Y/A/B methods
• getDPad (maybe returns an enum)
• getAxis(enum trigger, enum axis)

Closely tied to #22, but once the breadboard with the motors on it is complete, we need to talk to the individual component designers about how fast they want their motors to spin, etc. We can then implement this code and test it on the breadboard, so we can hone in on optimal speeds for things.

We have everything that the robot needs to drive, except the code to make it drive. Similar to LongMetal-Robotics/ShowBot, we should use the Input class to get values and the DriveTrain class to actually drive.
While #7 is still open, you can just use the Input class, but when it closes, commit as you have it then work on implementing the new classes.

Limelight has a great article about getting the distance to a target using a limelight. @EarlJr53's ShooterFormula expects a distance in meters so we can use this to feed it values we need.

Right now, the org.longmetal.util.Listener class isn't being used at all. That's a shame because it was created to simplify acting on changing booleans, so we should use it.

Status Boxes

• Endgame (bool)
• RPM (num)
  • OK for shooting speed (temporary bool)

Enablers

• Control Panel

As I recall, we never finished coding for the color sensor (or at least never initialized it, even if we did the other stuff. This should be a simple thing to fix.

Sorta similar to #41 , but for the other end of the robot. @i-am-gizm0 already tried out the vision processing software on the ShowBot, but we now need to decide how we would like to implement it on the comp bot. If I have some time over the next few days, I will load the software onto the Pi and test it with the comp bot itself. We also need to write code to process the information that we get from the software and communicate with the Pi. I would probably defer to @i-am-gizm0 on the code side and I will stick to the software for now.

We created a few classes in LongMetal-Robotics/ShowBot that are useful for many situations. We should copy them over to this repo.
They are all in org.longmetal.util:

• Dual
• Listener
• Math

Using the Wiring Plan, create a new class org.longmetal.Intake and create a CANTalonSRX object for the intake motor and another for the transport motor.

Using the Wiring Plan, create a new class org.longmetal.Shooter and create a CANSparkMax object for the drum spinner.
Of note: you will need to import the REV libraries. To install it, open the WPI Command Pallet and paste this URL: http://www.revrobotics.com/content/sw/max/sdk/REVRobotics.json

I already did this for the shooter, intake and transporter, but we need all of the methods to make the singulator (grouped in with Shooter.java) actually work. To some degree, this needs to be tied into the shooter, as you only want this to be spinning when the shooter is at the correct RPM. However, sometimes you only want the shooter spinning, not this (because the shooter needs to continue spinning for most of the match).

This isn't something one person can work on - we should use this issue as a thread to brainstorm ideas and note conversations with the drive team (Matt S., @AndreasDuma).
We need to think of how each part is going to be controlled, for example:

• Do we still want to use Curvature drive?
• What buttons will do what?

Sam, if you could setup a new webhook from here to the #programming channel in the new Discord server that would be wonderful, I don't have the Github perms to do so.

Currently, Constants.java isn't really organized. Someone should go in and group everything together that goes together: everything drive train together, everything intake together, etc.

Looking through how some of our code is structured at the moment, I believe (at least in this repository) a command-based architecture could be useful

Right now, Test mode doesn't do anything useful and it's out of date, so I'm just going to get rid of it

Some things that we need to add at some point:

• PID for alignment: Lining up using the Limelight isn't super accurate since it won't turn much when it is already close. We should have PID for lining up with the Limelight
• Run the shooter backwards: The power cells get stuck in the shooter because the singulator idles forward (in #62), so we should let it run backward to get it out

Whoever works on this issue should make a new branch to keep everything clean.
This is super simple so you can probably use DriveTrain.java and every line that uses it from LongMetal-Robotics/ShowBot.

As of right now, the Limelight is configured to look for any target. We should create different flows for different targets (upper ports, lower ports, hps, etc.). This will also help because we can detect which flow is running and change the distance calculations (#40).

We need to start to write the code that takes the Limelight output values and tells the drivetrain how to steer to line up the shot, as well as tells the shooter how fast it needs to be going. This link might be a good place to start: https://docs.limelightvision.io/en/latest/cs_aimandrange.html
I've already written the code that takes a distance value and converts it into motor RPM. So basically we need to get distance and angle from the LimeLight. Take the angle and translate it to the drivetrain. Take the distance and send it to my code for the shooter.

In the code, the implementation of the color sensor is commented out. At some point, we need to figure out how to properly implement it.

Pretty self-explanatory. We need to figure out how we want to code them.

We know the design of the robot! Wiring Plan. We can start writing code! Someone needs to make a project and commit it to the master branch.

I already did this for the shooter, intake and transporter, but we need all of the methods to make the control panel (at least the spinner for now) actually work.

We have quite a few small things to get done and perfect this week.

• Add more auto modes #53
  • I will work on this, but @jon-pun and @fjfur10 can also work on it some.
• Test current auto modes (including on taped-out field layout) #53
  • Work with carpentry people (?) to put down accurate tape layout of half the field somewhere in the school where (hopefully) we won't have to take it up everyday.
• Try writing auto modes with PathWeaver #53
  • @jon-pun and @fjfur10 I would like you two to continue to work on this if possible, as you have the most experience with PathWeaver at this point. Create your paths assuming we will have an IMU. Also, if you can start adding the code to import the Paths, that would be wonderful. Please do that in .
• Add manual controls for everything and rework some controls #64
  • Given that I wrote all the other controls, I will likely continue to work on them, and keep in touch with our drive team about what they want.
• Move Limelight to other crossbar
  • Mechanical needs to make the crossbar a bit more solid, but if @achkvina or @Sky14r are at a meeting this week and need something to do, this needs to get done. We may have to also change the current crossbar over the shooter if it's gonna get in the line of sight of the new Limelight placement.
• Fix control panel code and test it
  • We haven't gotten a chance to test the code that @jon-pun and @fjfur10 wrote. I would like to talk to them about how to properly implement it (it hasn't been called by Robot.java yet), and then try to test it and figure out what needs to be fixed.
• More PID tuning #69
  • This isn't urgent at this point, but it's something that only needs @i-am-gizm0 to do.
• Tune shooter conversion factor and test from multiple angles relative to target (related to #69 )
  • This will help our consistency and help the balls not bounce back out.
• Mount LED strips inside drivetrain so that we have that out of the way while we have our hands on the robot now. Once other people take the robot back, I want to be able to have them in place so that we just have to worry about their code. #57
  • I will probably do this, with help from @achkvina
• Order Pigeon IMU (I feel like we had one, but I may be delusional; either way we need one). We just have to send it along to one of the mentors to order.
  • I will probably send this along to Lee and PDunks soon.
• Have the control panel go up and down fairly quickly at the beginning of auto to release the intake
  • I can do this, or @AndreasDuma or @jon-pun probably
• Tune low port mode
  • I will do this hopefully soon, but it's not urgent.

I know this was a lot, but it's pretty much all the stuff I can think of at the moment that we need to do for now. Some of this stuff will be assignable to those who have done less code, some of it pretty much needs to be done by myself and Sam.

COMMENT YOUR CODE
IF YOU DON'T KNOW WHAT SOMETHING DOES (and therefore what to comment next to it), ASK SOMEONE WHO DOES

Revamp controls and add in manual controls for every section of every subsystem.

I know this isn't the most pressing issue, but it's important to get done nonetheless. If I remember correctly, @i-am-gizm0 already wrote most of the code for the Pi to control the LEDs, but if not, @fjfur10 can probably help with the Python. In the next 2 days, I'm planning on cleaning up all the wiring in the robot, and while I'm at it, I will mount the strips inside the drivetrain. At that point, all we need is to hook up the Pi and complete the code for it.