Announcement

Collapse
No announcement yet.

Questions and comments about the S/W architecture in FTC_APP

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

  • Questions and comments about the S/W architecture in FTC_APP

    I was looking for recommendations for best practices in library management. Philbot made good comments about leveraging the infrastructure delivered in FTC_APP and included sample OpModes. That sounds a prudent approach, but there are some issues in the current implementation and I am wondering how those will be addressed in subsequent releases.

    In nutshell, the current architecture there are three main components
    - com.qualcom.ftcrobotcontroller
    - opmodes within ftcrobotcontroller, no changes are required except
    > modify FtCOpModeRegister
    > create your own OpModes
    - External Libraries, these cannot be changed

    The PushBot OpModes is a good starting point for most FTC teams. There we have following class hierarchy

    Code:
    1. OpMode
       |-- 2 PushBotHardware
            | Define hardware assignments - GOOD
            | scale_motor_power - this could be in a separate module
            | wrapper functions for motor power
            | motor encoder management functions
            |-- 3. PushBotTelemetry
                 | update_telemetry function - GOOD
                 |-- 4.PushBotManual - registered
                 |-- 5.PushBotAuto - registered
    6. LinearOpMode
       |-- 7. PushBotDriveTouch - registered
       |-- 8. PushBotIrSeek- registered
       |-- 9. PushBotSquare - registered
    The interfaces to gamepads, motors, servos, and sensors are in External Libraries. These are not complete to cover all legal sensors, such as Bosch BNO055 Absolute Orientation Sensor. The questions are:
    - Should the new sensor interface go into
    > External Libraries
    > Local custom library
    > Robot Hardware Class (as in PushBotHardware)
    - What is the right location for general purpose utilities, such as a data logger
    - Where the State Transition Diagrams should go
    > Local custom library (this doesn't sound right)
    > Robot Hardware Class
    > Registered OpMode

    Cheers, Ollie

  • #2
    Further sensor support is coming in the next release.

    But I think one of the things you are struggling with is "where does all
    my team specific software go?" Whether that be libraries you develop
    yourself, or opmodes for you competition robots.

    A while back I turned the FTC SDK into a library that could be
    linked against any number of other code repositories.

    http://ftcforum.usfirst.org/showthre...on-%28True-SDK

    In this implementation, you just drop the SDK someplace,
    and you can create any number of other projects that link
    against it that contain any number of other software
    libraries you might develop. And presumably you could
    keep the changes from FIRST segregated from your
    robot software from year to year and update the SDK
    as needed independent of everything else you've done.

    This was done against the first version of the SDK released.
    I have not done the same for the most recent version of
    the SDK, although it would not be hard to do. I may or may
    not do the same for the official release coming in the next
    week or two. All depends upon time and interest from the
    community, and whether or not such changes would be
    competition legal.

    Comment


    • #3
      Originally posted by skatefriday View Post
      This was done against the first version of the SDK released.
      I have not done the same for the most recent version of
      the SDK, although it would not be hard to do. I may or may
      not do the same for the official release coming in the next
      week or two
      . All depends upon time and interest from the
      community, and whether or not such changes would be
      competition legal
      .
      I like the benefits available with this mechanism. My concerns are related to the potential resistance by FIRST (is this competition legal) and the long term availability, if a third party support is required for the new releases.

      In ideal case, I would like to see a path where the teams could have an evolution path starting with the basic things directly supported by FTC, and then incrementally adding new capabilities addressing the problems recognized by the teams. We are very close to the boarder line where the involved Computer Science technology is overwhelming for the team mentors and students.

      With LabVIEW and RobotC we had the situation that the teams were isolated from the system level issues and the focus was in robot specific code. We need to return back to that simplicity in the new Android/Java platform. For that, FIRST and Qualcomm need to provide infrastructure that is complete enough for allteams,from rookies to teams with college level CS skills.

      Comment


      • #4
        If you are uncomfortable with a local custom library, why don't you repackage the directory the OpModes are in?

        If you are redistributing the Sensor classes, don't add to your OpMode, package those separately; if not, feel free to add them into a class hierarchy. The general purpose ulities are gonna to be better outside of the OpModes package, but you can find them. The diagrams should be by your OpModes, wherever you put them.

        The goal when writing the OpModes, is to place in a place where anyone who can code, can read the source code, and figure what it does quickly without needing to ask anyone to clear something up (unless it is a basic question like: "What does a static modifier do in this context?") I purposely put ever one of the OpModes provided by FIRST into "com.qualcomm.ftcrobotcontroller.opmodes.examples, " then you should sort them into like catergories, "PushBot", "LinearOpMode,"etc., If your team wants the OpModes separate from the Qualcomm code, then repackage them into "ftc.omegafactor.opmodes," "org.sigmafactor.opmodes," or "ftc.5395.opmodes.competition.auto" Just be descrivptive in the package names, and have a logical reason for, where you put your code.

        Comment


        • #5
          Could we get an official opinion on the legality of skatefriday's split-out SDK?

          Comment


          • #6
            Originally posted by archimedespi View Post
            Could we get an official opinion on the legality of skatefriday's split-out SDK?
            I can't imagine how a rule against this would work.
            And if there was a rule, how would they inspect for it?
            Doing that would require build and code inspection at the competitions. I can't see that happening.
            Mark Hancock
            Tigard Team Mentor

            Comment


            • #7
              Originally posted by markshancock View Post
              I can't imagine how a rule against this would work.
              And if there was a rule, how would they inspect for it?
              Doing that would require build and code inspection at the competitions. I can't see that happening.
              Chuckle. My first year mentoring, I had no experience
              with the program, and the team was talking
              about software inspection and my first thought was, "they
              are going to do a code review of our team's software?"

              Comment


              • #8
                Originally posted by skatefriday View Post
                Chuckle. My first year mentoring, I had no experience
                with the program, and the team was talking
                about software inspection and my first thought was, "they
                are going to do a code review of our team's software?"
                I thought the same, except I was only informed about this 15 minutes before robot inspection.

                Comment


                • #9
                  Originally posted by skatefriday View Post
                  Chuckle. My first year mentoring, I had no experience
                  with the program, and the team was talking
                  about software inspection and my first thought was, "they
                  are going to do a code review of our team's software?"
                  Originally posted by dmssargent View Post
                  I thought the same, except I was only informed about this 15 minutes before robot inspection.
                  Yep, when I first head about SW inspection, I thought of a code walk-through to; but I asked our main lead and he told me it was only a field check. Kind of a bogus name; but, now it is gone.

                  Mark
                  Mark Hancock
                  Tigard Team Mentor

                  Comment

                  Working...
                  X