How many days do your programmers get with a fully built robot before stop build day?

[gerthworm]

Our team structure is the same. It's varied year to year, but what I've found from my 6 total years of doing robotics for various organizations: The robot is never truly finished. No matter how good or professional your other teams are, there is always something to be improved. Presuming people are enthusiastic about perfection, getting the robot for some quality software time is pretty hard.

We found two modes of operation were really useful this year:
1) mini-sprints: In parallel, the robot is constructed, and software is written. Major milestones (drivetrain written, manipulator added, etc.) are marked in software version control. As soon as the robot is mostly functional, there is a joint effort where software loads on a new program, does some tests, makes some observations. As soon as software knows what to do, they get off the robot and give mechanical & electrical a time estimate till the next time they need the robot (5 minutes? 15? an hour?). Mechanical/electrical then do whatever tasks they can in that timeframe, and get back out of the way for software to do their next iteration. Working like this allowed us to make lots of small mechanical tweaks that made a big difference at the end of the day.

2) Shift-based work: For longer software projects, such as tuning shooter/intake sequencing or autonomous routines, Software just needs the robot for a long stretch of time with little interference. These things were accomplished "after-hours" - effectively, non-software teams went home to get some sleep, and software came in later to get done what needed to happen. Most mentors stuck around for the whole time, but this allowed the students not to be super burdened. I'm hoping to improve how we organize this this year with better up-to-the-minute communication of schedule, as a mechanical failure has great potential to hose up pre-set meeting plans.

[DonRotolo]

It depends. From -10 to +15. We aim towards the latter, which was the case in 2016. ("Fully-built" is relative. Fully-Functional might be more accurate)

It is always not enough, and we strive always for more

[Wasabi Fan]

I know this is an old(ish) thread, but surprisingly I don't see any mentions of what my team does, which I think it pretty valuable: we write extensive unit tests. All the code from the motor controllers/DIOs upward can run on a development PC, so we can be confident that our code works even if we can't test it. We write tests to test math helpers, individual commands, command chaining, and overall flow, so all we need to do when we get our hands on the robot is make sure that none of the I/Os were swapped or disconnected. Obviously it's best when we get a good chunk of time for real testing and tuning of PID and such, but we make do when we are low on time with the practice bot.

[xjschwen]

We get only a few minutes each build day. This will be normally only 10 minutes or so with maybe 1-2 downloads. As the build team is building a component we are programming it so that we can test both the software and mechanical as early as possible.

It is basically an Agile way of working

We setup a board bot that has the right kind of motor controls and IO.

We set it up on a rolling cart and are able to push it/spin it for work with gyro control.

For the early season work this is actually better than having a real bot because it does not drive away and we do not bend/burn anything.

As we get closer to the end of build season we took one day about 5 hours to fully tune speeds, and sensors etc with just the programming team. 2016 was the first year this was done.


This method of working also ensures that we have a minimally complete bot early in the season. Since the Mechanical and the Software have to function as a system, having one "Complete" without the other is a waste of time.

As for the hours on a complete robot... that would be 0 hours. We were still bolting things to the bot at competition and our climbing winch was not functionally complete enough to test until the last few matches at States.

Jeff

[Chris Hibner]

Originally Posted by Wasabi Fan

I know this is an old(ish) thread, but surprisingly I don't see any mentions of what my team does,...

Then you didn't read very carefully: https://www.chiefdelphi.com/forums/s...9&postcount=14

(Sorry - I couldn't help but be a smart @$!)

But you are right - PC testing is the way to go.

[Brian Michell]

Since the beginning of our team, we never got a day with a fully built bot before bag 'n tag. We did however, build a second bot that was not identical, but close enough to make sure we had a decent, reliable autonomous and robust control system.

[adciv]

We've gotten better about getting the robot to the programmers before bag n tag. But we're still doing the 2nd bot for auto and control. A chunk of what we do would not be possible without the 2nd robot to debug and develop code on.

[Mitchell C]

Our build team gives the programmers little to no time with the robot. We usually get around 20 mins of the Thursday/Friday of comp depending on how the robot is coming along.

[Hitchhiker 42]

This year, our programmers had much more time than previous years. The programmers received the robot Thur/Fri before bag & tag. Then, we attended Suffield Shakedown on Sat, and Mon/Tue were a little bit of a scurry to quickly switch a component from a motor (window motors are bad for high loads we found) to pneumatics. Overall, I was mostly satisfied with the time we got.

[Cothron Theiss]

Originally Posted by Hitchhiker 42

(window motors are bad for high loads we found)

After putting one or more window motors on all four robots I've helped my team build, I can assert that window motors are bad for just about everything.

[GeeTwo]

Originally Posted by Cothron Theiss

After putting one or more window motors on all four robots I've helped my team build, I can assert that window motors are bad for just about everything.

I have 4 18-year old window motors and 4 11 year old window motors that have done a great job of occasionally raising and lowering car windows and are still going strong. On FRC robots, we have mixed experience: When we have just tossed them at a problem, we've had the worm gearbox fly apart faster than the arm it was driving (trying to lower the bridge in Rebound Rumble). When we've done the math and used them in situations within their torque and speed capabilities (e.g. raising and lowering our rung deflector for Ultimate Ascent), they have performed well. If it's too big a job for a servo, and a BAG motor would require a third VP stage or two high-reduction VP stages, consider the humble worm-geared window motor in your kit of parts.