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… 
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”
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
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.
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
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
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
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
Decide 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
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.
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.
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
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.
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)
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 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.
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