This year, I have to code the programs for my robotics team in Java instead of RobotC, so it can work with Androids. For the autonomous code, I want to make a basic template where any member of the team can create different programs through a list. I have tried to look up how to work with lists, but I haven't found anything useful. This is the code I would do in TI-BASIC
Code:
How would this code translate to Java? I mainly need to know how to set the series of numbers to a list and how to find how long a list is.

This is an interesting solution to the problem. Although you could do it this way, I would strongly recommend using methods to perform each of the actions - like you would do with a functions in RobotC.

If you still want to do it this way, Java uses arrays just like RobotC. You can begin by defining auto with an int array literal:

Code:

You can then use a for each loop to loop through each element of the array, and a switch statement to perform the desired actions:

Code:


If you have any questions, I know both Java and RobotC pretty well.

I have never done anything more complicated than If statements in RobotC, so what do you mean by methods?

A method is, in essence, a function contained within a class definition. e.g.


Code:


Also, depending on your use case, you may want an actual List, rather than an array. In that case you should look at the Javadocs for the java.util package, which has several implementations of List.

Re: jonbush's post: Just to make sure that you learn optimal form, magic numbers are to be avoided as much as possible. You'd want to define some constants like COMMAND_LEFT, COMMAND_RIGHT, COMMAND_FWD, etc, or even better, use an enumeration:
Code:

I believe the for(int action : auto) in Kerm's post is misplaced. You would need to have another method that iterates through the list of commands and calls performAction() for each. If you are using any sensors, it may also be useful to create other classes to handle sensor input.

Thanks for catching that; I corrected my post. I do think a vector/array type would probably better for this than a static int[] array, as elfprince mentioned. Also Runer112 suggested on IRC that making the enumeration part of the Robot class and attaching a method to each enumeration item would be a more Java-y, OOPy solution, and I agree, but that approach might be slightly out of scope for a Javascript beginner.

Yes, that would be a better solution. Overall, if you are using methods, none of this is really necessary because you could just write out the method names in the order you want to call them. This would also allow for easily passing different parameters to methods. In many ways, the current solution is just making things more complicated than they need to be.

I would tend to agree with this. Instead of defining an enum, an array, and iterating through that to call methods, you could call the methods directly:


Code:

Is this FRC or FTC? FRC libraries have an easier way to do things with the Command Based template, which is much more powerful in the long run, anyways.

EDIT:
@FrozenFire also RobotBuilder and such.
@Everyone Else: your code is great for one of the two options for FRC programming, the event-based one, but as I said, the command-based option is the better choice, and you have to do things a bit differently.

Thanks for all of the responses.

I'm doing this for FTC, so I don't think we have those libraries.

I guess I could try to set up separate OP mode classes for each motion of the robot (If I understand you guys correctly), but then I think it would be easier just to copy and paste the motorPower command, since that's the only thing the classes are going to consist of.

I don't really mind how unoptimized it is, I just want it to work and be easy to understand and create, and be easier to modify and have many separate programs than just copying what each motor does and how long to wait over and over.

I don't think you really need to create a separate class for each action. You can probably create methods using the motorPower command and then call those. The methods could be useful for more complicated actions like turning. If you are setting the power for multiple motors it can also be very redundant and annoying having to put motorPower four times every time you want to change the speed. If you create methods for the different kinds of movements, you can more easily create functional autonomous programs.

This was done with RobotC, but it still used many functions to handle the all of the different sensor inputs and motor commands:



EDIT: I haven't done this, but another interesting approach to autonomous development would be to log all of the inputs from a human controlled run, and then read the file back during the autonomous mode to simulate the same inputs. If you are using sensors, this obviously wouldn't be useful for everything, but it might be cool to try.

Our robot will only be using 2 motors to drive, but I see what you're saying. I won't be able to test anything though until Wednesday at our next meeting. Until then I'll try to learn some more Java so I can see the purpose of all of the example codes.

Doing a human controlled run does sound interesting, but I think it's currently above my level

Also, do you know why our motors a have an all or nothing response? Anything between 0 and 1 the motors go at full power one way, and between 0 and -1 they go the other way at full power. We have the variable that the motor power is being set to being displayed on the phone, so we know it is being set at the decimals between -1 and 1 depending on the joystick position. Additionally, if we quickly switch the joystick from up to down or vise versa, the motor can continue to go in the same direction, and a random amount of time later (usually between 1 and 3 seconds) the motor finally updates and goes in the right direction. Are these coding issues or motor issues?

This sounds like a coding issue. Perhaps you could put your code into Pastebin and post a link so we could look over it. Make sure you are keeping track of this mentoring in your engineering notebook.

Unfortunately I won't be able to have access to the actual code that we have until Wednesday, but here is what we have the code doing (Leaving technical stuff out):
Code:

I found this rather primitive implementation of a Mecanum drive algorithm that you may want to take a look at: http://ftckey.com/programming/tele-op/. Although it isn't the same drive type, the general principles behind reading the joystick and setting the power should be the same.

If this doesn't fix your problem, it may be related to having a PID controller active with no encoder input. If you have PID control enabled for your motors and do not have encoders, the controller will ramp the power to 100% because it thinks that the target speed has not been reached.

This is the code that we are using for teleop. We got the code from some other source, so I made the parts that I think are unneeded into comments.

Code:

This method can be rewritten to be a bit more efficient, imo. Also instead of an indexed array, I suggest you use a quadratic function. If you still want the index, you should instantiate the variable outside the method, so you only instantiate once instead of every loop.

Here's how I would write the code:

Code:


If you want the index you have, here's how I'd rewrite it for efficiency:

Code:

That was in the original code that we are using and making modifications on. I didn't really see a point in that part of the code either, so I made it a comment in case we did end up needing it later. I think a function would be better too, but I'm just leaving it as linear for now until we can get the motors working not all-or-nothing. This is the code without the comments:
Code:

Okay, in FRC, you control motors via motor controllers. Are you doing that? If so, there's the DcMotorController class that you should look in to (just read stuff on the FTC API. It's not too different).

EDIT: the DcMotorController's setMotorPowerFloat(int motor) method could be of use.

EDIT 2: or DcMotor's setPowerFloat() method