Java Auto addRequirements Chassis Subsystem

Technical Java
1

Hello programmers,

As a beginner, I am creating a very basic autonomous arcade drive with the kit chassis in Java. I have a driveForward command that instructs the bot to move forward at (s) speed for (t) time. This command “should” run multiple times in a sequential command group in autoCommand. However, when the program is deployed to the robot, there is an immediate error and the log prompts me to check line 17 in the driveForward command: addRequirements(m_chassis);

I think that I may be importing the chassis subsystem incorrectly into the driveForward command.

Any ideas? Thanks!

2

Generally, getting help will be easier if you post the full code so we can see the context for your problem.

2 Likes
4
5

Your assignment is reversed here: ArcadeDriveAuto/robot/commands/autoCommand.java at main · mechmustang/ArcadeDriveAuto · GitHub

I understand youre new and still learning, so im going to take this as a teaching moment if thats alright.

Coding conventions are important. The specific convention followed isnt quite as important as being consistent within the project (and especially in a more professional/business setting, among the team). That said, some conventions I recommend following with your FRC code:

  1. All class names (more generically: “types”) should be TitleCase (first letter of each word is capital, all others are lowercase)
  2. All function/method names should be camelCase (same as title case, but first letter is always lowercase)
  3. Class member variables are all camelCase with a m_ prefix (you have a few examples of it in there, so just make sure you’re consistent). [Note: this one I find optional, but it’s what the WPILib code uses, so it’s what most examples show]
  4. Function arguments should all be camelCase
  5. Local variables should all be camelCase
  6. Class member variables should all be accessed via this. (except in a few instances where it may not work, but I don’t expect you’ll find too many of those)
3 Likes
6

If you do # 3, this isn’t necessary (and to a lesser extent, vice-versa). The primary purpose of # 3 is to disambiguate local variables from class member variables such that the programmer is more likely to consistently visually interpret the code in the same way as what the compiler is actually doing. I would argue that one nice thing in Python is that this (called self in Python) is required to be explicit, avoiding this problem entirely.

7

Yes good call. I often do both just to avoid any semblance of ambiguity, but yes youre absolutely right that they’re not both strictly required.

8

Also, you should not be extending SequentialCommandGroup and then creating a new SequentialCommandGroup in the constructor. You don’t do anything with the latter object, so it is just thrown away. You should be using addCommands instead.

If you do things this way, then you don’t need an addRequirements in autoCommand at all, because it inherits the requirements from its sub-commands.

1 Like
9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.