When programming doesn't get enough time

[liavt]

https://drive.google.com/file/d/0B7l...ew?usp=sharing

[MaestroRoboto]

I know the feeling

https://drive.google.com/file/d/0Bwz...ew?usp=sharing

[Hitchhiker 42]

Best way to avoid this: set a schedule, and keep to it. Something that comes up on our team too. End up doing a lot of the testing during our 6 hour unbag time.

[cjl2625]

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

Hand over the robot to the programmers!

[arc25565]

We were competing in a week 1 regional and the programmers had to do all the code on the plane.

[BrianAtlanta]

Even at work you never get enough time to program. Sales and Managers seem to think that programming is easy. If I hear "I JUST want..." Nothing is ever "JUST"

</rant>
Brian

[Rivet Man]

Originally Posted by cjl2625

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

Hand over the robot to the programmers!

Hi cjl2625,

I noticed you had an issue with people rivet-popping. In particular, you called them barbarians.

While it's true that rivets have been around for quite a long time (archaeological findings date rivet use back to the bronze period) that does not make the people who implement them barbarians. In fact, it typically implies the opposite. Rivets are an extremely useful and lightweight fastener system that have allowed for a number of technological advancements to occur!

Hope this has helped pop your feelings about those of us who use rivets.

Best Regards,
RM

[danieltorres]

Originally Posted by cjl2625

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

Hand over the robot to the programmers!

EXACTLY! Those barbarians are SOO difficult to deal with right?!?

[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.

[Hitchhiker 42]

Originally Posted by BrianAtlanta

Even at work you never get enough time to program. Sales and Managers seem to think that programming is easy. If I hear "I JUST want..." Nothing is ever "JUST"

</rant>
Brian

Just wanted to put this here as it seems fitting:
http://xkcd.com/1425/

[Chris Hibner]

As Bongle said: simulation is everything. We write simulation wrappers for almost every bit of code we do, and test it on a PC before it ever sees the robot.

The key is to structure your code such that it can be executed on a PC - in other words, don't bury calls to the hardware input reading or output setting functions within each code unit. This will allow you to test your code unit off the robot.

[FrankJ]

Every year I tell the programmers they get the robot first. They program it. Then we build it. They have yet to take me up on the offer so they get what they get.

[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.