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

[Team34Guy]

That's a good one......programmers getting a fully built robot. lolz

Seriously, much like some of the other teams have noted, we usually have code and test it on older bots(or the secondary bot if it's ready). This set up has worked for us. Our build and programming teams work real well with each other and we often times stop build and load new code to check out things as we go.

[maxnz]

I can't speak for other years, but I think this year was the best year for the programming team (for multiple reasons).

We got a spare control system through FIRST Choice and Andymark, and let our programming team use those on a dummy board. They actually used the board from last year's robot to program it in Java (while we used the new one to program in LabView, the language we have used for multiple years). Once the robot was ready for the electrical components, we disassembled the Java board and decided to use Java for the robot. The LabView board was repurposed for Java, and the team kept working. Once the robot was completely finished (last weekend of build), they just needed to check some values for the potentiometer that was used for our arm. We didn't have anything too complex (like vision tracking), only the potentiometer. And they only needed to read the values on the smart dashboard while we were practicing driving to get their readings.

[sraque]

We typically have 3-5 days before bag day where the robot is essentially complete. We have an open house the Sunday before bag day for sponsors, parents, and community so it needs to be working. Those days are used for overall system testing, not just software. Some things we do starting from the first week of build to be prepared are:

1. We develop and configuration manage an Interface Control Document (ICD) covering all I/O ports and operator controls during the design.
2. We develop and configuration manage a set of use cases with the drive team and system designers so everyone is clear on how the robot is intended to function and what the operator controls do.
3. We have a spare control system that is used as a test rig. It is equipped with sensors and motor controllers to aid in verifying the software. Some sensors are replaced by potentiometers and limit switches so we can simulate certain parts of the behavior. Sometimes we have spare motors on there too if that helps debug certain behaviors. This test rig is also mountable on several old drive systems (common bolt pattern with wing nuts) so we can do some drive testing
4. Our first code release is "test code" that is used to test each individual actuator as the robot is being built. The controls for test code are usually different than the operational controls because they are focused on moving only one actuator at a time and under risky conditions (like checking motor polarity, seeing there is no mechanical binding, etc.). This verifies ICD compliance and helps debug mechanical issues in a controlled fashion.
5. We have a practice robot we call "Beta".

We still have huge challenges getting time for closed-loop control tuning. The practice robot never behaves quite the same way.

[Ky0t3]

On our team the programmer actually is coding throughout and will upload periodically to the bot to test it works correctly, like if we just finished a mechanism that we are gonna use. We will all stop building while he's uploading and then watch to see if it works and critique the way it's controlled or the way it functions. By the time we get to stop build day out coding will have been done for a while, even if the bot needs a few more things.

Sent from my LG-H900 using Tapatalk

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

[BDRessler]

My Team Allocates two weeks, but I honestly was testing my code for the first time at our first regional this year. This year is a bad example though because we had a lot of issues with ordering parts and sending them off to be machined. In a normal year I should get approximately four days.

[Max Boord]

Due to our odd meting schedule of 1 day a week, 1065 does things a little unconventionally. We set out our goal for the day I.E build the intake or build the drive base and when that is finished (generally around 4pm) the robot is handed over to the programmers to test the new code they developed for the added component. Then whenever they are satisfied or around 7pm ish we pack it up and head home for the week.

[Jonny_Jee]

during my time on the team, we gave our programmers the last five days of week five to program the robot + auto. more often then not they would complete their goals early which gave us plenty of time for driver practice, durability testing, efficiency revisions, bumpers, etc.

[Cothron Theiss]

We didn't exactly set out at the beginning of the season to do this, but we actually let the driver/programmer drive almost every build session we had this season (once we had an operational chassis). Each night, one mentor (a few would rotate out so as to lessen mentor burnout), me, the driver, and one of three other build members would stay from 30 minutes to an hour after everyone else left to test code and get in driver practice. If a sub-assembly wasn't operational, it was either removed temporarily or strapped down so we could drive. All season long, our programming mentor worked on vision code for a low-goal autonomous, but it never got close enough to completion to try out on the robot. Other than that, all of our code was pretty battle tested by the time we bagged.

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