Announcement

Collapse
No announcement yet.

Slow game pad updates

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

  • Slow game pad updates

    I have just started to do some numeric observations in the new FTC platform. It was a disappointment to see that the game pad values are updated only around every 35 ms. This means that the same value is used in the control loop for 6 or 7 cycles and after that there is a significant change in value. My expectation was that the updates would be in the 5-10 ms range to allow fast and accurate control of the robot.

    These diagrams represent some changes in the joystick X and Y values.





    The cycle times in these observations are around 5 ms.

  • #2
    I display min/max/avg cycle times in my telemetry data as a crude character graphic.

    I normally see average cycle times of 10-12 ms. This is with 5 USB CORE device controllers.

    You are cycling much faster. Are you running with no external devices?

    Phil.

    Comment


    • #3
      These measurements were done with a bare bone system w/o any external devices. I am planning to do additional measurements by adding different type of devices one by one.

      The first library class that I created was a data logger that is creating CSV files, which can be easily processed in Excel either with simple trending or advanced VBA scripts. The WiFi File Transfer app in RC allows easy wireless access to these files from any browser.

      Comment


      • #4
        Did you perform this test with an OpMode or a LinearOpMode? I've been curious to know if there's any performance advantage to LinearOpMode since we don't really know what's happening between calls to loop().

        Comment


        • #5
          These tests were done with the "normal" OpMode without any modules. I did repeat the test with 6 connected modules and one AndyMark Neverest 20 motor. In that case, the loop execution interval increased to over 10 ms. It did vary between 8 and 20 ms.

          I need to look the qualcomm code for the game pad stick processing. It is possible that there is not a communication delay, but the characterization curve is really bad. A new stick value is available typically on every 30 - 40 ms, which is still too slow.



          In these motor drive tests, I was trying to move the stick very smoothly. This is not reflected with the actual observations.

          Comment


          • #6
            Originally posted by Ollie View Post
            I have just started to do some numeric observations in the new FTC platform. It was a disappointment to see that the game pad values are updated only around every 35 ms. This means that the same value is used in the control loop for 6 or 7 cycles and after that there is a significant change in value. My expectation was that the updates would be in the 5-10 ms range to allow fast and accurate control of the robot.

            These diagrams represent some changes in the joystick X and Y values.





            The cycle times in these observations are around 5 ms.
            Hi Folks,

            The gamepad refreshes are currently set around 30 msec as Ollie observed. Specifically, I'm referring to the refresh rate of when the Driver Station sends (wirelessly) updated gamepad status info to the robot controller.

            While it is possible to modify the SDK to decrease this period, please keep in mind there are other technical issues that we have to balance/address. If we decrease the gamepad refresh period, we effectively increase the stream rate per robot-driver station pair. In small venues, where there aren't too many robots (< 30 to 35 robots) this is less of an issue (the stream rates are all relatively modest). However, in crowded and noisy venues, since the current Android devices are limited to the 2.4GHz band we have to be careful with how much bandwidth each robot uses. One of our primary directives from the program people (i.e., the folks who run the competitions) was to make sure the new wireless control system was responsive and robust.

            In our testing last winter and this past spring with mentors and teams, a 30 msec window seemed like it was a good value for the refresh period.

            Tom

            Comment


            • #7
              Stick movement

              Tom,

              Thanks for the explanation. I do accept the reasons to reduce the update rates. I am still wondering two other things.

              1. In the stick increments the values can as small as 0.0078, but sometimes the increments are 0.0157. Could the increments be as small as 1/256 = 0.0039?
              2. Only portion of the stick movement is used. With the muscle memory from FPS games, the expectation is that the whole range will be used. Why the range is clipped?

              With Best Regards, Ollie

              Comment


              • #8
                Since the returned value is between -1 and 1, it means that you're limited to 1/128 (or 0.0078) for each increment.

                Comment

                Working...
                X