Who Has Programmed From Scratch?

[davidthefat]

Well its my first time working on a robot, I have written tons of code thats way past the 1000 lines, but they were games on the computer, its just a different feel

Well enough complaining, have a meeting in like 1.5 hours

[apalrd]

I can't say much about Killer Bees code(well, actually I can), but Windows says the project directory has 114 files, not including the stuff in Builds. Those include VI's, LBPROJ, and MNU's. This does not include the Dashboard, it has its own folder. Most of the files are VI's. We took the default structure, and then separated all of the code into modules that run in their own threads. We also designed it to work the same on both robots, keeping two sets of cal points, process variables, and opening IO differently for each robot. We left the existing Elipse finding software, but wrote our own camera tracking software, although it uses the gyro in a similar way to the default code. Everything communicates with global variables, so there's not alot of wiring data between the modules (Actually, there is exactly none.) We made use of Diagram Disable structures to allow us to debug modules separately. No line count; LabVIEW dosen't have lines.

Oh, and for Autonomous - We wrote some cool stuff. So cool it needs to know if it is running on Win or VxWorks.


A direct answer to the question:
We took the Default code, and then added an enormous amount of code to it. We used hardly any of it.

As to the programmer that is never done:
I am still perfecting much of the autonomous stuff and implementing many features to increase accuracy and make it as close as possible to the simulator.

[Dave Scheck]

Originally Posted by apalrd

I can't say much about Killer Bees code(well, actually I can), but Windows says the project directory has 114 files, not including the stuff in Builds

For reference on the C++ side, we're currently at 120 files (.h and .cpp) with 12,146 lines (using a simple wc -l). Last year we had 137 files and 11,015 lines.

Our framework is a bit overkill, but it's definitely a very elegant way to approach the problem. The whole mentality is to isolate the inputs from the outputs and make the class methods simple and straightforward.

In a simple example, lets consider a simple two motor tank drive system controlled by a single joystick in arcade mode. Our robot class would instantiate the following objects

* Gamepad - The gamepad that controls the driving
* WsControllerAxis - One is created for each axis on the gamepad
* WsControllerPolarStick - Takes in two WsControllerAxis objects and creates a polar coordinate system out of it.
* WsControlMethodTank - Takes in a WsControllerPolarStick (as well as any buttons that are needed for driving such as turbo) and converts the inputs to a WsDriveVector (speed and direction)

* SpeedController - One is created for each Victor that we're controlling
* WsSc - Wraps a SpeedController so we can do things like disable or debug
* WsDriveBaseTank - Takes in the two WsSc objects. Uses a WsDriveVector input to calculate the outputs to send to the WsSc (and subsequently the SpeedController)

Then from in the teleop periodic call, we simply do a get on the WsControlMethodTank to get a WsDriveVector and pass that in to the WsDriveBaseTank and away we go.

On the autonomous side, we simply make these same types of calls and reuse the entire drive base objects. In addition, all of our programs run in a common engine that takes simple commands like driveByTime or driveByEncoder. This makes writing programs as simple as defining the steps and calling an addCommand function. Our individual autonomous programs last year didn't have a single line of logic in them. They simply assigned values to the step parameters and called addStep. Since they all derive from the same base class, they all have a run in the base that handles stepping through the commands.

[apalrd]

Originally Posted by Dave Scheck

...On the autonomous side, we simply make these same types of calls and reuse the entire drive base objects. In addition, all of our programs run in a common engine that takes simple commands like driveByTime or driveByEncoder. This makes writing programs as simple as defining the steps and calling an addCommand function. Our individual autonomous programs last year didn't have a single line of logic in them. They simply assigned values to the step parameters and called addStep. Since they all derive from the same base class, they all have a run in the base that handles stepping through the commands...

We did something fairly similar, except instead of adding commands to a list, we simply called the commands directly. We wrote our code in LabVIEW, and it runs in a virtual thread, so we can do things like this c++-equivalent code:

void auton_f1(void)
{
set_ball-o-fier(RUN);
drive_Straight(36,0.6); //Drive forward 36 inches max speed 0.6
drive_to_ball(0.3); //Creep to broken-beam sensor
kick(); //Kicker manipulates ball-o-fier as necessary, leaving it in its original state
drive_Straight(24,0.4); //Drive to almost next ball
drive_to_ball(0.3);
kick();
.....

We initially wanted to write the Auton code in Python, but decided that the Python-Labview interface would be too challenging to write compared to its advantages, so now we just put a bunch of VI's together and execute them sequentially.

[Lord_Jeremy]

Heh. As I just posted about in the Java forum, my codebase just broke 5000 lines. Complex things like the navigation-enabled drive class is nearly 1000 lines. I did a lot of things from scratch, not even using the WPILibJ stuff except for really low level. (I'm sure you can agree no one likes staring at data sheets trying to figure out how to send the raw signal to the Jaguars)

[will_1359]

so far i've got 5 class's about 25 lines of code each, and no robot to demo the code on... scrim is saturday, should be interesting

[Lord_Jeremy]

Originally Posted by will_1359

so far i've got 5 class's about 25 lines of code each, and no robot to demo the code on... scrim is saturday, should be interesting

Gah, that's always a hardship... I was supposed to get a robot tuesday, but of course the magical gods of aluminum decided to forsake us and four of our axles bent. Went downhill from there...

[Greg McKaskle]

On the LV lines of code measurement, in Tools>>Profile, there is a VI Metrics item which will give you statistics about your code. The tool only works on one VI at a time, but if you write a quick VI, you can call the same method on a VI and build your own tables/graphs, or whatever. It is often used by bigger SW teams to keep track of how their code has evolved.

Greg McKaskle

Originally Posted by will_1359

so far i've got 5 class's about 25 lines of code each, and no robot to demo the code on... scrim is saturday, should be interesting

Hey welcome to the wonderful world of Embedded Systems engineering. It not only happens at FIRST but in industry too. 13 to 26 week lead time on parts and boards....and management expects the firmware to be done and tested the day the boards arrive...There's a lot of truth in those Dilbert cartoons we laugh at. (sad to say)

Next year build up an electrical board that you can develop code on, then drop into the robot the last week when the mechanicals catch up.

BC

[apalrd]

Originally Posted by bcieslak

...Next year build up an electrical board that you can develop code on, then drop into the robot the last week when the mechanicals catch up..

Thats not the hardest problem. The hardest part is trying to tune feedback loops with everyone's hand out of the robot. Even when it's done, there are stil like 30 people trying to measure things for the practice robot or adding graphics or something, all of whom think they have a more important job than everyone else or think they're not directly in my way. They are. Everything is so close together that touching the robot = in my way.


EDIT: VI stats on Robot Main and subs, total:
1529 nodes
165 structures
353 diagrams
2022 wire sources
88 controls
65 indicators
0 property reads/writes
80 global reads
53 global writes
1 local read
0 local writes

Averages:
29.3 nodes
2.95 structures
6.30 diagrams
36.11 wire sources
1.57 controls
1.16 indicators
1.43 global reads
0.95 global writes
1.29 connector inputs
1.07 connector outputs

Over 56 VI's
393 vi.lib calls

That dosen't include any of Autonomous Independent - That will be harder to check, since it relies on a few Invoke Nodes which cause LabVIEW to not follow all subs. This dosen't include any of auton.lib either...

[Jon Stratis]

Originally Posted by TomBot

Hardware always comes first. If your FRC software isn't required to be anything more than dumb, you will have a better robot. I guarantee it. Any software you develop means nothing if the hardware isn't reliable.

I would disagree with this - a good robot is designed with everything in mind. The best mechanism in the world isn't going to do anything unless programming can make it work. So many people (especially students, but it applies to mentors, too) in FIRST are completely focused on their own specific area - be it mechanical, programming, electrical, PR, scouting, driving, or whatever - they forget to step back and look at the big picture. You see this in industry, too - you may have 100 people working on a project, and everyone is completely focused on making their part perfect. If you don't have someone concerned about the big picture, you'll end up with 100 perfect parts that don't work well together.

Our team tries to solve that problem. We start with the big picture, and make sure everyone knows what we want the robot to be able to do. During the season, roughly ever other meeting we take the last 15 minutes for "show and tell" - we go around and everyone presents what they've accomplished. This gives everyone a chance to not only be exposed to other areas, but to provide thoughts when someone encounters a problem and to show off their accomplishments. We've managed to build some pretty sweet mechanisms over the past few years, put in place all the feedback that was needed, and write some fairly complicated code to get it all to work.

It's not software first, and it's not hardware first. It's robot first, and a robot is all that and more.

[reversed_rocker]

yes, the demo code will work for a simple robot, but if you want to go beyond that you have the option. the code for 706's robot recently broke 500 lines (i started with the example "simple robot template", which was around 40 lines to begin with). it all depends on how many features you want and the amount of control you want on each one. i find that if programming has become to repetitive or too easy, i can just come up with a couple more sensors to add to take that extra load off the driver, or make an awesome autonomous mode.

some great ways to challenge your programming skills:

write an autonomous mode that automatically aims at the target

give your robot a swerve drive and make your own steering wheel

use a custom controller (something beside the joysticks)

write debugging code/add diagnostic sensors to see if any part of your robot is malfunctioning

all of these things are very possible but cant be done by copying and pasting demo code, and of course you can always write your own commands instead of using the ones built into the WPI library (i for one really dont like the PID controller)

[davidthefat]

Originally Posted by reversed_rocker

yes, the demo code will work for a simple robot, but if you want to go beyond that you have the option. the code for 706's robot recently broke 500 lines (i started with the example "simple robot template", which was around 40 lines to begin with). it all depends on how many features you want and the amount of control you want on each one. i find that if programming has become to repetitive or too easy, i can just come up with a couple more sensors to add to take that extra load off the driver, or make an awesome autonomous mode.

some great ways to challenge your programming skills:

write an autonomous mode that automatically aims at the target

give your robot a swerve drive and make your own steering wheel

use a custom controller (something beside the joysticks)

write debugging code/add diagnostic sensors to see if any part of your robot is malfunctioning

all of these things are very possible but cant be done by copying and pasting demo code, and of course you can always write your own commands instead of using the ones built into the WPI library (i for one really dont like the PID controller)

I wanted to do all these, PS3 Controller (How sick would that be) and the auto target/shoot but thats useless since the kicker is crap

[Greg McKaskle]

Being a SW guy myself, I can understand your frustration when everything else still has issues, but I'd encourage you to focus it in a more positive way.

Perhaps you can approach your mentor with some projects that you can work on that will not add too much risk to the robot. For one thing, you can easily make alternative code that you can test against the built-in. When yours is better and you convince your team and mentor, you can switch over. You can also switch back if you discover issues with yours.

It is pretty safe to develop a nice dashboard to give the drivers more info. And if you don't have an autonomous routine, yet, that is like the SW freebie. Figure out a way to score from at least the front field position in auto.

And good luck.
Greg McKaskle