Programming queries?

[paulcd2000]

This is actually more of a general team strategy thing. When does your team program? At all? First thing? Last weekend of build? Build windows? how many programmers do you have? Etc. Etc.

[Alan Anderson]

We program pretty much whenever it's legal to do so. There's a flurry of coding early on as we put together the structure to control what the concept is supposed to do, then a slower pace of changes to adjust to mutating designs and operator console decisions, followed by a bunch of tweaking as the robot hardware gets to the point of being controlled, and finally a few days of frantic automode programming.

This year our team has the software mentor (me), one main student programmer, and three other interested students who sometimes sit in on programming sessions.

[Shinigami2057]

Originally Posted by Alan Anderson

We program pretty much whenever it's legal to do so. There's a flurry of coding early on as we put together the structure to control what the concept is supposed to do, then a slower pace of changes to adjust to mutating designs and operator console decisions, followed by a bunch of tweaking as the robot hardware gets to the point of being controlled, and finally a few days of frantic automode programming.

This year our team has the software mentor (me), one main student programmer, and three other interested students who sometimes sit in on programming sessions.

This basically exactly what we do. While in the design phases, we code up a general implementation of how we think the interface should flow (mainly to save time later and also to show new programmers how things work). Later, as the bot is being built and we get access to it, we tweak and refactor code to model the changes in the design and rectify any mistakes we made in the preliminary implementation.

[kitscuzz]

I can't really vote on any of those. We code as soon as the robot is built enough to know what to code, but so often the development turns out to be based around a figure-it-out-as-we-go mentality, that we really don't know what we're getting until it's on there.

And then it's code-binges all the way to shipping time!

Part of what makes it so difficult is the fact that we don't know something works until we code it, and we can't code it until it's built. And so it gets built badly, we code it to go, break it, then build something else.

But we figure out how all the sensors work, and get general frameworks setup in the early build season, then we slowly stick in what we need as we see we need it.

[jesusescobar]

well we program or are programming at the last minute the full code

[Tureyhall]

We've got 2 programmers, one programmer-in-training, and one programming mentor. One of our programmer focuses on camera and auto programming, the other one (me) on controls and general stuff.


I feel bad for our programmer-in-training; he'll be the only programmer on our team of three (Driver, Programmer, Builder/Team Leader) next year.

[DonRotolo]

We start programming as soon as we can. We start with the basics - getting the wheels to spin - then start on the hard stuff for autonomous and such, and as the design matures we add the rest.

We use a previous year's robot for development. Reconfigure the chassis to be similar to the current design, then add 'test' sensors and mechanisms (sometimes made from cardboard, wood, etc...)

By the time week 4 is here, we can test some of the code in the production bot. It's (both the bot and the code) not complete (even today!) but those few hours a week for validation serve their purpose.

Don

[benhulett]

We do the following in our code process (for this year):

1.) early stage, we make sure wheels will move the way we want to control them
2.) after we see the robot moving, we tweak the code to make sure the way it drives won't damage things
3.) we start coding the controller buttons to get ready for any other motors we'll need to get running
4.) depending on our robot design, we'll split up tasks and use the FRC's from last year to double coding productivity
5.) our lead programmer starts on autonomous, and we begin tweaking our current code and coding smaller things
6.) rush time, autonomous becomes last priority, and we make sure our code is working correctly and integrated with everything else to have a "master code workspace", and we try and make things more user friendly and automatic rather than putting all the pressure on the driver.