Announcement

Collapse
No announcement yet.

FTC Robotics Library

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

  • FTC Robotics Library

    My team, who needs to Java training, and I, who can use all the practice I can get, should be releasing an alpha version of a library to help with the standard OpMode style of programming, and our own RunLevel style of programming.

    Our Features:
    - Customizable, Integrated HTTP web server
    - A unified single object to handle and/or control every other necessary object (contains the Gamepads,
    HardwareMap, Web Server settings, logging, app context, etc.)
    - Annotated OpModes (automatically sorted alphabetically and the ability to group OpModes, automatically discovered at run-time). Credit: @math222, and their team, for the basic code
    - RunLevel system (our form of linear programming for the autonomous routine)
    - Callbacks (in the case of object creation within main loop method, for exceptions, or just in general)
    - Automatic change-over to Read or Write mode after a specifiable amount of loops, also overridable
    - The ability to specify a function to run before or after the main loop at a certain loop number
    - The ability to run a function every X numbers of loops
    - Automatic loop counting (and maybe end of loop time stamping)

    If we wanted to get adventurous:
    - Bundling a SPA, AngularJS-based Web Dashboard for the Robot
    - Have the ability to automatically reinterpret motor output and joystick input, ex. if you accidentally (or purposely) said "motor.setPower(90)" it would turn it into "motor.setPower(0.9)" and/or if we wanted it to be scaled by .8 "motor.setPower(0.72)"

    Does anyone want to know something, request something, want their stuff integrated?

  • #2
    Since we are prepping for a development release (we didn't finish the documentation .) I thought I would share a basic example of an OpMode created with our library.
    Code:
    package org.ftc.opmodes;
    
    import org.ftccommunity.ftcxtensible.RobotContext;
    import org.ftccommunity.ftcxtensible.opmodes.Autonomous;
    import org.ftccommunity.ftcxtensible.robot.ExtensibleOpMode;
    
    import java.util.Date;
    import java.util.LinkedList;
    import java.util.logging.Level;
    
    @Autonomous(name = "Hello World Example")
    public class HelloWorld extends ExtensibleOpMode {
        @Override
        public void init(RobotContext ctx, LinkedList<Object> out) throws Exception {
            ctx.enableNetworking().startNetworking();
        }
    
        @Override
        public void start(RobotContext ctx, LinkedList<Object> out) throws Exception {
            ctx.telemetry().addData("TIME", "Start Date: " + 
                    (new Date(System.nanoTime() / 1000)).toString());
        }
    
        @Override
        public void loop(RobotContext ctx, LinkedList<Object> out) throws Exception {
            ctx.getStatus().log(Level.INFO, "LOOP", "Current loop count: " + getLoopCount());
            ctx.telemetry().addData("MESS", "Hello, World!");
            ctx.telemetry().addData("MESS", "How are you doing?");
        }
    
        @Override
        public void stop(RobotContext ctx, LinkedList<Object> out) throws Exception {
            ctx.getStatus().log(Level.WARNING, "TIME", "End Date: " + 
                    (new Date(System.nanoTime() / 1000)).toString() + "This ran for " + getRuntime());
        }
    
        @Override
        public void onSuccess(RobotContext ctx, Object event, Object in) {
            // Don't worry about this; it is used for the advanced stuff
        }
    
        @Override
        public int onFailure(RobotContext ctx, Type eventType, Object event, Object in) {
            // Return the default value; for when things go south
            return -1;
        }   
    }
    No need to register anything within the FtcOpModeRegister (thanks to Maths222).

    Comment


    • #3
      Since I can't actually thoroughly test our code on a RC (system configuration went all whacky), does anyone want a release of what we have?

      Comment


      • #4
        Our first development release (sorry about the lack of documentation still, please ask questions):
        https://github.com/dmssargent/Xtensible-ftc_app

        Your OpModes go in the OpModeLibrary module, instead of the FtcRobotController

        Comment


        • #5
          I'm guessing this was developed on windows?

          You had some issues with case sensitivity in file/directory names. I spent an hour trying to get it to import before I renamed ftcxtensible to FtcXtensible and opmodelibrary to OpModeLibrary.
          FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
          Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

          Comment


          • #6
            Primarily, yes. I spent the majority of today straightening out Git in this repo. I will fix that issue.

            Comment


            • #7
              I fixed the case sensitive issue, rearranged code, added some more documentation, added UI thread processing, added async processing, corrected an App Context issue (you are given an App Context in the constructor, and an Activity Context in the main code portions).

              If you want to help out on the camera, feel free to help, the current code only sorta of works (as in I have a working full-screen preview that does not go away, but it does not require modification of the bundled XML's).

              Comment


              • #8
                Originally posted by dmssargent View Post
                I fixed the case sensitive issue, rearranged code, added some more documentation, added UI thread processing, added async processing, corrected an App Context issue (you are given an App Context in the constructor, and an Activity Context in the main code portions).

                If you want to help out on the camera, feel free to help, the current code only sorta of works (as in I have a working full-screen preview that does not go away, but it does not require modification of the bundled XML's).
                I have a fork that handles the camera, but due to the casing issue and such it has diverged too greatly to be merged, as far as I can tell. I might try to merge your latest changes on a copy of ours and see how it turns out later today. We do have camera code, with one XML modification done at the library level, and then one can use the camera by creating a CameraHelper, adding a callback, and calling attach() on it.
                FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
                Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

                Comment


                • #9
                  We added OpMode Versioning to our library (via a @RobotSdkVersion(RobotSdkApiLevel.R3_2015) annotation), also it has upgraded to today's release. We still need new testers!

                  Our SDK version format is the release number (currently R3 for "stable release 3" + "_" + year in which release happened)

                  Comment


                  • #10
                    Is there anything a team would like to see?

                    See the README in GitHub to use the latest API

                    Comment


                    • #11
                      Now that we have semi-stable phones and a working drive train, I will have our more advanced coders work with your SDK while my beginners still use the cut and paste technique.


                      Team 8881
                      Pirates of the Pacific

                      Comment


                      • #12
                        Originally posted by dmssargent View Post

                        Does anyone want to know something, request something, want their stuff integrated?
                        Due to motor loading, non-equal friction in left -vs- right and front -vs- back, our 2WD (Tank Treads) and 4WD slowly turns to the left.

                        Have you thought of anything to automatically correct for slight mismatches in voltage through the PDM, friction losses, etc. so that by use of encoders (assuming encoders are accurate in counting portions of motor revolutions) one can automatically apply a scale factor to keep the left and right drive trains within some level of tolerance (say +/- 1%) to minimize the turning over long distances in Autonomous?

                        I was thinking of a check within the encoder comparison routine that would scale the power if the difference between the left and right encoders exceeded a certain tolerance.

                        Team 8881
                        Pirates of the Pacific

                        Comment


                        • #13
                          You could do that within the a specific controller firmware, or I could re implement that behavior has long as I can read the encoder counts. The main idea of I have in that regard is to scale the motor power to correct for the overall battery difference, if you need the certain power to be maintained regardless of the battery level (which could also be achieved with encoders).

                          Note that I haven't corrected the readme's just yet, I am about to update them, the develop branch gets any bug fixes and new features, the master gets semi-tested coded (my team is still waiting for robot electronics hardware, I have the DS and RC), and the autonomous branch is having a major overall. If there is a bug you need fixed in the master, check the develop. Also, note that the API should be considered unstable (I marked the ones that could change with @Beta and @Alpha on the class itself), but it is stable enough to work with, the only major fronted change pending is remove the "get" of some more of the function names.

                          Comment


                          • #14
                            With tank treads, it is very typical that there is dynamic variability between the left and right side. This cannot be compensated with any static bias settings. In practice, the only way to get a tank with treads to go straight in either autonomous or remote control mode, is to use gyro based closed loop control.

                            Tanks with wheels are more predictable in that sense, but them too would greatly benefit of using a gyro sensor.

                            Comment


                            • #15
                              Is there a reason to not simply use the RUN_USING_ENCODERS RunMode in the SDK? Looks like this would be much more accurate than a software-level correction since the corrections are being done constantly by the motor controllers.

                              Comment

                              Working...
                              X