frc1418 / noboty

:robot: Our defensive practice bot.

Noboty Practice Bot Code

Code for the 2018 practice bot

Noboty?

Noboty is a play on words from Team 118's Everybot. We called it this because noboty will use it.

Controls

We used a one-joystick control system for sake of convenience. Moving the joystick on the Y axis moves the robot forwards or backwards, and the X axis causes it to rotate.

Correcting Joystick Axis

The joystick we used is unique in that the origin, (0,0), is the bottom right of the joystick, rather than the center. To account for this, we had to make some corrections to the joystick input.

Sarah mode

This mode cuts the speed of the robot in half, for precision movement in confined areas as well as a simple safety precaution for inexperienced drivers. Sarah mode was created when Sarah, a member of our team, smashed the robot into a wall at full speed. It is activated by pressing the red button on the joystick.

Authors

See contributors

Licensing

This software is protected under the MIT License.

noboty's Issues

Add `.pytest_cache` to gitignore

Rename robot_drive to train or similar

Take a look at how we do it in 2018-robot.

Add requirements.txt

Self-explanatory. You can see 2018-robot for an example.

Allow toggling easily between different joystick layouts

Sometimes this robot uses a single joystick, sometimes a single aviator joystick with odd axes, and sometimes two joysticks. We should support a button to easily toggle between these options.

Note that we will have to be careful with the whole aviator joystick thing... what's (0,0) on that would make the robot move under another layout.

Use single joystick for control

We'd like to use this bot for defensive testing, and we're planning on controlling it with a single joystick (the black Aviator joystick). Please modify the drive code to use both axes of one joystick (Y for advancement and X for rotation).

RobotDrive is deprecated

RobotDrive, which we're currently using, is deprecated. We should replace it with another type of drive system. DifferentalDrive, which we use on the competition robot, is the best option. There's also KilloughDrive and MecanumDrive, but those imply specific drivetrain layouts which we're not using. Read up on all of them on the WPILib documentation anyway.

• http://robotpy.readthedocs.io/projects/wpilib/en/stable/wpilib.drive/DifferentialDrive.html
• http://robotpy.readthedocs.io/projects/wpilib/en/stable/wpilib.drive/KilloughDrive.html
• http://robotpy.readthedocs.io/projects/wpilib/en/stable/wpilib.drive/MecanumDrive.html

Use nice PWM port layout

Previously we had a nice binary layout for the PWM ports for the drivetrain Victors. Now they're assigned somewhat arbitrarily. Would be nice to move them back to where they were before. Should be quite an easy task.

`test.sh` must be executable.

To be run as ./test.sh, you'll need to use chmod to make the script executable. Explanation

Write README

We'll need sections explaining each of the following topics:

• The origin of the robot's name
• Explanation of one-joystick control
• Explanation of our crown jewel, Sarah Mode™

There will probably be a few other things to write about.

Test code on rebuilt chassis

They may have changed some electronics layout. We will need to change some values if so.

Set up basic motion profiling autonomous

Add button for switching between one- and two-joystick control

Add git hooks

Take a look at how we do it in 2018-robot.

Start checking E701 with pycodestyle again in tests

pycodestyle's method of checking whether policy E701 from PEP8 was violated had issues with type annotations, which were relatively new last season. They're no longer new, so I think it's okay to edit test.sh to stop ignoring E701.

Add all tests

Take a look at how we do it in 2018-robot.

Turn on Travis CI

We use a helpful web application called Travis CI (Continuous Integration) to automatically test changes to our code. This is very helpful during competition season: if someone makes a pull request (request to change the code) that would cause the robot to crash, there will be a helpful red X next to the PR and the offending commit (code update) to warn us that maybe it shouldn't be applied yet and further changes are necessary before we can merge (approve) the PR.

You can look at the way we do this in 2018-robot for an example; it should work pretty similarly here. You will need to turn on Travis for this repository; Google how to set up Travis CI for instructions on this.