Announcement

Collapse
No announcement yet.

Auton Does Random Things

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

  • Auton Does Random Things

    Please HELP!!!!

    We have had no issues getting everything to work fine in tele...Autonomous is another story though!

    Every time we run it, something different happens.

    I even started with a brand new program, no tele, only one auton, and it still gave us issues.

    We started fresh with a LinearOpMode, did a waitforstart, and just to try to get something consistent, we just did both motors same direction. Nothing extra.

    We had the same issue we have every time we try to run auton - 1 time it might work, next time only one motor turns, next time the opposite one turns, next it works right, next only one motor again, but opposite. We must have stopped and started it 35 times, and there was not even a pattern of which times it did what.
    I don't get it! There was nothing else in the program at all!

    We even tried the steps in this thread, but we run into the same issue, building it the exact same way they did.

    We are headed to the State tournament Saturday, and would love to actually be able to run an autonomous without fear of it just turning in front of our alliance mates.

    Thanks!

  • #2
    Originally posted by FTC10211 View Post
    Please HELP!!!!

    We have had no issues getting everything to work fine in tele...Autonomous is another story though!

    Every time we run it, something different happens.
    Hi FTC10211,

    We've had the same issues for weeks. I've been experimenting at home and have a theory about the random operation of motors. The team's Autonomous program was written to simply wait 15 second and then drive straight to zone. You'd think that'd be easy, right? Piece of cake in RobotC. The new system is a different story. I think there are bugs in FTC implementation of App Inventor vs. MRI motor controller. My testing indicates that the motor controllers are not getting the speed commands. It is random: any number of permutations of the motors (2 in out case) not getting the command to run or stop.

    See here for a discussion of "Hardware Cycles": http://ftcforum.usfirst.org/showthre...otor#post22743

    We made some improvements to our code, but still saw inconsistent performance, at our League Championship yesterday and opted to sit idle during Autonomous.

    My theory below. Still testing this...

    Comment


    • #3
      Finally... got position control to work w/ linear "FtcLinearOpMode" using encoders for "RunMode_RUN_TO_POSITION". Of course this is a test with 1 motor...

      Comment


      • #4
        Originally posted by FTC10211 View Post
        Please HELP!!!!

        We have had no issues getting everything to work fine in tele...Autonomous is another story though!

        Every time we run it, something different happens.

        I even started with a brand new program, no tele, only one auton, and it still gave us issues.

        We started fresh with a LinearOpMode, did a waitforstart, and just to try to get something consistent, we just did both motors same direction. Nothing extra.

        We had the same issue we have every time we try to run auton - 1 time it might work, next time only one motor turns, next time the opposite one turns, next it works right, next only one motor again, but opposite. We must have stopped and started it 35 times, and there was not even a pattern of which times it did what.
        I don't get it! There was nothing else in the program at all!

        We even tried the steps in this thread, but we run into the same issue, building it the exact same way they did.

        We are headed to the State tournament Saturday, and would love to actually be able to run an autonomous without fear of it just turning in front of our alliance mates.

        Thanks!

        We had the same problem! (Using android studio, not app inventor, but exact same symptoms.) What fixed it for us was switching to run_using_encoders and using a while loop to check if they are at position yet. That at least let us drive in a straight line (with a 15 second wait just in case). I think it will work to do more, but we will just build on previous encoder values and never use reset_encoders except for during init. Reset_encoders can take a few hardware cycles to complete. Speaking of which - make sure you put a "waitOneHardwareCycle()" inside of any while loop you have so the code doesn't get ahead of itself. Let me know if this is helpful and/or if you need more help/advice

        Comment


        • #5
          Thanks for the tips guys. I will be giving these a shot.
          I sure wish there was a faster way to test with app inventor! Would sure make debugging easier!

          CraigRochester - one thing I might be missing on your program. Will the time start at 'init' or at 'play'?

          Comment


          • #6
            Originally posted by FTC10211 View Post
            Thanks for the tips guys. I will be giving these a shot.
            I sure wish there was a faster way to test with app inventor! Would sure make debugging easier!

            CraigRochester - ... Will the time start at 'init' or at 'play'?
            The time based OpMode begins timing at "Start", sort of... It starts at Init, but stops at "WaitForStart". You get a very small fraction of a second if you put telemetry time before "WaitForStart".

            The position OpMode I see has a mistake and is referencing the wrong OpMode. :-o That's why I was getting random times...

            Comment

            Working...
            X