Announcement

Collapse
No announcement yet.

Frustrations With FTC Limitations (RobotC, Prototype Board)

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

  • Frustrations With FTC Limitations (RobotC, Prototype Board)

    Sorry if this is in the wrong forum, but I wasn't sure where to post it. Feel free to move it wherever appropriate.
    --

    Over the years, FIRST has somewhat demphasized of some of the other aspects of engineering a robot, namely the electronics and programming aspects. From a cursory glance, it looks sufficient- the NXT seems powerful enough to do perform everything that may be asked of a robot, with a nice C-based package on top. Teams may purchase HiTechnic sensors to add on to the NXT for sensing the environment. For basic routines: move the robot forward x, turn, check the light sensor, etc, this is fine. However, for more sophisticated techniques for automating the robot, the provided setup is insufficient.

    Let's take a look at the some of the goals that FIRST seems to have. There is a 30 second autonomous period, so they seem to at least recognize and emphasize the importance of autonomous control and the challenges associated. The inclusion of the IR beacon every year also seems to point towards this. The FTC portion of the FIRST website talks about applying "real-world math concepts" and this portion of the game seems like a great place to apply this.

    Now, what common methods do teams actually use in autonomous mode? They tend to use encoders and perhaps the IR seeker or the NXT color sensor. However, teams could go above and beyond this every year. They could use the HiTechnic accelerometer and gyroscope to get more information about their orientation and position. They could add on ultrasonic and other distance sensors to actively scan their immediate environment. With this, they could run AI and path-planning algorithms instead of hoping their preplanned route doesn't suddenly coincide with another robot's. There's a lot of potential here.

    How well does this actually work in reality? Not well. RobotC, despite being based on C, manages to do the opposite of what makes C great to code for embedded systems. It's interpreted. It's slow. The internal timer-counters have a resolution of 1 millisecond. You can't get a good handle on the length of a cycle. This tends to make reading sensor data in discrete timesteps difficult. And when you try to integrate and do calculations on the spot with them, it becomes about impossible. The limitation here isn't the creativity and ambition of the students, or the capability of the sensors, but the processing ability of the NXT.


    How can this be fixed? One method might be through the introduction of an alternative firmware and coding environment that is less bulky. NXC might be a good choice. A more immediate fix is to partially offload the processing of the data somewhere else.

    The idea of offloading work to a separate processor is not unique. The CMUcam, which is a 'sensor' that doesn't seem to be disallowed by the rules as of now, has an onboard DSP to process data. Lower-speed embedded systems aren't able to take on full image processing along with other duties, so the DSP onboard the sensor does it and presents it in an easier to digest form. The NXT itself contains an 8-bit coprosessor to the main 32-bit processor. Similarly, the HiTechnic "SuperPro" Prototype Board has a chance to shine in this area.

    The new "SuperPro" Prototype Board seems to address this data processing issue neatly. It seems to have an onboard PIC microcontroller that is intended to be programmed by the user. It also doesn't seem like pure low-level access, but with some level of abstraction: "The SuperPro Sensor also supports a powerful onboard program environment that enables programs developed in C using the SPC programming environment to be downloaded and run on the SuperPro." Yet rule <R03> k.6. seems to specifically disallow programming the "SuperPro", barring access from an important feature of the board. I believe this rule is a remnant from last year, when the obsolete HiTechnic Prototype Board was not intended to be reprogrammed. As the SuperPro is a very recently released sensor, there was perhaps some unfamiliarity with the intended capabilities of the sensor when the rules were written. I have not had a chance to try the SuperPro myself, but it seems to be a solution to the problem above. Data from sensors connected to the SuperPro can be preprocessed into a form that the NXT can handle.

    One more method for offloading processing may be through the SuperPro's strobe functions, which allow for some digital communication from the board to other components. Previously, the slow and unreliable update speed of the Prototype Board made communication impossible, but that has been solved with the strobe function. A separate microcontroller could conceivably be connected to the Prototype Board to do the data preprocessing, yet the "catch-all" rule of <R03> s. seems to prevent this. Not allowing external processors is somewhat understandable, as FIRST may not want people getting an unfair "advantage" or straying too far away from the standard electronics of their peer teams. It is somewhat unclear how this rule should be interpreted, as technically, no components that can be attached to the Prototype Board are "specifically allowed". Additionally, the rules for the Prototype Board only discuss sensors that may be attached to the board. What constitutes a sensor when we are working with basic electronics? Sensors more often than not need other components to work. I could attach a microcontroller to a sensor IC and call it my "sensor". In fact, the IC's from companies like Microchip are often just specifically programmed PICs. Basically, there is a lot of leeway in the wording and it suggests that the rules may need to be clarified and reevaluated with a better understanding of what reasonable limitations should be when allowing teams to build their own circuits.

    I urge FIRST to expand into this territory, as the "Hacker" and "Maker" movements have been rapidly growing in size in recent times. Many students have some basic understanding or are interested in learning about Arduino, and FTC could be a gateway into learning more. A step beyond just encouraging some use of programming and sensors and perhaps giving the electronics and programming portions a (slightly) larger emphasis moving into the future. This would better inform students that this area of robotics exists and allow students who are interested in electronics to better experiment and express their creativity and passion in a way that adds to their robot, team and FTC as a whole.
    Last edited by blazin; 09-13-2012, 04:23 AM.

  • #2
    Originally posted by blazin View Post
    How well does this actually work in reality? Not well. RobotC, despite being based on C, manages to do the opposite of what makes C great to code for embedded systems. It's interpreted. It's slow. . . . The limitation here isn't the creativity and ambition of the students, or the capability of the sensors, but the processing ability of the NXT.


    How can this be fixed? One method might be through the introduction of an alternative firmware and coding environment that is less bulky. NXC might be a good choice. A more immediate fix is to partially offload the processing of the data somewhere else.
    NXC is also an interpreted system and uses a modifed version of the firmware used with LabVIEW. It's been about 5 years since I did the benchmarks but at the time ROBOTC execution speed was 100X faster than LabVIEW and 20X faster than NXC. And several times faster than the other alternatives (LeJos, pbLUA) that were available. See http://www.teamhassenplug.org/NXT/NXTSoftware.html. for the performance comparison.

    The current ROBOTC execution speed, with a reasonable mix of features is conservatively around 100K lines of code per second; individual interpreted opcodes take 2 to 5 microseconds (on ROBOTC) and a typical line of code generates 2 opcodes.

    There are many standard C features found in ROBOTC that are not available in NXC; e.g. no support for pointers in NXC, I don't think recursion is supported because NXT functions are not re-entrant. And ROBOTC is the only programming solution for NXT with a debugger. ROBOTC has a priority based scheduler for different user tasks; all "tasks" in NXC have the same priority. ROBOTC schedules tasks on a much more frequent basis than NXC; in NXC, if you have five tasks simultaneously running a task would typically execute for 1-millisecond and each task would only get a timeslice once every five milliseconds. I'm biased, but suggesting NXC appears to be a step backward.

    Originally posted by blazin View Post
    How well does this actually work in reality? . . . The internal timer-counters have a resolution of 1 millisecond. You can't get a good handle on the length of a cycle. This tends to make reading sensor data in discrete timesteps difficult. And when you try to integrate and do calculations on the spot with them, it becomes about impossible. The limitation here isn't the creativity and ambition of the students, or the capability of the sensors, but the processing ability of the NXT.
    You're incorrect about the root cause of some of the limitations.

    The values of analog sensors in the NXT are read by a slave 8-bit CPU that does not have upgradeable firmware. It polls sensors on a 3-millisecond cycle. The main CPU on the NXT in turns polls the 8-bit CPU evey two milliseconds for analog values. So it is either two or four milliseconds between when the main CPU has read one polled analog value and the next value. In all the programming environments (ROBOTC, LabVIEW, NXC, ...) when you "read" the value of an analog sensor you're only retrieving the last polled value that has been received by the main NXT CPU.

    For the smart (i.e. I2C based) sensors the "standard" NXT firmware (i.e. all firmware except for ROBOTC) is able to transmit/receive one byte every millisecond. ROBOTC firmware has been optimized and has an option to use either the standard speed or one that is almost3X faster. THe ROBOTC implementation is also more robust (i.e. less transients) because it's smarter in the amount of delay it introduces between every bit wheras standard firmware always uses a 100 microsecond cycle per bit. It is hardware limitations in the NXT that prevent I2C from operating at a faster speed -- namely the series resistor for ESD protection and the very high pullup resisters used (to minimize idle current drain) limit the speed with which clean signals can be propagated on the sensor wire.

    Bottom line is that hardware / architecture limitations in the NXT limit analog and I2C sensor to a multi-millisecond polling rate. A higher resolution internal clock cannot improve this.

    If you're trying to "integrate sensor values" at a sub-millisecond rate without understanding the basic limitations of the sensor polling then I would expect the results to be unpredictable.

    Comment


    • #3
      To be fair, RobotC does not support many standard C features, either. The biggest thing here is that your program has no access to dynamic memory, and thus no pointers. This was a real difficulty for my team, as we had to allocate an arbitrarily large array ahead of time in our code instead of calling malloc() or a similar function to get exactly the required memory. This limitation also prevents teams from using basic data structures, such as stacks, queues, and linked lists which could prove quite useful in more advanced autonomous code.

      The task priority is a nice feature. The abstraction this provides was similar to an OOP language such as C++, and allowed us to perfect one task and then ignore it. Thus, we had a pollJoysticks task, an updateMotors task, an updateSensors task, a diagnostics task, and a couple of others running all the time. Unfortunately, the biggest problem here is not the task feature, but Samantha. Having more than one task running causes the required waitForStart() call to never return. We had three running (main, diagnostics, and updateLEDs), which consistently hung our code or crashed the FCS.

      I understand why FIRST sticks to RobotC: it is well documented, well maintained, has many useful features (tasks, debugger, FCS emulator, etc), and remains easy to use and to learn. Thus, the difficulty of I2C interfacing, memory access, LCD output, and a rudimentary filesystem are all abstracted away, and allowing teams to focus entirely on game-specific coding tasks.

      This whole argument is rather irrelevant, however. A careful reading of <R03a> reveals that any microprocessor is allowed, so long as it is attached to a SuperPro board. The SuperPro cannot be reprogrammed according to <R03k6>, so this will be a major bottleneck, but I can think of a couple ways around this, which I will leave you to discover for yourself. Happy coding!
      FTC Team 4508
      E=MC Squirreled
      Website: emcsquirreled.github.com
      Github Repo: www.github.com/emcsquirreled/FTC-2012
      Lead Programmer and Electronics

      Comment


      • #4
        Originally posted by emcsquirrled View Post
        To be fair, RobotC does not support many standard C features, either. The biggest thing here is that your program has no access to dynamic memory, and thus no pointers. This was a real difficulty for my team, as we had to allocate an arbitrarily large array ahead of time in our code instead of calling malloc() or a similar function to get exactly the required memory. This limitation also prevents teams from using basic data structures, such as stacks, queues, and linked lists which could prove quite useful in more advanced autonomous code.
        malloc is an interesting challenge and it is interesting to see how it is implemented in other small embedded systems.

        LabVIEW (for NXT) and NXC have no malloc either.

        Arduino has a very simple "solution. It starts with a single large block and allocates from that block. When all memory has been allocated once then it fails. The 'free' function does nothing. There is no garbage collection to combine smaller free blocks into larger blocks. LeJos (JAVA) for the NXT has a similar strategy, or at least it did when I looked at it a few years back.

        It seems to me the approach you adopted using ROBOTC is roughly equivalent to the Arduino/LeJos system.

        Garbage collection introduces an interesting problem for real-time systems. Usually the memory garbage collection function is an atomic function that cannot be interrupted. And with lots of fragmentation can take milliseconds or tens of milliseconds. This is not quite the desired behavior.

        One solution is restarting the CPU whenever a program has finished to clean up memory. This doesn't work well with something like the NXT where the background OS is continuously running with a UI and program chooser running. You don't want to reset this information. Espcially on FTC where you may want to preserve state information of the HiTechnic motor and servo controllers between autonomous and user control programs. Many teams also configure their FTC solutions so that servos hold their positions after program has stopped; this is not likely something that you want to stop.

        IF it weren't for worrying about recovery when things go wrong -- abd pointers, memory not freed, etc -- it would be easy to add a "malloc" and "free" intrinsic to ROBOTC firmware which would use the native malloc/free implementation that comes with the native ARM toolchain from IAR used to compile the ROBOTC firmware.

        I think pointers and malloc/free are serparate issues. The recent 3.50 release of ROBOTC has added standard pointer support. You simply have to assign the pointers to point to standard variables. If you really felt that it was needed, you could implement your own 'malloc' function from a large static array.

        Comment


        • #5
          The CMUcam, which is a 'sensor' that doesn't seem to be disallowed by the rules as of now
          The CMUcam is disallowed by the rules; it is not a LEGO certified sensor.

          The biggest thing here is that your program has no access to dynamic memory, and thus no pointers.
          Supposedly, with the latest version, we now have real pointers. I have yet to verify their effectiveness.

          A careful reading of <R03a> reveals that any microprocessor is allowed, so long as it is attached to a SuperPro board.
          Good luck. The SuperPro board must power all of your electronics, and I doubt it can source much current. I can't find a spec, but the old Protoboard could only source 22mA. Granted, there are some things you can do with that, but nothing too intensive.

          I think the true path to happiness for FTC teams using RobotC is compatibility between RobotC's compiler and a standard build system, such as Makefile, CMake, Apache Ant, or my relatively unknown favorite, Scons. That way, anyone who wants to program in RobotC isn't locked-in to the RobotC IDE. The RobotC compiler is pretty amazing compared to the other options, but there's a bit of a gap between its IDE and, say, Eclipse or Visual Studio. And to take that a step further, if RobotC had a standard gdb server for debugging, that would be really cool. Just my thoughts.

          P.S. dickswan, are you the "real" Dick Swan, creator of RobotC? Because if you are, I just might have to write on my resume that I'm in a conversation thread with you . Your work with the RCX and NXT has been pretty amazing, taking the Mindstorms system farther than LEGO could have ever planned it to go.
          Max Bareiss

          FTC #248 Fatal Error (2009-2013)
          FRC #3142 Aperture (2009-2012)
          FRC #1302 Team Lionheart (2012-2013)
          ZRHS #89 Team K├╝hlschrank (2011-2013)
          ZRAC #40 Catcher in the Skye (2012)
          ISR 12: Umptysquatch 6
          Rowan University Baja SAE

          And mentoring for life.
          --
          11 seasons of FIRST in 6 years, as a student. Many more as a mentor.

          Comment


          • #6
            Originally posted by Skinkworks View Post
            Supposedly, with the latest version, we now have real pointers. I have yet to verify their effectiveness.
            Lots of people will be disappointed, including me, if they're not "real". I'm sure there are still some rough edges but several very experienced programmers have been testing the implementation for the last six weeks or so.

            Originally posted by Skinkworks View Post
            P.S. dickswan, are you the "real" Dick Swan, creator of RobotC?.
            Yes.

            Originally posted by Skinkworks View Post
            I think the true path to happiness for FTC teams using RobotC is compatibility between RobotC's compiler and a standard build system, such as Makefile, CMake, Apache Ant, or my relatively unknown favorite, Scons. That way, anyone who wants to program in RobotC isn't locked-in to the RobotC IDE. The RobotC compiler is pretty amazing compared to the other options, but there's a bit of a gap between its IDE and, say, Eclipse or Visual Studio. And to take that a step further, if RobotC had a standard gdb server for debugging, that would be really cool. Just my thoughts.
            Remember that most ROBOTC users tend to fit the beginner / inexperienced category rather than well experienced. The Eclipse or Visual Studio solutions have a pretty steep learning curve; I feel they're really optimized for the full-time professional and not a student novice. ROBOTC wants to be a great fit for the less experienced end user but also provide good functionality for the real power users as well.

            Recently I've been using Atmel Studio for some Cortex CPU development. It uses the Visual Studio shell with the GCC tool chain to program program Atmel's ARM / Cortex chips. I've been underwhelmed with the poor performance of the Debugger. It's really, really slow and does a mediocre job of displaying variables; the call stack display only shows the topmost stack frame.

            Comment


            • #7
              Remember that most ROBOTC users tend to fit th beginner / inexperienced category rather than well experienced.
              Yes, I agree. Perhaps I should re-word my comment: I think FTC teams should have the option to use RobotC in an external toolchain. Yes, Eclipse and (certainly) Visual Studio have a bit of a learning curve, but some FTC team programmers are already proficient in Eclipse usage. They should have the option to use a build system and IDE that they are familiar with, but for those who aren't very proficient in programming, they should have the option to use a turnkey solution.
              Max Bareiss

              FTC #248 Fatal Error (2009-2013)
              FRC #3142 Aperture (2009-2012)
              FRC #1302 Team Lionheart (2012-2013)
              ZRHS #89 Team K├╝hlschrank (2011-2013)
              ZRAC #40 Catcher in the Skye (2012)
              ISR 12: Umptysquatch 6
              Rowan University Baja SAE

              And mentoring for life.
              --
              11 seasons of FIRST in 6 years, as a student. Many more as a mentor.

              Comment

              Working...
              X