Java Progress Report

[Vanshika C]

1/14/18:

I worked on swerve today. Here's what I got done:

• Copied over all code from 2017 for the Drivetrain subsystem
• Set up Joystick Command
• Attempted to test on last year's robot

The code does not work right now; the main problem we've been seeing is inconsistencies in turning. The first time we tested, the wheels continuously turned. We thought this might be because of the quad encoders being reset, so we tried to comment that out, but then the wheels stopped turning all together.

We decided to make a separate "Swerve Test Bot" to pinpoint the problem. So far, we've integrated in the drivetrain initialization methods and the joystick command. After adding the joystick command, the Swerve Test Bot stopped turning too, but we're not sure why. I did all of my testing on dev 3 (the robot labeled with the "Pixy"), but I didn't commit any of my code.

I'll be there on Tuesday. Email if you have any questions

[Matt S]

In the last post, we have determined that we were having issues because the CTRE libraries had changed some of the functionality of the CANTalon methods.  Today, as well as for the past few days, we have continued getting the swerve drive working.  The swerve still does not work right now, but it has improved since the last post.

Currently, the swerve drive now almost works correctly, but the wheels are strafing in the opposite direction.  We figured out that this was because of the encoders and each of the steering motors needing to be inverted.  We attempted to invert the wheels, but now all of the wheels are jittering.  This might be because of the ShouldReverse() method, or for many other reasons.

As for the rest of the swerve drive functionality, the rotational movement still needs to be tested, as well as drivetrain mode switching.

[Matt S]

Today we got the swerve drive working.  When using the CTRE CANTalon methods, we could not get the encoders and steer motors to invert with each other.  Instead, we created our own method in the CANTalon swerve enclosures to accomplish this ourselves, and the swerve drive now works correctly.  The swerve drive was also curving slightly in its movements so we readjusted the absolute encoder values to fix this issue.  On top of that, we added joystick deadzones to better control the drivetrain.

We also tested the distance encoder on the drivetrain, and it was incredibly accurate.  To do this we created a new command called DriveForward, which can currently be called by the SmartDashboard.  The command itself, as well as the methods that it uses, are only temporary and can be modified to support different uses.  Also, all of the new swerve drive code is now on the master branch.

The next thing we are doing is testing PID control for preparing to easily control the arm.  To do this we got a potentiometer (temporarily wired to analog input 0) which we plan to use with a motor on the testbench.  This motor is wired to the CANTalon on the testbench, which has a CAN ID of 10.

[Matt S]

Today I worked on adding a command to move the robot a specific distance at a certain speed and direction.  I also added a command for turning to a specific angle.  These will both be used heavily throughout autonomous.  However this has to be changed slightly if we want to be able to move while changing angles.

Tomorrow I plan on adding to the robotbuilder file to get all of the subsystems ready to use.

[Matt S]

Yesterday I worked on finishing the drive distance command, and turn to angle command.  I also added new subsystems and implemented the hardware interfaces for the intake.

Today I added methods to do the all of the intake functions, and added a command to run the intake wheels from the triggers.  The intake subsystem receives the trigger input during the subsystems periodic method, and then executes the command once the trigger is pressed.  I also put a command in place for some of the get cube process, which runs the lower intake command (which is not yet defined), move arm command (which is not yet defined), and intake cube command.  However, this command is still a work in progress, and many of its sub commands still need to worked on. 


All of these changes are within the mes_Intake_branch.  Once these intake functions are completed, we should begin working on aligning the claw with the accelerometer.

[Matt S]

As of today, all of the other software teams have been put on hold to work on Java, so we were able to get a lot done.  All of the current changes are on the master branch.  All of the lower level commands have also been placed into sub packages of the command package.

For the arm, we have begun using PID in order to keep the arm locked in position in order to counter gravity.  Currently, this is done by a software PID, but our plan is to use a hardware PID with the CANTalons.  We also implemented an arm default command for fine-tuning the arm, which was done by incrementing or decrementing this setpoint value.  When testing, this appeared to work as expected, but the PID values will have to be tweaked for the real robot.

For the gripper/wrist, we implemented code to open and close the gripper.  We also added and tested code that prevents it from opening or closing if the corresponding limit switch has been tripped.  We also implemented similar code for raising and lowering wrist, but this has not been tested.

For the intake, we were able to finish the intake position toggling command, but the timeouts for these commands were not working as expected.  We also have implemented the correct voltages for raising and lowering the intake, and also implemented current stalling.  This is the only subsystem that currently uses current stalling, so we should begin to implement this into other places when possible.

For the drivetrain, we finally finished the drive mode toggling.  However, there are a few things I would suggest changing with the current implementation, such as not having the swerve drive object as public, as well as adding back a set mode method.

For autonomous modes, we have implemented mode switching from the dashboard, as well as receiving the scale/switch positions.  These modes are represented by an enum, which we use during the AutoAction command along with the scale/switch positions to figure out where the robot should travel to.  This command then calls the corresponding commands that cause the robot to travel a defined path (not all of these commands have been implemented).