Announcement

Collapse
No announcement yet.

Constructive feedback for FIRST on the next generation of hardware

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

  • Constructive feedback for FIRST on the next generation of hardware

    Hell FIRST. I have been really struggling with hardware issues this season so much so that 7 out of 10 matches for my two teams were decided by hardware issues. The main issues were the friction lock power connectors on the REV hub and USB connections. I would like to give constructive feedback for the next hardware that I know you are working on.

    1) Place a SOM on the REV controller to take the place of the phone. By using a SOM you can upgrade the Android portion but just removing it and replacing it at a cheaper price than a phone. One I would recommend:

    https://www.variscite.com/products/s...napdragon-410/

    2) All connectors should have a lock. The power connectors not locking is a huge oversight.

    3) Add this eeprom EEPROM to the robot controller https://www.digikey.com/product-deta...4-2-ND/5872981

    This EEPROM is 30 cents and it will add NFC to the robot controller.

    4) Select a driver phone that has NFC. Through the NFC app pair the phone to the robot controller by writing all the phone parameters to the eeprom.

    5) Make the robot controller an always on wifi direct hotspot and once the FIRST app sync through NFC the WIFI direct pairing is done.

    6) All user interface functions and updates for both the robot controller and phone are done through the app.

    I feel these will solve most issues teams have. The FTA told us 25% of matches had at least one connection issue.


  • #2
    Originally posted by ejschuh View Post
    Hell FIRST. I have been really struggling with hardware issues this season so much so that 7 out of 10 matches for my two teams were decided by hardware issues. The main issues were the friction lock power connectors on the REV hub and USB connections. I would like to give constructive feedback for the next hardware that I know you are working on.

    1) Place a SOM on the REV controller to take the place of the phone. By using a SOM you can upgrade the Android portion but just removing it and replacing it at a cheaper price than a phone. One I would recommend:

    https://www.variscite.com/products/s...napdragon-410/

    2) All connectors should have a lock. The power connectors not locking is a huge oversight.

    3) Add this eeprom EEPROM to the robot controller https://www.digikey.com/product-deta...4-2-ND/5872981

    This EEPROM is 30 cents and it will add NFC to the robot controller.

    4) Select a driver phone that has NFC. Through the NFC app pair the phone to the robot controller by writing all the phone parameters to the eeprom.

    5) Make the robot controller an always on wifi direct hotspot and once the FIRST app sync through NFC the WIFI direct pairing is done.

    6) All user interface functions and updates for both the robot controller and phone are done through the app.

    I feel these will solve most issues teams have. The FTA told us 25% of matches had at least one connection issue.


    Thanks for your suggestions! I'll share them with our technology review commitee.

    JoAnn

    Comment


    • #3
      ejschuh, I appreciate all the thought you've put into this, and all the time and professional services your are offering to FIRST. I strongly believe the professional services you are offering to provide on a volunteer basis are just as valuable and appreciated as the time and services of any other FIRST volunteer. Your services have the potential for exponentially reducing the workload and frustrations of thousands of other volunteers and students, which in turn will give mentors much more time to teach STEM education, and students much more time to learn. Not to mention that a flawed and flaky control system works against the mission of inspiring kids to pursue STEM education.

      I think we need to do a bit of market research before undertaking to design the next generation control system. RoboteQ produces SOMs ("controllers") that can control brushed DC motors at 20+ amps per channel, and offers models having one, two, or three channels.

      Roboteq controllers are designed to be meshed together on a CAN Bus network. Thus if you have four drive motors you can mesh together 2 x two channel controllers (SDC2160) to create a single 4 channel control network (making it feasible to implement effective PID control of holonomic drive systems). To control 7 motors, you can mesh together 2 x three channel controllers (SDC3260) plus 1 x one channel controller (SDC2160S) to create a single 7 channel control network. Servo, sensor, and general I/O interfaces are built into the Roboteq controllers.

      A Roboteq controller is a standalone robotics computer running a realtime controller OS designed to mesh together with any number of controller nodes on a CAN Bus network.

      By creating a mesh of controllers on a CAN Bus network you can scale the processing power of the control system while scaling the number of motors, servos and sensors under realtime control and/or query.

      If additional servo, sensor, or I/O interfaces are needed, they can be added to the system by adding Robot IO eXtenders to the CAN Bus network. The eXtender controller is also a standalone computer that further scales the processing power of the control system.

      Typically you will want to minimize the number of controllers, so you will mesh together a small number of larger controllers. Or you can opt to mesh together a larger number of smaller controllers, so as to increase the overall processing power and/or parallelism of the control system.

      You design your control program to run distributively on the control network. There is a visual designer which you can use to design and simulate your control program on a PC. After your control program is verified under simulation, it can be compiled into bytecode that is loaded onto the controllers on the control network.

      Out-of-the-box, the controllers are configured to act as slaves under the control of a control program running on a Robot Controller computer, such as a PC, smartphone, Raspberry Pi, DragonBoard, etc.

      The Roboteq controllers have more features than you could ever imagine, including conformance to ESD protection and protection verification standards. Check out the Datasheet and the User Manual.

      Apparently there are open standards for motion control (PID control). Roboteq's controllers implement the "CiA DS402" open standard for motion control.

      A DragonBoard 410c running Android OS + FTC Robot Controller can connect to a Roboteq control network either via CAN Bus interface (mezzanine required) or via the DragonBoard's built-in UART interface. A single UART connection to any controller on a Roboteq control network is all that is needed. The controller that is connected to the DragonBoard via UART acts as a gateway to the other controllers on the CAN Bus notwork.

      So pretty much all you have to do to enable the FTC Robot Controller to control a Roboteq control network is create classes that wrap control and query commands that are sent & received over the UART connection to the Roboteq control network. Roboteq will probably even do this work for FIRST.

      Speaking of customer support, for larger orders, Roboteq will customize any aspect of their controllers, i.e, processor, firmware, packaging, connectors, power ratings, etc, to suit a customer's particular requirements.

      Note that a team can create the wrapper classes in their OpModes without having to wait for FIRST or Roboteq to provide wrapper classes in the FTC SDK.

      Once support for a Roboteq control network is added to the FTC SDK (or added to your OpMode), the real fun can begin: you can create and load simple or complex subroutines onto the Roboteq control network to run distributively/in parallel in realtime on the control network!!!

      Roboteq controllers require minimum 10V DC supply. For a decent margin, you will probably want to supply 18 or 24V to the controllers. You can use two Tetrix batteries in series to supply 24V to the Roboteq controllers. BTW, FTC batteries are long overdue for an upgrade. I bet a lot of the failures at competitions are caused by the 3Ah Tetrix battery, which I feel is inadequate given the increases in loads that have been allowed over the past few seasons, and given the flakiness of the current electronics offerings from FTC.

      As for pricing, a 2 channel Roboteq controller lists for $250 USD. Considering the features, time savings, customer support, and educational value to students, a $250 price point for a 2 channel controller is highly reasonable. Roboteq will probably be inclined to offer their controllers to FTC teams for a lot less, to support the FIRST cause and/or for volume.

      Best of all students get to learn valuable skills and knowledge of standard control system architectures which are highly marketable. Rather than having to learn the proprietary control system that FIRST is developing, students get to learn standard control system architectures on mature production quality hardware that are in use today in industrial environments all over the world. I think FRC might even become envious of a FTC/Roboteq control system.
      Last edited by Alec; 12-03-2018, 06:56 PM.

      Comment


      • #4
        Originally posted by Alec View Post
        ... Roboteq controllers require minimum 10V DC supply. For a decent margin, you will probably want to supply 18 or 24V to the controllers. You can use two Tetrix batteries in series to supply 24V to the Roboteq controllers. BTW, FTC batteries are long overdue for an upgrade. I bet a lot of the failures at competitions are caused by the 3Ah Tetrix battery, which I feel is inadequate given the increases in loads that have been allowed over the past few seasons, and given the flakiness of the current electronics offerings from FTC.

        As for pricing, a 2 channel Roboteq controller lists for $250 USD. Considering the features, time savings, customer support, and educational value to students, a $250 price point for a 2 channel controller is highly reasonable. Roboteq will probably be inclined to offer their controllers to FTC teams for a lot less, to support the FIRST cause and/or for volume.
        Also, to lower the price points further, Roboteq could produce FTC specific models of their controllers with lower power specifications. A four channel model for FTC at $250 and a two channel model at $150 would be quite reasonable considering the MR and Rev price points.

        Roboteq need not replace MR and Rev. Roboteq would give teams an alternative that might better suit a team's needs and interests.

        Comment


        • #5
          Alec, all good points, but let me throw in some other perspectives. You use the term real-time in several points of the above discussion. This is not true, since the architectures you describe cannot be real-time as they are based on Java. They may be fast enough to get done most of what is needed for robot control, but ultimately using the wrong tool for the job is not teaching the upcoming generation of design engineers how things should be done. Thus, I take issue with your statement above as they are not learning standard control system architectures. As I have indicated before, leveraging the Java ecosystem is fine, e.g.. extensive GUI libraries for example as well as existing high level communication and control. Where Java falls down is in direct motor control, as Java is not ultimately predictable. A better architecture would be to have a microntroller running compiled C opcode performing all the real-time control tasks interfaced with the SOM perfoming the high-level tasks.

          Comment


          • #6
            Originally posted by 11343_Mentor View Post
            Alec, all good points, but let me throw in some other perspectives. You use the term real-time in several points of the above discussion. This is not true, since the architectures you describe cannot be real-time as they are based on Java. They may be fast enough to get done most of what is needed for robot control, but ultimately using the wrong tool for the job is not teaching the upcoming generation of design engineers how things should be done. Thus, I take issue with your statement above as they are not learning standard control system architectures. As I have indicated before, leveraging the Java ecosystem is fine, e.g.. extensive GUI libraries for example as well as existing high level communication and control. Where Java falls down is in direct motor control, as Java is not ultimately predictable. A better architecture would be to have a microntroller running compiled C opcode performing all the real-time control tasks interfaced with the SOM perfoming the high-level tasks.
            Thanks for the feedback. We are in agreement. We just need to clear up some misunderstandings...

            By "architecture" I was referring to the Roboteq control network architecture. To me, the Roboteq control network looks like it would be a standard architecture for motion control.

            You can throw everything away and start from scratch on the Roboteq control network. Alternatively, you can slowly migrate some or all of the Robot Controller/SDK over to the Roboteq control network and/or to other hardware, starting with the pieces that need to run on a realtime stack.

            With the Robot Controller/SDK running on the DragonBoard (or other SBC/SOM) instead of a phone, you have the option of running the Robot Controller/SDK on a realtime variant of Android (say SBC/RTAndroid). You also have the option of running a realtime variant of Linux on a SBC (say SBC/RTLinux), but you would have to port the Robot Controller/SDK to Linux.

            So you would have parts of the OpMode/SDK running on a realtime OS on a SBC, and parts running on the Roboteq control network. You can keep the Driver Station as-is, or decide to refine the DS as well.

            At some point you may come to realize that it is not necessary nor advisable to migrate the Robot Controller/SDK completely off of SBC/RTAndroid or SBC/RTLinux. You may even find that you need not change today's SDK very much at all, and find that you just need to migrate the realtime pieces of your OpMode to the Roboteq control network as I had mentioned:

            Originally posted by Alec View Post
            ... Once support for a Roboteq control network is added to the FTC SDK (or added to your OpMode), the real fun can begin: you can create and load simple or complex subroutines onto the Roboteq control network to run distributively/in parallel in realtime on the control network!!!
            I think that even if you eventually find that you need to migrate completely off of phones and SBCs, migrating is a better option than starting from scratch on other hardware.

            The important thing is the Roboteq control network will allow students to get hands on experience and exposure with the types of control system architectures they will be facing in the real world. And, as a bonus, students & mentors will get to spend much more time on STEM education if they are not having to deal with the issues of the current architecture and hardware.
            Last edited by Alec; 12-08-2018, 12:58 PM.

            Comment

            Working...
            X