Consider adding Vex MC29 option for servo ports

[Windwoes]

One very common issue teams have with the Vex Motor Controller 29 is that they set it up as a CRServo and then try to set the power to -1 or 1. This results in nothing happening because the PWM range of the Expansion Hub is wider than that accepted by the MC29. Creating an additional option for the MC29 in the servo drop-down would be trivial using the ServoType annotation. While one could make the argument that doing so would set a precedent for adding a servo type for XYZ servo because of a similar issue, I would argue that this case is expressly warranted due to the fact that the Vex motor is the only type of "servo" explicitly mentioned in GM1.

[AlecHub]

I would prefer scrapping Servo and CRServo altogether and just stick with a lower level PWMOutput type interface. Let teams invent their own wrapper classes for whatever type of PWM device they've attached to a PWM output port. Less confusing, more fun , and better educational value this way.

[Windwoes]

Yeah that's also an equally valid option. Although, having the Servo class with the default wide PWM range that works with many servos is convenient.

[AlecHub]

having the Servo class with the default wide PWM range that works with many servos is convenient.

Or leave Servo class out of the SDK and provide the source code for Servo class in a sample opmode.

[alan412]

Personally I think removing a class that has been in the SDK and that a good bit of example code depends on is a bad idea.

[AlecHub]

Not removed, just moved to sample code.

[AlecHub]

I would prefer scrapping Servo and CRServo altogether and just stick with a lower level PWMOutput type interface. Let teams invent their own wrapper classes for whatever type of PWM device they've attached to a PWM output port. Less confusing, more fun , and better educational value this way.

Same goes for LinearOpMode. Take LinearOpMode, Servo, and CRServo out of the SDK and just provide the source code of these classes in the samples. For those of you who are in love with these classes, just think of it as a baby step towards an open source SDK.

[Windwoes]

I would prefer scrapping Servo and CRServo altogether and just stick with a lower level PWMOutput type interface. Let teams invent their own wrapper classes for whatever type of PWM device they've attached to a PWM output port. Less confusing, more fun , and better educational value this way.

Same goes for LinearOpMode. Take LinearOpMode, Servo, and CRServo out of the SDK and just provide the source code of these classes in the samples. For those of you who are in love with these classes, just think of it as a baby step towards an open source SDK.

No I disagree with you on that. The LinearOpMode source is not a simple thing and could easily be messed up big time by a user. Also in my opinion, LinearOpMode is way more useful than OpMode because you can easily create a while(opModeIsActive() loop in a LinearOpMode, and it gives absolute control over exactly when your code is run.

[1tree]

I don't think either should be removed. Nobody who has started a team would think this a good idea.

While I disagree with FROGbots-4634 over the usefulness of LinerOpMode, I do consider it a great starting point to teach how to write code. Something that needs to be kept in mind is that the system needs to be accessible to teams that are starting out and teams without mentors who can guide them through the early stages of growth.

[AlecHub]

I don't think either should be removed. Nobody who has started a team would think this a good idea. While I disagree with FROGbots-4634 over the usefulness of LinerOpMode, I do consider it a great starting point to teach how to write code. Something that needs to be kept in mind is that the system needs to be accessible to teams that are starting out and teams without mentors who can guide them through the early stages of growth.

Hi Kirk, perhaps a better starting point is for kids to read and understand the sample code. If we add Servo and LinearOpMode to the samples, that may further aid in kids learning, and better yet on kids learning on their own..

[1tree]

Actually when starting from 0, that is a terrible way for most to learn programming. We have formed a team from my scout troop and they have struggled with a couple attempts at learning to program.

What worked after a few failed attempts was to start with a blocks op mode that had a simple drive controlled by the joystick. We made a couple modifications on that. Then we looked at the same in java relating what they saw before to text. We refactored the text to move each section into a separate method. Then we moved the contents of each method into a "normal" op mode.

They are now working on refining basic robot movement and struggling with building a simple autonomous routine.

As I type this out it occurs to me that to remove LinearOpMode would require a rework of Blocks. All blocks op modes translate to LinearOpMode. The thing is that it is easier to see a progression than to direct the whole. It is easiest when you start with some obvious commands that do stuff.

[AlecHub]

All blocks op modes translate to LinearOpMode.

I was not aware of this, so yeah you can't remove LinearOpMode.

The thing is that it is easier to see a progression than to direct the whole. It is easiest when you start with some obvious commands that do stuff.

Agreed, and that's exactly what the sample opmodes do. Start with the simple samples and work your way up to the more advanced samples.

[1tree]

The simplest thing is to see a liner progression of things happening. At some point I need to look into how they set this up.

[1tree]

I will say that I like the idea of having open source examples of how to wrap various things up. For teams starting out, it could make things move much quicker. Just never under-estimate the intimidation of starting out where no team members are sure what to do.

[gearsincorg]

@1tree

They are now working on refining basic robot movement and struggling with building a simple autonomous routine.

LinearOpmode was created specifically to address the needs of making Autonomous simpler. Teleop is usually a simple joystick/motor loop, so the basic OpMode class is great. But once you start doing sequences of moves with interlaced actuator movement, even a simple Autonomous OpMode starts getting really messy. Welcome LinearOpMode.

In the first years of FTC/Android, there was not a well-developed LinearOpmode class, and you needed to create your own state machine to do anything significant in Autonomous. State machines are great, and very cool programming constructs to learn, but if you are talking about incremental progression for non-programmers, they can be daunting. Go back to 2015 to view a three part video series I created to ease the transition. https://www.youtube.com/watch?v=Pu7PMN5NGkQ&t=2s

Best Advice ever... If you or the kids are struggling, work through the samples, and watch some tutorials. Blocks is great, and now it can help the transition to Java with the Export to Java feature.

[AlecHub]

Best Advice ever... If you or the kids are struggling, work through the samples, and watch some tutorials.

The samples and the javadoc are awesome. I don't believe I've ever posted a question on a topic that was covered in either the samples or the javadoc. I've answered a lot of posts by folks who don't consult the samples or the javadoc. Perhaps the first thing that needs to be taught to kids and to mentors is to consult the documentation.