What do you think about how easy theyre making programming?

[CJO]

Seriously,

Take a look at the code before you start talking. If the kevin.org/frc version is correct, the "scipted" commands are simply a matrix in the file "commands.h." That being the case, all you are really doing is calling macros, besides, if you can integrate the Camera system effectivly with interrupts, etc., you are doing well. Finally, you do not have to use the scripting, if you are really that good, go ahead and write in binary.

[BandChick]

I think what FIRST has done gives MORE students potential in programming and engineering that they didn't have before. I don't speak programming, not well anyway, but with the new code I can actually understand what's going on. And to me, that's golden. I would love to understand more than just what the robot is made of and how it works. This gives every student, not just the programmers, to try their hand at something new. I think we all need to remember that FIRST is about inspiration, not about competition. With the new code I think FIRST is more likely to see kids heading in the programming direction that might have been afraid to previously.

[KevinH]

Every team this year is also getting pieces to build gearboxes and frames out of a kit, and I don't think all of the mechs are complaining. Rookie teams are happy that they can get a successful robot and focus on making a robot competitive now, rather than just a robot, while I expect most veteran teams are still going to build all of their own gearboxes and chassis.

Same with programming- I expect most veteran teams will use what they know and write at a lower level w/o scripting or at least extending their scripting to be more powerful, while rookie teams will use the 'out-of-the-box' code.

If FIRST removed the ability to code at a lower level, there would be a problem, but they didn't. Rookie teams are still going to need to figure out what to do with the tools to be competitive.

I think that FIRST is very worried about veteran teams getting so much more advanced than rookie teams that rookie teams never stand a chance. That's why this year they tried to find ways to help rookie teams remain competitive with the most of the teams at a competition, and that's why this year we have a 3v3 game: in 1v1's rookies stand a suffer alone, is 2v2's, the veteran paired with a rookie often stands at a significant disadvantage, but in a 3v3, a rookie team doesn't really matter as much as past years. 3 team alliances also force rookie and veteran teams to talk, to strategize together, and helps rookie teams learn from the veterans.

I think the biggest difference this year is that this game is different-- there's no big mechanical challenge this year like 10' high chin-ups, but there's a big strategy challenge in managing the alliances. I think this is the biggest 'problem' this year, and that kits and better default code was inevitable.

[CJO]

The FIRST scripting has just been released. That means that all of this complaining was without even seeing the "scripting." Kevin Watson wrote the scripting system. It is available at kevin.org/frc.

Please download the zip, and take a look at the way it works before you start complaining, even the writing is difficult. Not to mention, the Camera software is not supported by the scripting system . . . so, all of you "its too easy to program" people, figure out a way to make the serial port driver in the FIRST release (required for LCD screens and the new powersystem) interface with the serial port driver required to make the Camera function. In addition, you must develop scripting commands for each camera function. Then, add interrupts, encoders, math libraries, gyro control, banner sensor control (for those of you who do wheel rev counts), custom interface control (a nightmare to adapt to the new serial drivers), and any custom robot parts, and then, sure, its almost easy.

P.S.: For anyone not thrilled to do all that themselves, I have posted a version of the default code in the white papers section here. It includes support for the camera, the new Dynamic Diagnostics Tool (included in IFI loader 1.8), LCD screens, and the power system, it also incorperates interrupts, encoder control, and gyro control. In addition I have included the cordic math libraries and basic camera control, while maintaining the scripting set-up.

[cabbagekid2]

I wouldn't mind looking at your code to see how you got all those things incorporated, but when I tried looking for it in the white paper section, it wasn't there. Did you not post it up there yet? I'll check back later.

Thanks.

[Mike Betts]

Originally Posted by KevinH

...I think the biggest difference this year is that this game is different-- there's no big mechanical challenge this year like 10' high chin-ups,...

Kevin,

I do not think that you have looked at the game close enough...

Center of gravity and strength of materials will be a huge problem for a majority of teams. In fact, I think it likely that an awful lot of teams will not be able to solve the problem.

[Mike Betts]

Originally Posted by CJO

The FIRST scripting has just been released. That means that all of this complaining was without even seeing the "scripting." ...

Chris,

Well said! This is hardly a trivial challenge.

Regards,

[KevinH]

Originally Posted by Mike Betts

Center of gravity and strength of materials will be a huge problem for a majority of teams. In fact, I think it likely that an awful lot of teams will not be able to solve the problem.

Still, I feel like lifting a pvc tetra to cap a the 7' tall goal isn't as hard having a robot lift itself up on a 10' bar.

[EDIT]
Not to mention climbing the steps to get to the bar...

[Mike Betts]

Originally Posted by KevinH

Still, I feel like lifting a pvc tetra to cap a the 7' tall goal isn't as hard having a robot lift itself up on a 10' bar...

We shall see....

[stephenthe1]

we're having trouble with Kevin W's code. we have an encoder hooked up to digital (interrupt) 1 (left encoder). this encoder is actually working on an arm, so for now we're not bothering with the wheels. here is the code in user_routines_fast. everything else is configured properly. the only thing is that our encoder's "b" phase isn't wired yet. will this mess it up? here's the code, I'm interested if this will even work as I'm somewhat new to this stuff.

pwm14 = p1_y;
	pwm16 = p2_y;
	if (Get_Left_Encoder_Count() >= 12)
	{
		pwm02 = 127;
	}
	else
	{
	pwm02 = p3_y;
	}

[IAmDave0887]

your right the coding is easier to understand. i just figured that easier meant worse but now that i've given it a second look its easier to understand and teach to new members so they can take over for the seniors who are leaving after this season. i do agree with you in that it gives more people a chance to see if they like programming.

[Greg Ross]

Originally Posted by stephenthe1

[T]he only thing is that our encoder's "b" phase isn't wired yet. [W]ill this mess it up?

Yeah, I would guess not having the B line connected will keep your code from operating as you expect. (Since you don't explain how you expect it to operate, I will make some assumptions.)

Not having the B line connected will keep the software from knowing which direction the encoder is turning. If you're lucky(?), the encoder interrupt handler will DECREMENT the counter on each interrupt, so that the arm control will appear to operate correctly for a while (with the exception that the arm won't stop where you think it should be when the encoder counter = 12.) After the encoder counter overflows, the arm will stop responding, because the counter will now be greater than 12.

If, on the other hand, the interrupt handler INCREMENTS the counter instead of decrementing it, I expect that the arm will stop responding after just a slight twitch, no mater which direction you move the joystick. (I say just a slight twitch, because 12 seems like such a small number when you're talking about encoders. I could be wrong, and your encoder might actually be of low enough resolution that a count of 12 will actually measure a reasonable arm rotation.)

[Mike Betts]

Originally Posted by stephenthe1

we're having trouble with Kevin W's code. we have an encoder hooked up to digital (interrupt) 1 (left encoder). this encoder is actually working on an arm, so for now we're not bothering with the wheels. here is the code in user_routines_fast. everything else is configured properly. the only thing is that our encoder's "b" phase isn't wired yet. will this mess it up? here's the code, I'm interested if this will even work as I'm somewhat new to this stuff.

Steve,

First of all, please do not take this personally (it is usually a matter of communication)...

Please start by explaining your algorithm in plain English. What you are trying to do. Your code/question does not make sense to me.

[pickle]

Originally Posted by KevinH

Still, I feel like lifting a pvc tetra to cap a the 7' tall goal isn't as hard having a robot lift itself up on a 10' bar.

[EDIT]
Not to mention climbing the steps to get to the bar...

Yes, but now you have to raise an 8 pound hunk of plastic 7' in the air, plus, the more they stack, the higher it gets, to you have to reach higher and higher, each time you're holding an 8-12 pound object on the end of an arm, stressing the material alot because of wobbling, and the center of gravity gets moved and tipping is easier..... I think its just as hard.... Instead of just having raw power to pull your 120 pounds up, you have to find a way to make a manuverable bot, but one that won't tip when you really throw the center of gravity off

[Roland]

Originally Posted by pickle

Yes, but now you have to raise an 8 pound hunk of plastic 7' in the air, plus, the more they stack, the higher it gets, to you have to reach higher and higher, each time you're holding an 8-12 pound object on the end of an arm, stressing the material alot because of wobbling, and the center of gravity gets moved and tipping is easier..... I think its just as hard.... Instead of just having raw power to pull your 120 pounds up, you have to find a way to make a manuverable bot, but one that won't tip when you really throw the center of gravity off

I agree, hanging is relatively easy compared to this. The reason is that you only had to hang once last year, and once you were hooked on the bar you were pretty much set. Now, though, you'll have to quickly stack a bunch of tetras during each match, and you can't attach to anything.