I’m David and I am part of Team 4780 and we are a second year team that is switching from LabVIEW to Java. I’m currently having a problem programming autonomous. I have no idea how turn the robot. I know you can turn it by changing the curve value, but can I turn it stationary (pivot). Or even the ratios for different turns at 1/2 speed for whatever amount of time.
Is your robot using differential steering? If so, to turn in place you would simply set one side of your drivetrain to a particular speed and the other to the opposite of that. What is your chassis like (and what is this curve value)?
The drive (ie ratio curve) method in wpilib will do a turn in place if you set curve to 1 or -1. The outputMagnitude will determine how fast it will turn in place.
I’ve always found it simpler to use arcadeDrive or tankDrive in autonomous, and haven’t really used the ratio curve method. I recommend using whichever one you used in LabVIEW.
I’m a little lost because this is my first year programming. I’m starting from scratch because our old programmer forgot the password and I had to reimage the our computer so I don’t have any of our previous data.
By differential steering, do you mean chassis.drive(ROBOT_TASK_PRIORITY, ROBOT_TASK_PRIORITY);?
So if I were to use the curve, it only works at 1.0 or -1.0.
Also I can just use arcade/tank drive to turn? Can you possibly explain how?
Thank you for the help guys.
Also, I have our robot set for arcade drive in teleop and fowards and backwards are fine but the left and right are flipped. Basically up is foward, back is backwards, left is right, and right is left. I can’t remember if our robot was like that last year. Is there any way to fix that.
Basically, to use arcade drive during autonomous, create a method in your chassis subsystem that takes in 2 parameters: double speed, double turnRate. The method only needs to contain 1 line: chassis.arcadeDrive(speed, turnRate); From there, just put it into a command like normal, feeding it the speed and turnRate values. To turn in place, just feed it (0, 1) or (0, -1). A similar process applies to tankDrive, only now your parameters are double leftSpeed, double rightSpeed, your line of code is chassis.tankDrive(leftSpeed, rightSpeed); and to turn in place you feed it (1, -1) or (-1, 1).
About the teleop question: are you using 1 joystick, 2 joysticks, or 1 gamepad to drive (only to control the drivetrain, don’t include what your operator uses). And could you post the line of code that controls the drivetrain (chassis.arcadeDrive(…)
I’m using one joystick. And the code line is
public void operatorControl() {
chassis.setSafetyEnabled(true);
while (isOperatorControl() && isEnabled())
chassis.arcadeDrive(rightStick);
Timer.delay(0.01);
}Oh, you are using the simple robot template. I recommend that you look into the command based robot template. Unless your team has a REALLY simple robot, the simple robot template is going to get really crowded and hard to read really fast. (Hence the name simple robot template).
Anyways… the solution might be a bit more complicated than this; I will check when I get home. Replace chassis.arcadeDrive(rightStick); with chassis.arcadeDrive(rightStick.getY(), - rightStick.getX()); That should invert the turn values.
What do you mean by command based robot template? And I’ll let you know if that fixed once I get to school tomorrow.
I checked, this solution should work fine. Incase you didn’t catch it, I made a small syntax error; the line of code should be chassis.arcadeDrive(rightStick.getY(), - rightStick.getX());
Basically, when you create a new project for a robot, you have 4 types of templates to choose from. The one that you are using (or at least I think you are using) is called SimpleRobotTemplate. In it, you are just given 1 page with places to put your code for autonomous, operatorControl, disabled, etc. It is very hard to properly organize large ammounts of code inside of this template. That is why the CommandBasedRobotTemplate exists to divide up your code into sections. It is based off of 3 main parts: subsystems, commands, and the OI. It is had to explain, but basically you create a subsystem in code for each subsystem on your robot. This subsystem contains information about that part of the robot. You then create commands for everything that you want your robot to be able to do. The commands use the subsystems to figure out how to do what they need to do. The OI (operator interface) simply figures out “if the driver does X, I should start running command Y”.
Ok I know what you’re talking about now, that makes sense. Well I’ll let you know how it works out.
So I’m looking into the command based robot template along with the wpilib guide online and I’m a little bit lost. I get what it says I just don’t know where to put everything. Would you or anyone else be able to send me a sample so I can better understand?
There’s a pretty good set of tutorials/guides here.
Navigate through the links on the left hand side for different topics.
You could also use the robotbuilder tool to generate complete command based robot projects.
You could probably get a good sample by clicking on new project in NetBeans and looking in the samples folder.
However, IMHO the best way to learn are the videos on this channel. I have referred people to this channel many times before, and I will keep doing it, because I think it is an amazing resource that we have. You will notice that there are 2 playlists, one that uses robotbuilder and one that doesn’t. You can check out otherguy’s link to see if it’s something that you want to use. FWIW, I highly recommend robotbuilder.
Ok thanks guys I’ll try these out. I’ll let you guys know if I have any more problems.
If you use the Command base and/or RobotBuilder, and you decide that you really like it and get the hang of it, you could take a look at my thread here(http://www.chiefdelphi.com/forums/showthread.php?t=118745) about autonomous. I made a couple of classes you can extend to set up your autonomous so that it’s really easy to change.
Another question, this time about PIDs. I somewhat understand what they are, but do I need them? I know that they hook up to the analog breakout board. If so where can I get some? Would you use them for autonomous and for like setting an angle for a shooter?
I think you have a few things confused. PID stands for Proportional Integral Derivative. It is a type closed loop control algorithm. This algorithm is typically implemented in software, so it wouldn’t be an analog device.
What I think you’re referring to though, as far as sensors go, are encoders. These can be digital or analog components. Basically what they are there for is to feed information back in to your software (like the speed or rotational position of a wheel, or setting the angle of a shooter mechanism). Adding these sensors can allow the robot’s code to compensate for real world effects on a commanded output. They can be particularly helpful in autonomous mode. They can allow you to target specific travel speeds or distances on your drivetrain, target specific wheel speeds on your shooter, etc. They’re also helpful in teleoperated mode as it can allow single button presses to set repeatable and reliable positions/speeds on your devices, or to verify speeds/positions are within an acceptable range (like making sure your shooter wheel is above xxx RPM before shooting a disc).
To answer your question about whether or not you need them… It really depends on your design. They may not be particularly helpful on pneumatically operated mechanisms since their positions are usually pretty reliably set. Mechanisms which are motor driven can often be made more reliable or at least easier to operate with the help of sensors and some code.
As an exercise, write an autonomous mode that attempts to drive in a square, that ends in the same position that it started. All you have to do is drive straight and make a few 90 degree turns. Sounds simple enough. If you run that code repeatedly though, you will see how much variability there is in your final position. The differences in your battery voltage, wheel slippage, frictional forces at the wheels, variability in code timing between runs will all contribute to a pretty lackluster positional accuracy. Adding in sensors can allow your code to adjust for these inevitably inconsistent factors.
I would highly suggest playing around with some code that uses an encoder on the drivetrain, as well as the gyro sensor. Both come in the kit of parts, so you should have them on hand from last year’s competition. Code as simple as: drive at set voltage until the encoder moves xxx", or turn at some set voltage until the gyro reaches xxx degrees, will perform significantly better than a time based algorithm. No speed/position controllers required, so it’s pretty simple to write and is quite a powerful tool to have in your back pocket.
Things to read up on:
This article gives a pretty good overview of what a PID controller does and why: PID Without a PHD
CD User Ether has a good paper on how to set up a bang bang speed controller (simple alternative to using PID). This would be best suited for a shooter wheel, not drivetrain.
Wiki page on Encoders