Who Has Programmed From Scratch?

[davidthefat]

Well since the eclipse detection demo worked out of the box, my mentor said to just add on to it and I just added maybe 8 lines of code and we got a fully functional robot, the kicker, compressor and camera and drive all working right... :confused: :confused: Why does FIRST do this? its too $@#$@#$@#$@# easy, I think they should just give the API and the Libraries next time with no demos and make us figure it all out... My mentor says he knows how I feel, but he is more worried about a functional robot than "The feeling of satisfaction you get from programming"

[Mr. Lim]

I guess we know which team will be scoring 6 balls in autonomous mode at the LA regional this year!

:ahh:

There's a world of difference between just getting a robot to work versus producing a world-class robot.

The mediocre do the minimum, then exclaim how easy it is.

The exceptional never stop to gloat... they're too busy figuring out new ways to make it even better...

[davidthefat]

I guess we know which team will be scoring 6 balls in autonomous mode at the LA regional this year!

:ahh:

There's a world of difference between just getting a robot to work versus producing a world-class robot.

The mediocre do the minimum, then exclaim how easy it is.

The exceptional never stop to gloat... they're too busy figuring out new ways to make it even better...
Well IDK:rolleyes: My mentors do not believe in the programmers... I wanted to make a robot that would be shooting accurately, well programming can't do crap if the robot hard ware does not allow for that to happen... From the first day of the video broadcast, I had a design for a shooter that will allow programming to do it's job to the full potential, got shot down as soon as I presented it, for being too complex for "Highschoolers to make" well I don't think we were motivated enough, the programmers had to play around with the old robotics for the first 4 weeks... When I run for team leader next year, I hope to change that... I was totally willing to work my $@#$@#$@# off for this since this was my first year... We don't even know what to do during autonomous period, and how many days do we have left? like 5? I personally feel offended for not getting worked harder


Our team focused too much on the hardware itself, but my self was saying software first from the beginning, taking into stanford's philosophy of software first. I wanted to focus on the software to handle almost every thing, but too bad that didnt happen

[FlyingHedgeHog]

You might seriously consider applying the "student designed, student built, mentor approved rule. As it would seem you are having some instances of mentors being a bit too over-bearing, perhaps. Another useful rule our team has it the "mentors hands off policy." They don't have anything to do with the bot other than random pieces of advice here and there.

[davidthefat]

You might seriously consider applying the "student designed, student built, mentor approved rule. As it would seem you are having some instances of mentors being a bit too over-bearing, perhaps. Another useful rule our team has it the "mentors hands off policy." They don't have anything to do with the bot other than random pieces of advice here and there.

Well there is that rule but our mentor STRONGLY advised us to just go from the demos... Well I guess our mentors are pretty involved in our robot... The robot this year is a fail in my book, I personally thought we could have done way better, none of my ideas got implemented either... and we are losing lots of valuable seniors next year, so I have to step up.

[ideasrule]

Does the demo code work out of the box for detecting soccer balls? I haven't been able to get that to work.

[davidthefat]

Does the demo code work out of the box for detecting soccer balls? I haven't been able to get that to work.

No, because the ball is not a 2 dimensional shape, it has shadows and stuff, so no

[davidthefat]

I HATE this year's robot, the kicker does not kicker over even one bump... Its unpredictable kicking too. I just hate it... It doesnt even drive over a bump... The middle wheel prevents it, and I was warning about it since the idea was introduced... $@#$@#$@#$@# no one listens to the sophomore...


I am definitely running for Team leader next year... I think we have to work harder next year

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

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

[gblake]

I ... next yearDecide if you (personally) want to be RIGHT, or be successful; and then do what is appropriate after that decision.

The consequences of that decisioin might even involve an apology or two.

Many people want to be successful, but mistake that goal for the similar goal of being RIGHT.

Blake

[slavik262]

The mediocre do the minimum, then exclaim how easy it is.

The exceptional never stop to gloat... they're too busy figuring out new ways to make it even better...

This sums it up extremely well. A good programmer is never done coding, and his programs are never done (at least not before the deadline, they're not). If you're complaining that things are too easy, make it harder. There's always something that your code can do to make the robot perform better and the drivers drive easier. Implement PID on a mechanism so that it functions more smoothly. Implement the dashboard so your drivers have feedback. There's always something you can do. Our robot code has exceeded 2000 lines every year for the last three years, and I'm working on custom dashboard software that will soon exceed 4000 lines. I'm saying this to brag, but just to make the point that you can always add more and make it better. Could my team use the out-of-the-box code and use a standard dashboard? Sure we could, but we want to aim higher than that.

As for mentors, our team has always believed strongly that FIRST is an organization for students. We (the students) design the robot, we build the robot, and we code the robot. The mentors are there for our assistance when we ask for it. If this isn't how your team works and the mentors make the decisions, I'd strongly suggest doing something about this. FRC is a program for students, and your team should be for the students too.

[Alan Anderson]

To answer your question directly: the only things left from the default code in the Begin and Finish vi's of this year's TechnoKats programming are the camera initialization and cleanup. Aside from the framework, everything else in them and in the entire Teleop is custom. We also played a little trick of our own that prevents typos in the RefNum Registry names.

Naturally, a twelve-wheel holonomic drivebase with full pushing power will tend to need completely different code than what the default 2-motor arcade drive has.

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

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

[Tom Bottiglieri]

but my self was saying software first from the beginning, taking into stanford's philosophy of software first. I wanted to focus on the software to handle almost every thing, but too bad that didnt happen
Stanford had a large amount of support from VW during the GDC.

Also,
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.

[Loubear]

I take a "if it's not broken, don't fix it" mentality towards all of this. If the existing camera code works fine, I have no qualms just using the default code. My time can be better spent doing something more productive and not already done, like implementing a kalman filter to augment dead reckoning, or creating an editable config interface. If you want a robot that just drives and does nothing else; then you could always use the default code. Other than that, there are PLENTY of neat things to be coding.

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

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

[bcieslak]

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]

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

[Dave Scheck]

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

[Jon Stratis]

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.

[AmoryG]

Stanford had a large amount of support from VW during the GDC.

Also,
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.

Yep. What's the point of getting your camera to track if you're just as likely to hit the referee standing 10 feet from where you were aiming?

[apalrd]

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

[davidthefat]

Stanford had a large amount of support from VW during the GDC.

Also,
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 mean the hardware supplements the software, not software supplementing the hardware, a big difference