When programming doesn't get enough time

[EmileH]

Originally Posted by cjl2625

Curse those filthy wrench-swinging rivet-popping screw-driving hammer-smashing mechanical barbarians.

Hand over the robot to the programmers!

You must spread some Reputation around before giving it to cjl2625 again.

Most true statement I've read in a while

[R2D2DOC]

Hello,

In sympathy with the programmers, how about this (and check the legality of any of it):
(1) Is wireless flash of the controller available? If so:
(2) Bag the robot with a charged battery.
(3) Put the robot up on blocks.
(4) Depending on what is in the bag, and attached:
(5) Programmers can modify code and wirelessly flash and do limited testing?
(6) Yes electrons are passing though the bag. Yes an electrical change is being made on the robot, but not mechanical.

Just thowing it out there. . . . .

It is human nature to let things slide, especially when the deadline appears far away, and you are not on the tail end of the process. Off season, endeavor to think about scheduling, robot modular design, practice robot, or even partial practice robot that can be controlled and powered. For example, if the mechanical design crew is working on the game manipulator, with a modular design, the programmers can work on chassis control.

Hoping to make the process more effective for as many teams as possible.

[Bongle]

We got around this very effectively this year by taking a test-driven approach.

Split whatever code you're trying to test out into its own class, and have its entire interface with the robot be a single function call. Make sure the controlling code doesn't talk directly with WPILib (or else it ups the complexity of doing your simulated tests) We had something like:

class ArmController
{
public:
  Tick(double currentTime, double armPosition, double* shoulderPower, double* elbowPower);
private:
  PIDController m_myPidController;
  int myCurrentState; // 0 = stowing, 1 = going out, 2 = out, 3 = stowed, etc.
};

Usage in the robot code looks like:

double shoulderPower=0;
double elbowPower=0;
m_armController.Tick(currentTime, m_armPot.Get(), &shoulderPower, &elbowPower);

m_shoulderMotor.set(shoulderPower);
m_elbowMotor.set(elbowPower);

Then, elsewhere (in our case in Visual Studio), write some other code like:

ArmController controller;
double desiredShoulderPower;
double desiredElbowPower;
controller.Tick(0, OUT_POSITION, &desiredShoulderPower, &desiredElbowPower);

assert(desiredShoulderPower == 0); // the arm is out, so we shouldn't be trying to drive it
assert(desiredElbowPower == 0); // the arm is out, so we shouldn't be trying to drive it.

And do that for every other state that the arm might be in. We ended up with 20-30 unique tests for our arm controller, found a _ton_ of subtle bugs (some that we may not have found while doing in-pit testing anyway), and it worked _flawlessly_. We wrote it in the stands at Waterloo while the team was unbagging the robot, and basically didn't even give it a classic on-robot test.

[Drakxii]

Originally Posted by R2D2DOC

Hello,

In sympathy with the programmers, how about this (and check the legality of any of it):
(1) Is wireless flash of the controller available? If so:
(2) Bag the robot with a charged battery.
(3) Put the robot up on blocks.
(4) Depending on what is in the bag, and attached:
(5) Programmers can modify code and wirelessly flash and do limited testing?
(6) Yes electrons are passing though the bag. Yes an electrical change is being made on the robot, but not mechanical.

Just thowing it out there. . . . .

It is human nature to let things slide, especially when the deadline appears far away, and you are not on the tail end of the process. Off season, endeavor to think about scheduling, robot modular design, practice robot, or even partial practice robot that can be controlled and powered. For example, if the mechanical design crew is working on the game manipulator, with a modular design, the programmers can work on chassis control.

Hoping to make the process more effective for as many teams as possible.

This... is a terrible idea. Not only do you run the risk of putting a hole in the bag but you can't really test anything this way. My programmers and I can make any bot WORK in about an hour or two but it takes days of coding AND FIELD testing to make it work RIGHT.

[adciv]

There's a reason we're building two robots now. As programmers, we frequently find flaws mechanical didn't consider. Some require a moderate redesign. e.g. We sheared the rivets again, you need to make this more durable. If you think the programmers are being hard on the robot, you should see what Drive Team does to it...

[Ninjastahr]

Originally Posted by adciv

There's a reason we're building two robots now.

This is a great strategy, and my team was able to get a lot of programming done in build season before the real robot was even finished with just a practice drivetrain and a camera!

EDIT: But sometimes I still wished that the Mechanical people could just hurry up and finish the robot