ftctechnh / ftc_app Goto Github PK

The robot controller app is consistently throwing exceptions during robot initialization. The exact error seems to be a problem in the way that the app is interfacing with the Android SDK. Our team is running the app on a ZTE Speed with Android version 4.4.4, and version 1.2 of the FTC robot controller. The full stack trace of the exception is shown below:

Activity com.qualcomm.ftcrobotcontroller.FtcRobotControllerActivity has leaked IntentReceiver com.qualcomm.analytics.Analytics@420f8aa8 that was originally registered here. Are you missing a call to unregisterReceiver()?
android.app.IntentReceiverLeaked: Activity com.qualcomm.ftcrobotcontroller.FtcRobotControllerActivity has leaked IntentReceiver com.qualcomm.analytics.Analytics@420f8aa8 that was originally registered here. Are you missing a call to unregisterReceiver()?
    at android.app.LoadedApk$ReceiverDispatcher.<init>(LoadedApk.java:796)
    at android.app.LoadedApk.getReceiverDispatcher(LoadedApk.java:597)
    at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1520)
    at android.app.ContextImpl.registerReceiver(ContextImpl.java:1500)
    at android.app.ContextImpl.registerReceiver(ContextImpl.java:1494)
    at android.content.ContextWrapper.registerReceiver(ContextWrapper.java:467)
    at com.qualcomm.analytics.Analytics.register(SourceFile:209)
    at com.qualcomm.analytics.Analytics.<init>(SourceFile:235)
    at com.qualcomm.modernrobotics.ModernRoboticsUsbUtil.init(SourceFile:85)
    at com.qualcomm.ftccommon.FtcEventLoop.init(SourceFile:89)
    at com.qualcomm.robotcore.eventloop.EventLoopManager.a(SourceFile:496)
    at com.qualcomm.robotcore.eventloop.EventLoopManager.setEventLoop(SourceFile:417)
    at com.qualcomm.robotcore.eventloop.EventLoopManager.start(SourceFile:369)
    at com.qualcomm.robotcore.robot.Robot.start(SourceFile:58)
    at com.qualcomm.ftccommon.FtcRobotControllerService$b.run(SourceFile:160)
    at java.lang.Thread.run(Thread.java:841)

The full log file that this excerpt was taken from is available here. The included exception occurs on line 7746 of the file.

Our team is unable to test anything at the moment, because the app will not survive past the initialization routine. We will continue to look into additional causes of the error, but in the event that FTC's code is the fundamental cause of the error, teams will be almost completely powerless to fix it.

Due to the use of reflection to store OpModes, trying to run a non-OpMode class as an OpMode throws some cryptic errors at runtime. It seems like this could be pretty easily solved by changing the method signature of OpModeManager.register() from public void register(String name, Class opMode) to public void register(String name, Class<? extends OpMode> opMode).

complieSDKVersion is currently listed as "Google Inc.:Google APIs:19". This is incorrect version naming for default Android Studio setup. Should be listed "android-19".

//assuming we have a GyroSensor named gyro
gyro.getRotation(); //returns a double, but it isn't explained what this represents

I couldn't find enough info in the javadocs, does this return the rate of rotation or the rotation angle? And is the angle a quaternion, Euler angle, etc. ?
Also, this is all assuming this refers to a GyroSensor that is one of the new sensors, not the Built in or legacy ones, right?

After many hours of testing for problems relating to #70, we have found the error to be in a limit of data transfer size when the Robot Controller transfers OpMode's to the Driver Station. Currently, it is limited to 256 bytes of data, which is not enough for use of the Thunderbots Robot Controller with a large number of OpModes. Is it possible to set the limit to something impossibly high, say around 5KiB, or just completely remove the limit?

Hello,

Would it be possible to get the source .jars for the jars in the libs directory

• FtcCommon-release.aar (the App Activity classes and UI elements)
• RobotCore-release.aar (the framework base and utility classes)

Many of the students on the team are new to JAVA and just get introduced to the JAVA language and having the source code of the classes we use (like OpMode, HardwareMap, etc) would be very educational. Some of the students are familiar to the Java SDK and were hoping to see an annotated source code, similar to how JAVA SDK is released, to better understand how the code is written.

And from the 'android' app side it was nice to have the source code for the various Activities used by the RobotController and DriverStation projects so that the kids could possible learn about Android software development elements.

Thanks for all that you have done!

Even though the user icon glows green on the DS when you push the "back" button on the gamepad, it does not get reported through the gamepad object.

The current isBusy() motor status is not indicative of whether the motor has reached the target encoder position. It simply indicates that the motor is currently not moving, which could be occurring for a number of reasons (not started yet, stall, hardware failure). It would be more accurately named isStopped().

In order for the isBusy() status to be useful, as soon as a new encoderTarget is set, isBusy() must return true, and it should remain true until the actual target is reached. Otherwise the user must gate it by manually reading the current position. This defeats the purpose of having an isBusy() status.

isBusy() should (at minimum) compare the actual encoder value with the last commanded encoder target, and apply a pre-defined match window. isBusy() could be extended to isBusy(int Window) where the user can define the +/1 position matching window desired.

The current isBusy() code could/should be reused as a new isStopped() method that teams could use to detect motor stall conditions.

The Lego NXT Color Sensor is not working for us. Will this be supported in the future?

And I am having troubles my team wants me to program the robot to go straight then turn and this is my first year doing android could I get a push in the right direction for this program it would be very helpfull

Feature request for DriverStation (DS) & RobotController (RC) "sanity checks":

• DS & RC check for FTC legal WiFi-Direct names:
  • RC doesn't create WiFi-Direct group unless WiFi-Direct name of RC is FTC legal, and
    • no newline characters
  • DS doesn't attempt to pair with RC unless WiFi-Direct name of DS is FTC legal, and
    • no newline characters
    • team number portion of RC name matches team number portion of DS name
• DS checks version of RC and disconnects if DS version is incompatible with RC version
• Any other useful check that the DS and RC can make

Abstract classes artificially constrain implementation approaches. Pure interfaces capture the essentials of the API contract without impacting choices of implementation. ColorSensor, CompassSensor, etc should be interfaces, not abstract classes.

Can you please provide an example or explain how to use an i2c device like a gyro

It is necessary to perform a "Restart Robot" operation after downloading to the Robot Controller. Unfortunately this only works from the Robot Controller phone. This makes it hard for wireless downloading or even for wired downloads in cases where it is difficult to reach the menu buttons on the screen.

There is an equivalent ""Restart Robot" menu option on the Driver Station phone that does not seem to do anything.

Can this be fixed?

Every other HardwareDevice seems to return some string, but LED objects return null when getDeviceName() or getConnectionInfo() are called.

This is my configuration file:

<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<Robot>
    <MotorController name="Accessories" serialNumber="AL00VD65">
        <Motor name="bucket" port="1" />
        <Motor name="arm" port="2" />
    </MotorController>
    <DeviceInterfaceModule name="DIM" serialNumber="AL00VDDK">
        <I2cDevice name="bno055" port="0" />
    </DeviceInterfaceModule>
    <MotorController name="Left" serialNumber="AL00VESE">
        <Motor name="F" port="1" />
        <Motor name="G" port="2" />
    </MotorController>
    <LegacyModuleController name="Legacy Module" serialNumber="AL00VBU7">
        <ServoController name="Servos" port="0">
            <Servo name="roller" port="1" />
            <Servo name="climber" port="2" />
        </ServoController>
    </LegacyModuleController>
    <MotorController name="Right" serialNumber="AL00VFH4">
        <Motor name="D" port="1" />
        <Motor name="E" port="2" />
    </MotorController>
</Robot>

There is a servo controller on a Legacy Module with servos attached on the first two channels. However, the HardwareMap indicates that there are servos on ports 1, 2, and 6. When I iterate over all the servos in hardwareMap.servo and print out the connection info, I get the following:

USB AL00VBU7; port 0; port 6
USB AL00VBU7; port 0; port 1
USB AL00VBU7; port 0; port 2

The ghost servo also appears in the app's logcat:

========= Device Information ===================================================
Type                                          Name                           Connection
Modern Robotics USB DC Motor Controller       Right                          USB AL00VFH4
Modern Robotics USB DC Motor Controller       Accessories                    USB AL00VD65
Modern Robotics USB DC Motor Controller       Left                           USB AL00VESE
Analytics detected NetworkInfo.State.CONNECTED
DC Motor                                      D                              USB AL00VFH4; port 1
DC Motor                                      E                              USB AL00VFH4; port 2
DC Motor                                      F                              USB AL00VESE; port 1
DC Motor                                      G                              USB AL00VESE; port 2
DC Motor                                      arm                            USB AL00VD65; port 2
DC Motor                                      bucket                         USB AL00VD65; port 1
NXT Servo Controller                          Servos                         USB AL00VBU7; port 0
Servo                                         NO DEVICE ATTACHED             USB AL00VBU7; port 0; port 6
Servo                                         roller                         USB AL00VBU7; port 0; port 1
Servo                                         climber                        USB AL00VBU7; port 0; port 2
Modern Robotics USB Legacy Module             Legacy Module                  USB AL00VBU7
Modern Robotics USB Device Interface Module   DIM                            USB AL00VDDK
I2cDevice                                     bno055                         USB AL00VDDK; port 0
Modern Robotics USB DC Motor Controller       Right                          USB AL00VFH4
Modern Robotics USB DC Motor Controller       Accessories                    USB AL00VD65
Modern Robotics USB DC Motor Controller       Left                           USB AL00VESE

For teams who are only getting servos by name, this probably isn't such a problem, but it becomes apparent when trying to target all the servos regardless of the configuration file.

When we were using robotc last year, all we had to do to activate PID control. Is there a system like this for the new system? I skimmed through the documentation and there doesn't see to be any support for it except things like motor.setEncoderTarget();.PID control was super useful and new teams may not even realize they need to put a system in place to smooth out the motor.

I'm trying to run the code colorsensordriver.java and after fixing some of the obvious issus like haveing the wrong maping and stuff I ran into an exception that didnt really give me much insite into the problem. "User code threw an uncaught exception: null" is the error it threw. If any more information is needed just ask. If anyone has had this happen to them and knows how to fix it, please let me know.

Is the 3 axis gyro supported yet? I can't find any documentation on the website or in the doc folder.

I cannot seem to get the Logitech F310 joystick working on many (european) Android phones.
With the switch in "X" position it is seen as a USB device with VID=0x046d and PID=0xC21D, but the DriverStation app does not detect the joystick.

(I can see the USB data from the controller when I use the tincore App on the same phone).

See for more information:
https://github.com/pbrier/ftc_app/wiki/Logitech-F310-controller
https://github.com/pbrier/ftc_app/wiki/Tested-Devices

Hello, I am a member of a rookie FTC team. With the latest release of the FTC app, we have started to encounter issues with the robot state "EMERGENCY_STOP". It seems to call itself and shut down our robot unpredictably.
Oftentimes this happens when our robot is on the mountain and is jarred, even with nothing but the drive motors attached. When the robot is level and we shake it, even bang on our securely-mounted electronics, the app continues to run. If we take the phone off its mount and shake it/turn it upside down, the app continues to run.
However, if we attach the phone to the robot and tilt the robot like it was climbing the mountain, even a little shaking of the robot will cause the app to set the robot state to EMERGENCY_STOP. This is a major problem because resetting the robot state requires restarting the app multiple times, something that could not happen during the competition.
We have tried to find the line of code which is triggering this condition. However, there is only one "line" of functions, each calling one another, that involve this robot state. This quickly leads us into a closed section of the FTC code which we cannot access.
Any suggestions?

Thank you!

When writing motors and servos to legacy controller outputs, only the last change is transferred, ignoring all previous writes.

See also:

http://ftcforum.usfirst.org/showthread.php?4285-Please-Help-problem-with-buffer-overwriting-when-writing-to-our-cloned-Legacy-Module

For some reason, when we try to use the driver controller app from the play store with this app, the app spits out "Unknown command CMD_SET_OP_MODE" in the logs.

Team 9964

I created an OpMode to return Android sensor values, in this case related to device orientation.

Do we know if FTC teams going to be allowed to use the phone sensors?

Is there a way to do this with RobotCore or some other API in that's been included?
I didn't see anything, but only looked briefly.

To do it I had to save the application context from FtcRobotControllerActivity and make use of the Android Sensor classes. The following is a link to GitHub compare to show what I changed and what I added to make it work: acharraggi/my_ftc_app@v0.1...v0.2

It seems to work OK. I'm just not sure if it's safe to do (thread safe or any other kind of safe: such as proper un-registering of the sensor listeners in all cases). I don't have the new hardware yet to test using both together.

What do you think?

This is an issue that effects robot/user safety.
When a particular series of events occur, the robot can start running expectantly, posing a safety risk.

The issue occurs when the user stops a running robot by hitting the phone's BACK or HOME button by mistake.

When this occurs, the driver station appears to simply stop sending control packets to the robot. The stop() method is not called. So, if the driver was driving firward quickly, the robot continues to drive forward even if the driver releases the joysticks. After a short period, the robot detects the loss of communications and shuts down.

This run-on is somewhat serious but it's not completely unexpected. HOWEVER the real safety issue occurs the next time the user goes to run the opmode.

If the driver re-selects the Driver Station app and runs it, (performing the usual opmode selection, init and play) the robot will start executing the last gamepad command it received, which may cause it to start driving forward at full speed (unexpected and dangerous).

How the user gains control of the robot will depend on how they terminated the program last time. If they exited by pressing HOME, then the gamepads are still assigned and any joystick movement will regain control of the robot. However, if they exited using BACK then they will need to re-assign the gamepad (using start A) before they can regain control.

FIX: It seems important that:

1. On seeing the app loosing focus, the stop() method should be called
2. On seeing an INIT Press, the Driver Station should clear out any defunct gampepad input.

Modern Robotics has informed FIRST that they suspect that some of the early production Core Power Distribution Modules might have a hardware issue that can cause inconsistent behavior with the device's built-in USB hub. Devices that are affected might make it difficult for the Android Robot Controller to detect USB modules (such as the motor controller, servo controller, legacy module, and/or device interface module) that are connected through the Power Distribution Module's USB hub.

The problem requires that the module be sent back to Modern Robotics to have a part replaced on the device.

FIRST has requested from Modern Robotics additional information to help identify potentially suspect Power Distribution Modules, but currently we do not have a serial number range that can help us identify the devices which might be affected by the issue.

Modern Robotics has created a very handy utility program that can be run on a PC that can be used to scan and check all of your Modern Robotics modules (servo, dc motor, legacy and device interface). It can also be used to check your Power Module (if your PC can detect and communicate with the Modern Robotics devices that are connected through the Power Module reliably, then it's most likely a good Power Module). You can find information about the utility at the following web page:

http://modernroboticsinc.com/coredevicediscovery

If you are experiencing inconsistent USB connection issues that cannot be explained by problems with loose wiring or low battery voltage, then you should contact Modern Robotics for technical assistance to determine if you have a problematic device.

http://modernroboticsinc.com/contactus

The comments in the portion of the code that switches the Controllers connected to the legacy module from READ_ONLY to WRITE_ONLY lead me to believe that you can optimize the code. Questions/concerns:

What is the reason for resetting the numOpLoops to 0 at the end of the if (READ_ONLY) block? The previous block checks for the number of loops using the Modulus operator. Therefore, this is not needed for entry in the previous block. Is it because you will overflow the integer (int numOpLoops) by the end of a 2-1/2 minute run period?

If that is the case, why are you using the Modulus operator instead of if(numOpLoops == 17) in the previous block. This would save you processing time as you no longer need to perform the mathematical operation before the comparison test.

Might it be a suggestion to make the default text in the Joystick area the following:

"Press [START] + [A] Button to assign" (on the left side)
"Press [START] + [B] Button to assign" (on the right side)

To make it more intuitive for the operator what to do when a joystick is attached.

The XML configuration files are stored in /sdcard/FIRST but the name of the selected one is not. This means that the configuration files persist when you update the app or build it from a new computer, but the selected file is not. For teams who plan to use multiple computers to build the app, it would be nice to save the name of the selected file so that they don't have to constantly re-activate it.

The Readme.md file appears to have the wrong version number.
It says "20150803_001" instead of "20150918_001"

Currently the Javadoc descriptions for many of the classes in the API don't really provide much description; they're the same thing as the name of the class. Possibly it could be helpful to describe in more detail the functionality and use of each package and class.

We are unable to import the Color Sensor files even though they are in the directory. Can you fix this?

There is no type HiTechnicNxtGyroSensor for HardwareMap. Using gyroSensor instead when the object is created like HiTechnicNxtGyroSensor GyroSens returns the error
Error:(81, 43) error: incompatible types required: HiTechnicNxtGyroSensor found: GyroSensor
and using the type HiTechnicNxtGyroSensor returns the error
Error:(81, 28) error: cannot find symbol variable HiTechnicNxtGyroSensor

I am fairly sure I explored all the possibilities and its actually a bug, but I am not sure as I can't see the source code for the hardwaremap function.

Hello Github!

I have recently been trying to use a gyro with our autonmous code (which should be easy) but the GyroSensor class was empty. I did some googleing and found that this was "fixed" in the latest release. I immediately downloaded the zip and very very carefully combined my working directory with the update. I know my way around android projects, so this was pretty straight-forward. After updating, however, FtcRobotControllerActivity.java (which i pulled from the update) started throwing errors about the library com.qualcomm.hardware.HardwareFactory not existing. This is a problem. The latest release should come with working files. Does anyone know what AAR files contains this, or know of another way to fix this?

When connected, the Driver Station app is unable to load the OpMode drop down list.

Observed rules of telemetry.addData(key,message);
Rule A) items with unique keys are listed separately in alphabetical order
Rule B) multiple writes with the same key will overwrite the original entries in place

Issue 1: Items entered with unique keys should appear on the display in the order that they are entered. Please take out the re-sorting by key in alphabetical order. This make it difficult to debug time sensitive events.
It is possible to place a timestamp in the key so as to influence the order of the display however that will violate Rule B above. ( meaning you will never be able to overwrite an existing row)

If any read function is called, for example arm.getCurrentPosition() where arm is the hardware mapping for the motor connected to the Hi Technic Motor Controller or controller.getMotorCurrentPosition(port) were controller is the hardware mapping for the controller, it fails reading:
User code threw an uncaught exception. Cannot read while in this mode: WRITE_ONLY from method: Then the method used.

I'm not even sure what happened here, but this is probably wrong.
https://github.com/ftctechnh/ftc_app/blob/b4b71b2949/.gitignore#L27-29

Press Start-A on a gamepad. The icon above User 1 appears.
Press Start-B on the same gamepad. The icon above User 2 appears. However, the icon above User 1 doesn't disappear. At this point only one gamepad is active, but two icons are shown.
Press Start-B on the other gamepad. Both icons are shown, but the first gamepad no longer operates the robot.
The team/FTA/CSA/etc. may become confused seeing both icons when only one gamepad is active.

I have tried many code cleanup websites, but the issue the Studio is telling me is that I cannot resolve the symbol of OpModeRegister and I cannot resolve the method of .register. What is wrong and what must I do?

FtcRobotController/build.gradle instructs Gradle to try to build the app using Android SDK 21, which doesn't make sense given that it is designed for SDK 19 and SDK 22 is the newest release version.

This was the only interesting feature in the log, it was just before it crashed:
Fatal signal 13 (SIGPIPE) at 0x00001522 (code=0), thread 5410 (sh)
11-06 16:21:29.816 I/Timeline( 5458): Timeline: Activity_idle id: android.os.BinderProxy@41951900 time:991409

Before the beta release, there was sufficient documentation here. But now, with the changes, the methods and way of using them is not really explained. I suggest an example piece of code and/or a bit more explanation.

I am not sure whether it happens every time, but it seems that usually pressing the stop button during the loop() stage of an OpMode successfully stops the OpMode but leaves the stop button visible on the screen. It is only when pressing the stop button again that it becomes the INIT button.

Is there a way to create multiple threads in a LinearOpMode to allow me to do things like constantly update sensor variables in the back ground or add a timer to automatically stop the program?

It appears that the function getCurrentPosition() does not ever update inspite of the fact that motor moves and in spite of the fact that rotations are being recongized by the rotatry encoder. PID is working so the motor controller must be registering the rotations in some way. I know that PID is working because the motor ramps up it's power after moving.

Here are the related global variables.

    DcMotor[] arm;
    DcMotorController armzeroctl;
    int armzeroid;
    boolean whichArm=true;
    boolean quearmize;
    double speedArm=6.;
    double armzeropos;
    int lastarmzeropos;
    boolean armzerobusy;

Some of these variables are initalized in init() as so. I based my code off of the K9TeleOp class.

       arm=new DcMotor[2];

        arm[0] = hardwareMap.dcMotor.get("arm0");
        arm[0].setMode(DcMotorController.RunMode.RUN_USING_ENCODERS );

        armzeroctl=arm[0].getController();
        armzeroid=arm[0].getPortNumber();

In loop() I have the following code

           if(armzeroctl.getMotorControllerDeviceMode()==DcMotorController.DeviceMode.WRITE_ONLY) {
                if((!armzerobusy)&&quearm) {
                    int armposround=(int)armzeropos;
                    arm[0].setPower(.01);
                    arm[0].setTargetPosition((int) armzeropos);
                    quearm=false;
                    lastarmzeropos=(int)armzeropos;
                }
                arm[1].setPower(scaleInput(gamepad2.right_stick_y));
                armzeroctl.setMotorControllerDeviceMode(DcMotorController.DeviceMode.READ_ONLY);
            }else if(armzeroctl.getMotorControllerDeviceMode()==DcMotorController.DeviceMode.READ_ONLY){
                armzeropos -= (scaleInput(gamepad2.left_stick_y) / speedArm * 32.);
                if(((int)armzeropos)!=lastarmzeropos){
                    quearm=true;
                }
                armzerobusy=arm[0].isBusy();
                telemetry.addData("Arm", String.format("Position %d Target copy: %d Target: %d busy: %b", arm[0].getCurrentPosition(),arm[0].getTargetPosition(), (int) armzeropos,armzerobusy));
                armzeroctl.setMotorControllerDeviceMode(DcMotorController.DeviceMode.WRITE_ONLY);

            }

Upon viewing the telmetry data I noticed that getTargetPosition() is always zero and most likely because of this the motor never stops. I used the Netbeans decompiler and I am baffled by this issue because of the following:

    public int getMotorTargetPosition(int motor) {
        this.a(motor);
        this.b();
        byte[] var2 = new byte[4];

        try {
            this.c.lock();
            System.arraycopy(this.b, OFFSET_MAP_MOTOR_TARGET_ENCODER_VALUE[motor], var2, 0, var2.length);
        } finally {
            this.c.unlock();
        }

        return TypeConversion.byteArrayToInt(var2);
    }

    public int getMotorCurrentPosition(int motor) {
        this.a(motor);
        this.b();
        byte[] var2 = new byte[4];

        try {
            this.c.lock();
            System.arraycopy(this.b, OFFSET_MAP_MOTOR_CURRENT_ENCODER_VALUE[motor], var2, 0, var2.length);
        } finally {
            this.c.unlock();
        }

        return TypeConversion.byteArrayToInt(var2);
    }

This is from HiTechnicNxtDcMotorController.class and we can see that getMotorTargetPosition() is using reading from the array which is called b. Values returned by getMotorTargetPosition() are correct. However getMotorCurrentPosition() always returns zero. At this point I do not know how to percede futher. What could be causing this issue?

When configuring the CDIM with more than one sensor (say COLOR_SENSOR and TOUCH_SENSOR), I am unable to save the configuration due to the following error:

The logcat merely echos the same error and provides no additional information as to the cause of the error. The configuration saves successfully when only one sensor is configured.

The repo is bloated with useless things such as 100MB worth of git history and this 70MB pdf full of images. Those should be linked, not included in the repo. This is terrible practice and a waste of bandwidth :(

Hi Folks,

Please post all questions/issues in the FTC Technology forum:

http://ftcforum.usfirst.org/forumdisplay.php?156-FTC-Technology

The Technology forum is where you should visit if you have questions, comments or issues regarding the new platform (including the FTC SDK).

Thanks,

Tom