Announcement

Collapse
No announcement yet.

Download new/modified code to phones.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dlevy
    replied
    Originally posted by dburnette View Post
    LinearOpMode is poorly named. It implies that it has something do to with traveling in a straight line.
    I think what they were going for is Linear VS Event based. My interpretation of "Event" based in this context is that the Event is fired ( loop() method is called) when the hardware is ready to be evaluated ( sensors read, motors written to). The motor actions will go into effect after the loop() method is completes.

    Linear on the other hand means "top down". That is you code your opmode to read sensors and write to motors with the expectation that the action on the motors will performed immediately ( don't have to wait to the end of your opmode method).

    What tends to happen in Linear mode is that your top down program tends not to be able to do its job by simply running the code once. That is, sensors that were checked earlier in the code may need to be checked again. As a result, looping may need to be added to the top down method at some level. When looping wraps the entire top down method , then the distinction between Event based and Linear becomes a bit fuzzy in my opinion.

    Leave a comment:


  • dburnette
    replied
    LinearOpMode is poorly named. It implies that it has something do to with traveling in a straight line.

    Leave a comment:


  • dmssargent
    replied
    Originally posted by zain View Post
    OK, that's just a little confusing. Is that true for code that "extends" *both* the OpMode *and* the LinearOpmode classes, or just one of the two?

    And... what then are the Java equivalents of RobotC StartTask() and StopTask(?) How do we get multiple things happening in parallell?
    Java does not allow to extend multiple classes. The best bet if you needed to do it, is to write a "reverse proxy" class to handle it.

    Originally posted by FTC_Team5648 View Post
    The LinearOpMode is like RobotC. The OpMode is the one in which that is true not the LinearOpMode.

    The equivalent to StartTask() is:
    Code:
    Thread thread = new Thread(new Runnable() {
        //Insert code here
    });
    thread.start();
    I'll reply again later with an example of how to implement StopTask()
    You have to keep the reference of the Thread, and call the interrupt() method of it to stop (if the code can handle an interruption).

    Leave a comment:


  • FTC_Team5648
    replied
    Originally posted by zain View Post
    OK, that's just a little confusing. Is that true for code that "extends" *both* the OpMode *and* the LinearOpmode classes, or just one of the two?

    And... what then are the Java equivalents of RobotC StartTask() and StopTask(?) How do we get multiple things happening in parallell?
    The LinearOpMode is like RobotC. The OpMode is the one in which that is true not the LinearOpMode.

    The equivalent to StartTask() is:
    Code:
    Thread thread = new Thread(new Runnable() {
        //Insert code here
    });
    thread.start();
    I'll reply again later with an example of how to implement StopTask()

    Leave a comment:


  • dmssargent
    replied
    An example of a state machine for a Unified Diff Parser:
    http://wickedsource.org/2013/11/19/s...ine-with-java/

    State machine libraries:
    http://www.techrepublic.com/article/...tate-machines/
    http://stackoverflow.com/questions/1...brary-for-java

    I think the roll your own method is to create an enum of states and have a select case for each state that calls a function.

    Leave a comment:


  • FTC8767
    replied
    Are there any good tutorials to learn the state machine logic int java?

    Leave a comment:


  • zain
    replied
    Originally posted by markshancock View Post
    Note also that in RobotC, motor commands took effect when they are called; but, for an OpMode, motor commands build a list of instructions that don't get executed until AFTER the loop() method returns.

    Ex: In RobotC the following would cause motor1 to turn on for 1 sec then turn off
    motor[motor1] = 100
    wait1Msec(1000)
    motor[motor1] = 0

    This approach will just wait 1 sec then turn off motor1 (because the the commands would be collected, there would be a 1 sec delay, then when loop() completed it would see motor1 was set to 0 and send that to the motor)

    OK, that's just a little confusing. Is that true for code that "extends" *both* the OpMode *and* the LinearOpmode classes, or just one of the two?

    And... what then are the Java equivalents of RobotC StartTask() and StopTask(?) How do we get multiple things happening in parallell?

    Leave a comment:


  • Tom E Reynolds
    replied
    https://www.youtube.com/watch?v=UtKbbi31PWc

    Here is a great video that shows how to load the SDKs into Android Studio, and then modify one of the default OpModes (TeleOp Programs), then load onto the phone.

    My kids were able to watch it twice and then load their programs and get some motors working!

    Leave a comment:


  • markshancock
    replied
    Note also that in RobotC, motor commands took effect when they are called; but, for an OpMode, motor commands build a list of instructions that don't get executed until AFTER the loop() method returns.

    Ex: In RobotC the following would cause motor1 to turn on for 1 sec then turn off
    motor[motor1] = 100
    wait1Msec(1000)
    motor[motor1] = 0

    This approach will just wait 1 sec then turn off motor1 (because the the commands would be collected, there would be a 1 sec delay, then when loop() completed it would see motor1 was set to 0 and send that to the motor)

    Leave a comment:


  • GearTicks
    replied
    In regards to LinearOpMode vs. OpMode, it is really just a difference in how you choose to program. OpMode uses an "event-driven model", so there is a start() method called when loading the OpMode, an init() method called when starting the OpMode, a loop() method called repeatedly once the period begins, and a stop() method called when the OpMode is stopped. A LinearOpMode is an OpMode, but it merges all those methods together into one master runOpMode() method. None of the method calls in OpMode are supposed to be "blocking", which means that the methods should execute and return as fast as possible, while it is encouraged to use methods like sleep() (which prevents the function execution from continuing for a certain amount of time) in a LinearOpMode. LinearOpModes will probably come much more easily to experienced RobotC programmers who wrote autonomous programs that weren't state machines.

    Leave a comment:


  • FTC3805
    replied
    First you need the FTC training manual:
    https://github.com/ftctechnh/ftc_app...r/doc/tutorial
    (I believe the 0_94 version is the same as the one with no version number on it.)

    Chapter 9 has what you're looking for.

    Leave a comment:


  • zain
    started a topic Download new/modified code to phones.

    Download new/modified code to phones.

    Disclaimer: Mech-E non software coach here, so go slowly and use small words...

    Following the various disjoint instructions available, we now have functional control of motors and servos in either the pushbot or K9 configurations. And the kids have pawed through the example code and are ready to try changing examples into their "own" programs to verify comprehension. The following seemingly obvious questions arise and I did not have answers:

    1. So once they build/compile new code/apps how do they actually download them to the phone? I speed to have missed a step between getting the Apps from GooglePlay and making your own with your own code.
    2. Are we all converging on using LinearOpmode or (regular?) Opmode and what they heck are the differences and where are they documented?
    3. And what about the legacy sensors... Eh... This list gets long, I'll settle for the first couple and try to stumble along with the kids after that.

    Thanks in advance.

    - Z
Working...
X