Announcement

Collapse
No announcement yet.

Is there a plan to release Driver Station module source code?

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

  • #16
    Originally posted by FTC4211 View Post
    I was working tonight with the released sdk to try and see why there is such a latency between the calls of the "loop()" function. I decompiled the classes.jar files within .aar files in the "FtcRobotController\libs" path to look at how the code functions.

    For those interested the process to decompile the source is quite simple:
    1. Copy "RobotCore-release.ark", "ModernRobotics-release.aar", and "FtcCommon-release.aar"
    2. Rename the copied files to "RobotCore-release.zip", "ModernRobotics-release.zip", and "FtcCommon-release.zip" respectively and open like a normal zipped folder
    3. Copy out the classes.jar file within each zipped folder and rename to "RobotCore-release-classes.jar", "ModernRobotics-release-classes.jar", and "FtcCommon-release-classes.jar" respectively.
    4. Download JD-GUI java decompiler from http://jd.benow.ca/
    5. Open the ".jar" files that you created from JD-GUI to view the decompiled packages.


    Looking around in the decompiled source there are several interesting sections:

    In the 'EventLoopManager.class' file contained in the RobotCore-release package the section performing the loop operation is:
    Code:
            while (!Thread.interrupted())
            {
              while (localElapsedTime.time() < 0.001D) {
                Thread.sleep(5L);
              }
              localElapsedTime.reset();
              if (RobotLog.hasGlobalErrorMsg()) {
                EventLoopManager.this.buildAndSendTelemetry("SYSTEM_TELEMETRY", RobotLog.getGlobalErrorMsg());
              }
              if (EventLoopManager.g(EventLoopManager.this).startTime() == 0.0D)
              {
                Thread.sleep(250L);
              }
              else
              {
                if (EventLoopManager.g(EventLoopManager.this).time() > 2.0D)
                {
                  EventLoopManager.this.handleDroppedConnection();
                  Thread.sleep(1000L);
                }
                for (Iterator localIterator1 = EventLoopManager.h(EventLoopManager.this).iterator(); localIterator1.hasNext();)
                {
                  localObject1 = (SyncdDevice)localIterator1.next();
                  ((SyncdDevice)localObject1).blockUntilReady();
                }
                try
                {
                  EventLoopManager.i(EventLoopManager.this).loop();
                  for (localIterator1 = EventLoopManager.h(EventLoopManager.this).iterator(); localIterator1.hasNext();)
                  {
                    localObject1 = (SyncdDevice)localIterator1.next();
                    ((SyncdDevice)localObject1).startBlockingWork();
                  }
                }
                catch (Exception localException)
                {
                  RobotLog.e("Event loop threw an exception");
                  RobotLog.logStacktrace(localException);
                  
                  Object localObject1 = localException.getMessage();
                  RobotLog.setGlobalErrorMsg("User code threw an uncaught exception: " + (String)localObject1);
                  
                  EventLoopManager.this.buildAndSendTelemetry("SYSTEM_TELEMETRY", RobotLog.getGlobalErrorMsg());
                  
                  throw new RobotCoreException("EventLoop Exception in loop()");
                }
                finally
                {
                  for (SyncdDevice localSyncdDevice : EventLoopManager.h(EventLoopManager.this)) {
                    localSyncdDevice.startBlockingWork();
                  }
                }
              }
    ...

    Similarly within the decompiled "ReadWriteRunnable.class" file is the startBlockingWork() method. Unfortunately JD-GUI can't decompile it fully and the result is the java byte code:
    Code:

    Code:
     public void startBlockingWork()
      {
        // Byte code:
        //   0: aload_0
        //   1: getfield 71	com/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable:waitingLock	Ljava/util/concurrent/locks/Lock;
        //   4: invokeinterface 122 1 0
        //   9: aload_0
        //   10: getstatic 75	com/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable$BlockingState:BLOCKING	Lcom/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable$BlockingState;
        //   13: putfield 60	com/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable:blockingState	Lcom/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable$BlockingState;
        //   16: aload_0
        //   17: getfield 70	com/qualcomm/modernrobotics/readwriteloop/ReadWriteRunnable:waitingCondition	Ljava/util/concurrent/locks/Condition;
        //   20: invokeinterface 121 1 0
        //   25: aload_0
       // There is more on the original thread
    ...
    John Stegeman
    Team 4211
    The Bombers
    Jonathation Berling's quote was:

    Originally posted by Jonathan Berling View Post
    Be careful reading the decompiled AAR files. You're looking at obfuscated code.

    Under normal operations there are no sleeps between calls of an op mode loop method, nor before calls to an op mode start method.

    The reason we recommend that you return from an op mode loop method as quickly as possible is because the hardware doesn't get updated until after the loop method returns.

    The delay between calls to your loop method is simply that is how long it takes to write all of your commands to the hardware, and then the hardware to respond with its current state.

    If you have no hardware attached, then an op modes loop method will be called every 5ms.
    In any case I posted code that was already in the forum (though obstructed) and had already been attempted to be reverse engineered. At http://ftcforum.usfirst.org/showthre...ll=1#post14013

    My problem is that I found not found anything explicitly disallowing reverse engineering.

    Comment


    • #17
      I did not see this post orginally so, I will quote it here:

      Originally posted by Jonathan Berling View Post
      My main concern with people looking at the obfuscated code is that obfuscated code, by definition, is hard to read. Very little of the analysis was correct.

      While I would prefer to not talk about the source code that hasn't been released, I'm more than willing to talk about the API. If you have any questions start a new thread and ask them!

      I am also excited to see all of these projects spring up around the new code base. It is impossible for one API to meet everyone's needs. FTC is lucky to have such a great community that is willing to share their solutions to different problems they encounter.
      So, I agree that assumptions are going to be hard and maybe incorrect. I will also say this extends to any de-complied code, and obfuscation just makes life more difficult. I also believe that what I can read and what Qualcomm sees are most likely different. But, you do realize Android Studio can do this natively given a library?

      Comment


      • #18
        Originally posted by dmssargent View Post
        I did not see this post orginally so, I will quote it here:



        So, I agree that assumptions are going to be hard and maybe incorrect. I will also say this extends to any de-complied code, and obfuscation just makes life more difficult. I also believe that what I can read and what Qualcomm sees are most likely different. But, you do realize Android Studio can do this natively given a library?
        Yes, in fact Android Studio has been handling the obfuscated bytecode quite well in my experience. However, I would like to see source being officially available, and (graciously and professionally) believe that any agreement that does not give the community the ability to see (and improve upon) an open system is ultimately not necessarily in the best interest of the community as an whole.
        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


        • #19
          Originally posted by Alec View Post
          The old platform is governed by the licensing agreement(s) between FIRST and the old vendors.

          The new platform is governed by the licensing agreement(s) between FIRST and the new vendors.

          In Qualcomm’s licensing agreement with FIRST, I would be very surprised if Qualcomm has granted FIRST and FTC teams permission to post Qualcomm code on the Internet (or even for teams to decompile Qualcomm code for personal use).
          LOL. The old vendor was a very small team of volunteers
          run by John Toebes, who happened at the time to be working
          for cisco, but the project was neither endorsed nor funded
          by cisco.

          John won the FIRST volunteer of the year award for the
          FCS in the year of it's introduction IIRC.

          Comment

          Working...
          X