Announcement

Collapse
No announcement yet.

Array Queue for the FTC I2C Wire Library

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

  • Array Queue for the FTC I2C Wire Library

    I have published the code for ArrayQueue to enable the FTC teams to build their own I2C sensor interfaces
    using the FTC Wire Library.

    I am not aware of any other I2C interface implementation that would allow the I2C communication without any performance impact for the OpModes.

    If an OpMode uses a read command that waits a response from a I2C sensor, then the OpMode cannot do anything else during that time. The waiting time could be over 10 ms.

    With FTC Wire Library, the OpMode can continue immediately after a read request and then later get the read value once the reply is available.

    Cheers, Ollie

  • #2
    Originally posted by Ollie View Post
    I have published the code for ArrayQueue to enable the FTC teams to build their own I2C sensor interfaces
    using the FTC Wire Library.
    Ollie,

    I hope that these are not dumb questions, but I have several to ask:

    1). You said that you published the code for ArrayQueue to enable the FTC teams to build their own I2C sensor interfaces using the FTC Wire Library. Why and how would you use them together?

    2). If I wanted to add either one of both to my copy of the FTC SDK - where would I put the code? Would it go in the Op Modes folder, the FTC Robot Controller folder, or some place else?

    Thanks,

    Allen

    Comment


    • #3
      Allen,

      Thanks for extremely relevant questions. The answers are easy, in case your team is using similar project structure that I have used. In both these classes, the first line is

      package org.usfirst.FTC5866.library;

      This could be changed to org.usfirst.FTC<your team number>.library.

      There was some discussion about this subject in this thread

      http://ftcforum.usfirst.org/showthre...ary-management

      My recommendation is to read the postings in that thread and then to decide, what will be your team library practice.

      This is independent of using GitHub or not. The major selections are to have super classes for the team OpModes and use inherited methods or to have dedicated directory for classes used by multiple OpModes.

      Comment


      • #4
        Originally posted by Ollie View Post
        I have published the code for ArrayQueue to enable the FTC teams to build their own I2C sensor interfaces
        using the FTC Wire Library.

        I am not aware of any other I2C interface implementation that would allow the I2C communication without any performance impact for the OpModes.

        If an OpMode uses a read command that waits a response from a I2C sensor, then the OpMode cannot do anything else during that time. The waiting time could be over 10 ms.

        With FTC Wire Library, the OpMode can continue immediately after a read request and then later get the read value once the reply is available.

        Cheers, Ollie
        Out of curiosity, why did you choose to write your own Queue library instead of using something like ConcurrentLinkedQueue? Since you are only ever doing operations on the ends, it should be much faster than having to reallocate and copy elements whenever you need to grow the queue and doesn't result in memory being used to store more queue slots than are needed.

        Comment


        • #5
          GearTicks,

          That is totally valid question and my answer is not accepted by all, but perhaps understood by many. My background is in hard real-time control and for long time I have had and still have a distaste of using Java for those applications. In all places, where I can reduce the overhead and delays, I like to do it - even if not totally required.

          In this case, the synchronization within ConcurrentLinkedQueue is fully solving the internal inerlocks, but it is not solving the problem where the detection of an empty queue before addition or removal is required as a synchronized operation.

          By using an array that is expanded only in rare cases, the array acts as a fixed size array without any allocations. For performance, the Array Queue is faster than the ConcurrentLinkedQueue.

          Cheers, Ollie

          PS. I did start with ConcurrentQueue but switched to my own queue because of the required additional functionality and my personal experience of using Array Queue in hard real-time control.

          Comment


          • #6
            Originally posted by Ollie View Post
            I have published the code for ArrayQueue to enable the FTC teams to build their own I2C sensor interfaces
            using the FTC Wire Library. [...] With FTC Wire Library, the OpMode can continue immediately after a read request and then later get the read value once the reply is available.
            Ollie,

            All the examples that I saw in your library seem not to exploit this asynchronous ability, instead rather choosing, using spin loops, to implement what amounts to the usual synchronous reads and writes.

            Do you have examples of where the ability to initiate a read or a write operation but only later actually harvest the results is importantly exploited? That, I think, would be very interesting to see.

            Thanks for doing this.

            Comment


            • #7
              In the I2C Color Sensor with FTC Wire Library example there is the sensor initialization code

              private void initColorSensor() {
              cs = new Wire(hardwareMap,"Color",2*0x29);

              cs.write(0x80,0x03); // R[00] = 3 to enable power
              cs.requestFrom(0x92, 1); // R[12] is the device ID
              cs.write(0x8F,0x02); // R[0F] = 2 to set gain 16
              cs.write(0x81,0xEC); // R[01] = EC to set integration time to 20* 2.4 ms
              // 256 - 20 = 236 = 0xEC
              }


              It has a series of read and write commands that are executed without any delay.

              In the OpMode loop method, there is a call that is receiving the replies whenever they are available.

              public void loop() {
              if (isColorUpdate()) {


              I think that this is a really cool technology

              Comment


              • #8
                Originally posted by Ollie View Post
                In the I2C Color Sensor with FTC Wire Library example there is the sensor initialization code [...] It has a series of read and write commands that are executed without any delay. In the OpMode loop method, there is a call that is receiving the replies whenever they are available.
                Thanks. I had indeed missed that.

                If I'm reading it right, the writes you use here are all blocking, but the reads are non-blocking, which is nice.

                If I'm understanding it correctly, this approach is similar in behavior (but not quite identical) to the the use of II2cDeviceClient.READ_MODE.REPEAT read windows in the Swerve Library. When reading Euler vectors in the BNO055 IMU driver, for example, 99 44/100% of the time the getAngularOrientation() call does not block because such a ReadWindow is use and the data is already available.

                Thanks again.

                Comment


                • #9
                  Both reads and writes are non-blocking. The OpMode can use any number of read and write requests in any order in init, start, or loop methods.

                  Both reads and writes do generate a response with microsecond level response. The write response can be critical in that sense that a confirmed write could be a trigger for some other actions.

                  There is no "hurry" when the OpMode consumes the responses. They are all buffered. In the examples, if statement was used to consume one response at time. While statement can be used to keep the response queue as "clean" as possible. Because the sensors are slow, the if statement is always OK in practice. The garbage collection is the main reason that there could multiple responses could be there. For integration, such as for gyro sensors, the time stamp is useful in those cases.

                  This non-blocking feature allows multiple sensors to be totally active at the same time. With blocking, all sensors have to be served serially.

                  Cheers, Ollie

                  Comment

                  Working...
                  X