We have been trying to get our robot to track the high goal target but it just won’t… we have the limelight mounted on our bot, wired correctly, have interacted with it on the web interface, adjusted the thresholding and such, and just generally followed the documentation as best as we can.
We have no programming mentor so me and another kid are trying to figure this out on our own and it’s not working. I feel like we are missing something simple/obvious but maybe not (idk). We are trying to have it setup so that we press a button and the robot will try to align the limelight’s crosshair to the center of the target.
we pressed the button while the robot was misaligned to the target (we could see the target through the limelight via the web interface) and the robot didn’t even try to move.
Would someone look at our code and see if you can find anything? Thanks
I noticed in your Robot::TeleopPeriodic() (Robot.cpp Line 59) that you call userControl() then arcade_drive().
Your userControl later calls either limeLight() or arcade_drive() base on whether raw button 1 is pressed. this leads me to believe that when you press this button, your robot code is trying to call these actions in rapid succession. Removing the arcade_drive() (Robot.cpp Line 61) should allow for either arcade_drive() or limeLight() to be called.
Other general coding suggestions
Here are a few other things that I believe could improve your code:
Naming Conventions
I noticed multiple variables and methods being named in different ways. This can become cumbersome to read. The two big things I see is the lack of camelCase and not having methods be verbs.
Camel Case is the act of naming methods and variables with the first word lowercase, and every sub-sequential word being uppercased.
For Example:
int motorID
double numOfDogs
setPower()
spinUpFlyWheel
Consistency is easier to read.
You also seem to have the tendency to not name methods as verbs. We make methods verbs so that they read more like english sentences when we code. For examples, in your code, you have a method called limeLight(). This give me no indication of what it does. driveByLimeLight() might be a more appropriate name.
Here is a good article to read about java naming conventions. Many of this is similar to C++ conventions.
Better Architecture
I highly suggest looking into the WPILIB command based architecture. I believe this would help you organize your code better. It structures the code into subsystems and commands. The subsystems are groups of objects (sensors/Motors/ cameras) that need to work together for a specific task. Examples of subsystems would be Intakes, Shooters, Elevators, and Drivetrains. These subsystems are then used by commands to execute certain robot actions. No two commands can use the same subsystem at the same time, so you don’t have to worry about two areas of the robot fighting for control.
If you (or anyone else) would like help setting this up, feel free to asked!
I think the positive tx should be adding min_command - not subtracting?
Also, try setting min_command higher (probably 0.1 to 0.2, depending on size of your robot). Raise it until you get cycling back and forth on small errors, then back it off.
By way of quick readthrough, I think UnofficialForth hit the nail on the head. You are always calling arcade_drive() in your TeleopPeriodic even if Limelight() runs within userControl() and this means the call to arcade_drive on line 61 of Robot.cpp would likely be overriding anything it tries to do in the userControl()->limelight() function when button 1 is pressed.
Also I can confirm that if you copied the C++ example from the limelight website then as chesterm said:
That is probably correct, we found that the official limelight example for C++ seems to be backwards for adding/substracting the min_command amount and we had to flip that to get ours working well. We also had to play a lot with the Kp and min_command values to get to something that would actually move our drivetrain, went through that confusing time of thinking “we’re pressing the button, the robot should be moving” but our min and kp values as-copied from the example were too small to get our drivetrain to actually go.
Thank you all for the help! Removing the extra call for arcadeDrive definitely fixed the issue and the robot actually tries to do something when we press the button.
@chesterm, that makes sense. When we pressed the limelight button, the robot did some pretty crazy moves, none of which were in the right direction. We will have to fix that later and do some tuning.