Scenarios for Learning Java
 

Hi guys. I'm posting this thread to ask for some robot scenarios to program. I'm doing this because I'm experienced with Java but have not worked with it in FRC. My team primarily uses LabVIEW, but I would like to learn to work with Java and C++ as well. I may also use some of the scenarios you provide to help teach other programmers from my team who also wish to learn to work with these languages. I'll probably work with the 2013 version of the FRC libraries so I can use jRIO to test.

Edit: when I say scenarios I mean list different actuators, sensors, and functions that the robot would use.

Re: Scenarios for Learning Java
 

I'd say the beat one to start with is write a drive train. And having a complete robot to work with, reprogram the robot in java would be another good tool.

Re: Scenarios for Learning Java
 

Ideas for what your code could control:

1. Drive Code (as notmattlythgoe suggested)
2. Shifting Code
3. Some sort of collector
4. A pneumatic actuator (perhaps an Arm)
5. Autonomous modes - drive forward, 1 ball, 2 ball, 3 ball
6. Kid Mode for Drive Code (for robot demos - pretty much a quick way to set the robot to drive slower so that kids can drive it)
7. Kinect control for Autonomous
8. Compressor status & pressure sensor readouts
9. A shooting mechanism, probably based on whatever your team used this year.

If you can do all of that, you can program most of what a robot might require.

Re: Scenarios for Learning Java
 

Everything said before, and some:

• Reading constants, e.g. for autonomous, without having to redeploy
• Experiment with user interface/debugging tools like SmartDashboard
• On the vision side, you may want to look into OpenCV
• Different base classes - iterative or command-based paradigms

Re: Scenarios for Learning Java
 

You wouldn't have to use Java at all on the robot to use it for the driver's station. There are some pretty nifty things you can do with data from the robot during the build season and during the competition season.

Re: Scenarios for Learning Java
 

Is it alright if I ask how one language can communicate with another directly? I mean, I could make a file of some sort (txt?) and get the data from it, if both languages supported that, but something that would work better in realtime?

Re: Scenarios for Learning Java
 

You can usually use TCP sockets to communicate between devices in general, and pretty much all modern languages support sockets.

Alternatively, you could use an existing protocol written on top of sockets, such as NetworkTables (comes with FRC robots and usable from at least C++ or Java, although there may be a LabVIEW interface as well) or a team's released network communication library (My team, for example, wrote an open source communication framework, although that's only in Java. I'm sure that you can find some others if you look through the code releases from various teams that have been popping up in the various Programming forums here.)

Re: Scenarios for Learning Java
 

A byte is a byte is a byte, regardless of language.

Say you have an array of 14 Floats (have no idea why you'd have 14 of them in FRC). C++ has a way to cast/interpret all 14 floats into an array of bytes. Java has a way to cast/interpret the bytes to Floats. You can do this all yourself (faster to implement from scratch, doesn't depend on 'flavor of the month' frameworks, often easier to increase performance) or use something like Google protobufs (easier to understand and add new features, once you understand the framework).

Some frameworks even support sending a method call with parameters across the socket between multiple languages - such as CORBA and Java RMI. However in FRC this usually isn't necessary. Our messages are is a byte array of (1)An integer which identifies how to decode the byte array (message id that, when converted to hex, usually states what the message is - 0x60B0760 = 'Go Bot Go', i.e. the HOT message) (2) An integer which is the Message length - useful for custom generic messages where the id changes based upon bit flags so that bandwidth can be saved when necessary and (3) the rest of the message. The rest of the message is an array of bytes, and each 'float' or 'int' in the array is always a 4-byte value (i.e. no doubles or longs).

Our team tried the SmartDashboard & NetworkTables in 2012 for a few things, but it wasn't working out for what we wanted. That year and every year since, we have implemented our own network code. From what I hear, it's wonky and was somewhat unreliable (we still don't reliably get a message from the D/S to the robot without killing the robot...) so we won't open-source it. Next year, we have plan to evaluate alternative approaches.