Team 589's Code On Line:

[davidthefat]

http://code.google.com/p/cvhs-589-robotics-2011/

Code is still work in progress; I need to work on camera, autonomy and the arm code. I might not even do camera at all unless someone specifically tells me to do it. My current goal is to get the autonomous mode working and Andre will be working on the arm.


Anyone like the way we set up the code? It is aimed to preserve the programming team. All the programmers are either Juniors are Seniors. I am currently a Junior. I wanted to make the code as reusable and expandable as possible. That is why the code is in Java, not C++. I would have loved it if it was in C++, but for the sake of simplicity for the other members, I had to compromise.

Apparently Andre does not like my coding style at all; anything you see that is not good?

Edit: the test code is run by the main as of right now. Change it to runTeleop

[lynca]

Looks good, thanks for sharing.

Google code & svn is a great way for teams to keep track of their files.

[MagiChau]

Just skimmed the code you guys had. I kind of don't get why you gave your camera the type Image. The image if I am interpeting it correctly deals with all the image processing from the camera and not with the actual camera.
The AxisCamera class is the type of the camera object. It must be started by using its method getInstance() probably best in RobotInit() in the main class

Might be irrevelent now since the code has last been updated a week ago.

[davidthefat]

Originally Posted by ZonChau

Just skimmed the code you guys had. I kind of don't get why you gave your camera the type Image. The image if I am interpeting it correctly deals with all the image processing from the camera and not with the actual camera.
The AxisCamera class is the type of the camera object. It must be started by using its method getInstance() probably best in RobotInit() in the main class

Might be irrevelent now since the code has last been updated a week ago.

I just constructed any image and camera like the 2nd week of build season as a place setter. I haven't touched it ever since.

[demosthenes2k8]

I just skimmed through it, and, if I may be blunt, it would definitely not survive a code review by my team's mentors. One thing that I noticed is that many of the variable names don't really describe what they ARE. For example, in ArcadeDriveCalculation.java:42, the line

mY = cube(Y) / 8 * 2;

tells me absolutely nothing. Modified Y? And what are m1 and m2? Are they the values to be sent to the motors, or the motors themselves, etc. Because we do something similar in our own code, except squaring and not cubing, I am familiar with the cube() part. However, the numbers 8 and 2 mean nothing to me. Are they for tuning the joystick values? And why are they two constants, if they can be simplified? Why not just say /4? (Which still means nothing to me.) Also, just a warning, the logic on line 45 seems strange, and m1 and m2 are identical, so you can use only one variable for that part.

Suggestion: Simplify your while loop on CVEncoder.java:29. You can do it with a simple

for(int i=1;i<numOfEncoders;i+=2) {
spin[i] = new Encoder(i,i+1);
}

and save yourself both some unnecessarily obfuscated code, and some space.

There are tons of magic numbers in your code, which refers back to my first paragraph. If you DO use a magic number, you might want to either make it a named constant for legibility and ease of changing, or at least leave comments saying what they are and what they are for, so it makes it easier to "preserve the programming team" when students next year look at it and wonder why a certain number is so crucial. (My team had to look up pi/128 today, and made sure to comment exactly why and how they got that value.)

The naming, "Actuate Calculate Perceive" DOES say what those groups do, and it may just be my unfamiliarity with Java talking, but it seems kind of unneeded. Why not just say "Outputs Logic Inputs"? Or even (pardon my Java inexperience here), why do you need to have them all separated like that? Since you most likely won't have two classes with the same name, why not just put them all in the same folder?

Also, side question, DataStructure only has support for one joystick. Is your team planning to add a second joystick? If not, what are your plans for the second driver?

[sjspry]

Your use of one large class to hold all your robots data is kind of interesting. What made you choose this? The only wrapping I did was when I made my variable-modifying code so I could receive automatic updates.

It's important to comment your code, but I would say the ArcadeDrive is a good example of an exception. It's one of those things you accept it works, and look it up if you want to know about it. If something like CVEncoder hadn't had at least some comments (it looks decent as of now), that might have been a problem.

Could use some more linebreaks, though