Author: Fletcher

Attendance

• Fletcher
• Hunter
• Evan

Journal

Tasks

• Unbend the scissor lift frame
• Attach the scissor lift frame
• Find out why the scissor lift frame bent

Reflections

Evan unbent the scissor lift frame.  It was fairly straightforward to fix, though it was decided that we would never want it to happen again.

Then we attached the scissor lift frame back on the robot after it was fixed, we definitely never want this to happen again.

Attendance

• Fletcher

Journal

Tasks

• Get robot
• Set up computer to use RobotC
• Test IR autonomous

What Happened

Fletcher went to Evan’s house and got the robot.  He then went home and installed RobotC on his computer.  He set up a practice field (though it may be low end).

Once all this was done, Fletcher went to the code and made a couple small changes to the IR autonomous, like adding a waitforstart(), and uploaded the program to the robot.  Upon running it on the NXT, it read an error: “IRautonomous2.c Bad State!”

The program failed.  TeleopHR was ran and it worked fine, so Fletcher thought that perhaps it was the fact that he was using a Mac with a Virtual Machine (VM) rather than a PC.  He uploaded a version of TeleopHR that had worked in the past and it read a similar error, except it said TeleopHR.c rather than IRautonomous.c.  This confirms that it was the computer rather than the software that was causing the problem.  He went searching the internet for a solution, but he came upon none.  He went to the RobotC website for help and went on the page explaining how to run RobotC on OS X, and it said that Virtual Box wasn’t supported with their virtual world software, indicating that perhaps they didn’t support Virtual Box too well with RobotC.

Attendance

• Fletcher
• Hunter
• Evan

Journal

Tasks

• Assemble field
• Test New Features on Robot
• Driver Practice
• Autonomous Testing

Reflections

New year’s eve, we built the field in Hunter’s garage so that we could test autonomouses and do driver practice. We found that the rack ends are 7.875″ from a perpendicular on the base board [illustrated]

Once Evan came, we turned the robot on and started driving it.  Once it was verified that everything that had worked worked, Fletcher uploaded some new software to account for the new hardware additions, like the servo that makes the hand go up and down, the fork lift peg, and the new hand.

We turned the TeleOp on, and the robot didn’t move an inch.  Based on past experience, we told Evan to check all wiring on the robot.

All wiring on the robot was checked, even to the point that the entire wiring setup was disassembled.  The robot was still not working.  A new mini-TeleOp was written that only used one motor controller, as one the things thought to be the cause of our problem was the series configuration.  Each time we had things running on the mini-TeleOp, it worked.  We were baffled, why wasn’t our TeleOp working?

Hunter went into the code for TeleOpHR.c (our TeleOp) to comb through and see what was causing the problem.

He found the problem.  It was this:

//the_problem.c
int J2Y2 = joystick.joy2_y2;

This creates a variable J2Ys that holds the current value the joystick is returning, or so we thought. It actually only held the first thing the joystick read when the program is turned on, usually 0.  This is because this function is only called once, since it isn’t a function and rather a variable.  The correct way to do it is this:

//the_solution.c
int J2Y2() { return joystick.joy2_y2; }

This can be called many times, unlike the problem.

After we solved our problems, we shot footage for our Promote award video.