Value and Purpose of Default Code

[apalrd]

A question came up in this thread about the value and purpose of default code. Since this discussion is off-topic there, I have created this new thread to discuss.

I'll start by linking the Vex Cortex users guide, which contains the Cortex default code mappings on pages 6 and 7. The Cortex offers what I believe to be the model that should be emulated - It provides enough basic functionality to drive all motors from joysticks, allows both tank and arcade drive, and limit switches.

It is similar to the default code provided with the IFI control system, which also included mapping of relays to buttons and compressor control. I believe that this sort of 'minimum functionality' should be included in default code, with both compiled code as part of the image and source provided with all three languages. While it would be possible as a community to write this, it would be much better if it was provided in the development environment and base images as an example or starting point, since the VAST majority of teams would benefit from a working starting point when writing their own code.

With the Vex system (and IFI control system), the default code is extremely valuable to teams, both teams who lack the programming skill (although the additional time and smaller scale of Vex makes it arguably easy to learn with less risk), and for testing and development. The ability to test functionality and drive a robot both before the software is done and if there are software issues is a huge benefit which should not be underestimated.


What are your opinions and thoughts? I provided some similar functionality with the PalLib default code, but I can't promise support, and it uses a nonstandard library.

[apples000]

Roughly half the teams that I see at competition use software that has tank/arcade drive, buttons to toggle relays, and a joystick axis that corresponds directly to a motor set command. Most of the teams that do this, come up with very poorly written solutions full of race conditions, and other inefficiencies. Some people say that giving example code would ruin the learning experience for the teams, but in my opinion, working with well written code and doing things the right way is MUCH more valuable than making your robot work through poorly written software. Also, the more advanced teams are given the command based framework to write Java/C++ software. These teams don't have to learn about complicating concepts related to threading, thread interference, and atomic variables, but they still learn and get inspired, and they also get a well working robot. If teams were not provided the command based framework, many teams' robot software would contain threads, and would have many issues because threading is more difficult to do properly in Java/C++ than in LV. If teams are provided the command based framework, they also should get a simple example project (like the old IFI system had!). Who knows, maybe they wouldn't have to give us a control system that was complete overkill for 99.9% of the teams if we got example code.

[AllenGregoryIV]

To me it comes down to what the goal of the program is. Would I love every team to have programming mentors to teach students to program or students that are dedicated enough to spend the time to learn to program the robot properly on their own, YES. Does this currently happen, NO.

Would having default code provide a better experience to those teams at competition, inspire more students, and hopefully allow them to move away from the default code in the future, YES.

I equate default code to the kitbot. How few teams would be able to turn a long robot if the kitbot didn't already come with the center wheel dropped? Some teams still fail to do this even with the the kitbot and manual, just like some teams will still fail to plug everything in properly with default code, but it will allow us to get more robots on the field quicker and take up less time at competition. It will also allow more teams to be at least somewhat competitive and allow them to decide what new thing they want to learn that year, maybe it's not programming.

I run offseason workshops that go over programming, that is the time to learn how to code the robot. Not at competition where teams are missing matches.

[MrRoboSteve]

If you haven't tried RobotBuilder, you should do so before contributing to this discussion. It is a worthy competitor to a more complicated template, if for no other reason that it can support more than one scenario.

[EricH]

Note: I'm a mechanical guy.

To me, the value of default code is that it gives a base. You can look at it to get a model. You can use it as a base to build on.

But the REAL value is that it gets the robot running early, if there is a mechanical and electrical system ready for it. That alone is enough to make a case for a default code. (And, if you don't have a programmer... you can still survive.)

[Billfred]

Originally Posted by EricH

Note: I'm a mechanical guy.

To me, the value of default code is that it gives a base. You can look at it to get a model. You can use it as a base to build on.

But the REAL value is that it gets the robot running early, if there is a mechanical and electrical system ready for it. That alone is enough to make a case for a default code. (And, if you don't have a programmer... you can still survive.)

Eric more or less hit my points, but by a different route.

To me, the ideal default code is a well-documented one (a la Vex or the old IFI FRC controllers). Just as I can look at a drivetrain and see why we're throwing chains, I can look at an ideal default code, verify that left-drive is in PWM 1, right drive is in PWM 2, the pressure switch is in DIO 1, etc., etc., and that It Will Work. If it does not work, we can eliminate a lot of things.

Granted, the requirements to set up IP addresses may make it impossible to have the no-computer-required-ever simplicity of yore. Next-best thing would be to have the out-of-box cRIO able to run a testing mode and talk to the driver station software (which would look for a default IP and run with it with a big "HEY DUDE, YOU'RE IN TEST MODE – DOWNLOAD REAL CODE BEFORE COMPETITION" warning on the dashboard). At least then you can putt the thing around for testing or a demo.

[dtengineering]

I know of several teachers who were hesitant to get their students involved in VEX robotics because they, personally, knew nothing about programming. When I could show them that opening the box, plugging motors into the prescribed ports, and plugging in the batteries would get their machine running first time, every time... they decided that getting involved wouldn't be quite so scary. (That was with the old Crystal units... the new wifi units bring some additional sophistication, but at the cost of some of the simplicity).

When we first got involved with FIRST, our very first robot spent most of its time running default code. We just plugged the controllers into the ports that IFI specified, followed the wiring diagram and it all worked. Straight out of the box. First time, every time.

Neither our team, nor the VEX teams, continued to use default code beyond their first year... but it removed one barrier to entry. Once we got started with the default code, we had reason and opportunity to try something more complex.

Default code... that works, first time, every time, removes one barrier to entry. It matters.

As to how it could be implemented, I've got to say that I've been pretty impressed by the Raspberry Pi in this regard... I can build an SD card of a particular distro and application, plug it into any Pi on the planet, and have it run. First time. Every time.

If I screw it up, I unplug the SD card and plug in a new one with the "default" code on it.

If we want people to get involved with FRC, we should provide a welcoming experience with low barriers to entry. If we want them to come back, we should provide a minimally frustrating experience. Good default code that works straight out of the box, first time and every time is part of that experience. It matters.

Jason