Announcement

Collapse

Technology Forum Has Moved!

The FIRST Tech Challenge Technology forum has moved to a new location! Please take a look at our forum blog for links and instructions on how to access the new forum.

The official blog of the FIRST Tech Challenge - a STEM robotics programs for students grades 7-12.


Note that volunteers (except for FTA/WTA/CSA will still access their role specific forum through this site. The blog also outlines how to access the volunteer forums.
See more
See less

Feature Request for SDK: Ganged Motors

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

  • Feature Request for SDK: Ganged Motors

    I'm not sure how to make an official feature request so posting here. Please move if this isn't the right location.

    As part of the discussion about the best motor/speed control method for using the new Tile Runner base when using the default mode with two ganged motors per drive wheel, it was proposed to add the following to the SDK to support this natively. It would seem this would be a relatively simple extension of the existing control code for driving at constant speed or to position by encoder already. This would avoid the strong possibility of overloading a port on the motor controller by directly wiring two motors to a single port.

    Originally posted by Alec View Post
    Feature Request for Modern Robotics: Provide a configuration option that will create a master/slave relationship between the 2 motor ports of a Core Motor Controller.

    If you configure motor port 2 to be a slave of motor port 1, then motor port 2 will output the same power/signal as motor port 1, with the option of reversing the polarity of the signal that is sent to port 1. Any OpMode commands to the slave port are ignored (or throws an error) while the master/slave relationship is in effect.

    The requested feature would eliminate the drawbacks of having to power two ganged motors off of a single motor port to be able to use an encoder to control the ganged motors. Each motor can be powered from a dedicated motor port when using an encoder.
    Technical Coach, Newton Busters FTC 10138, FLL 3077
    Chicago 'burbs, IL

  • #2
    Originally posted by gof View Post
    I'm not sure how to make an official feature request so posting here. Please move if this isn't the right location.

    As part of the discussion about the best motor/speed control method for using the new Tile Runner base when using the default mode with two ganged motors per drive wheel, it was proposed to add the following to the SDK to support this natively. It would seem this would be a relatively simple extension of the existing control code for driving at constant speed or to position by encoder already. This would avoid the strong possibility of overloading a port on the motor controller by directly wiring two motors to a single port.
    This is a great request, but it can't be done in the SDK, it has to be done inside the Motor Controller.

    The reason is that when you put the motors in either RUN_USING_ENCODER or RUN_TO_POSITION mode, the firmware in the Motor Controller is what's actually regulating the output voltage to keep the motor running at the correct speed.. It increases and decreases the output voltage automatically to constantly adjust the speed (as read by the encoders). Unfortunately the Phone (SDK) can't tell what voltage it's sending the motor because the Motor Controller does not provide that information back to the phone.

    In order to slave two motors together, the output of two channels would need to be controlled by one encoder. This could potentially be done by the motor controller, but it would require a firmware change, AND an SDK change to issue slightly different commands.

    You would need to suggest this feature to Modern Robotics.

    Note:
    The way this slaved operation has been done in the past is to simply gang the left and right motors together (electrically) on one channel of the controller and then just feed one encoder back to that channel.
    As long as you don't stall the motors, the motor controller has ample power to run two motors on one channel. If you do stall all 4 motors, chances are you will blow a fuse anyway....

    Phil.

    Comment


    • #3
      Originally posted by Philbot View Post
      ... As long as you don't stall the motors, the motor controller has ample power to run two motors on one channel.
      Hi Phil,

      <RE00> says "Teams must ensure that electrical and electronic devices are used consistent with manufacturer's requirements and specifications."

      The Core Motor Controller specifications allow a maximum of 5 amps per motor port [channel]. If the motor draws more than 2.5 amps under load, then connecting two motors to a single motor port would violate <RE00>. I believe a Tetrix DC motor can draw more than 2.5 amps under load.

      Comment


      • #4
        Originally posted by Alec View Post
        Hi Phil,

        <RE00> says "Teams must ensure that electrical and electronic devices are used consistent with manufacturer's requirements and specifications."

        The Core Motor Controller specifications allow a maximum of 5 amps per motor port [channel]. If the motor draws more than 2.5 amps under load, then connecting two motors to a single motor port would violate <RE00>. I believe a Tetrix DC motor can draw more than 2.5 amps under load.
        For some reason we have always been allowed to put 2 motors per port.

        From miscellaneous robot electrical section of Game Q&A forum post #12

        Quote Originally Posted by FTC2856 View Post
        Hello,

        Is it permissible to attach two legal motors to a single Motor Controller port by soldering the two wires to make a "y" splitter? Please see the attached picture. Thank you.


        Answer: There is nothing in the rules that would prohibit the connection of two motors to a single motor controller port via a splitter cable.

        Note: Care should be taken to pay attention to the current driving limits of the Core Motor Controller. The CMC has internal thermal breaker that will open when excess load is drawn from the controller resulting in the controller being inoperable until the breaker resets. Two motors under stall conditions would likely exceed the CMC current limit!

        Comment


        • #5
          My opinion on this issue is that it is an example of trying to "over-featurize" something. Coupling motors is quite easy in software, and you can quickly write a method or class to do so. If you want to use only one encoder cable, you can do this as well. Trying to couple motors through the MR Firmware is making things much more complicated. Now you have to change both software and firmware, and changing things in 2 places is not as "reliable." In the case of a quick switch, especially at a competition, you would have to spend extra time going through the process of updating the firmware before replacing a broken controller. There is no reason to program in 2 different places, when it can all be done through one interface.

          If you are referring to coupling them in terms of run to position mode or run using encoders, that is not a good idea as each motor has slight imperfections, and so in order to achieve best performance, the motors should be controlled separately by the channels, and not together. If the differences are tiny, then it would be no different from just continuing to do what we do, which is couple them in software.

          So while I think that it wouldn't hurt anyone to have this feature added, I think that the help it does would be far less than the pain it causes to maintain it, and most teams would not use it because coupling in software is easy and more efficient.
          Programmer for Team 4997 Masquerade -- 2012 World Champions, 2014 - 2016 Division Finalists
          Founding Member of Team 6433 Neutrinos -- 2015 World Champions

          Check out my intro video to the new tech platform
          Check out my team's Robot Reveal for Res-Q

          Comment


          • #6
            Maybe a little of thread.

            Is there a definite relationship between setPower and the resulting speed? I.e. 1.0 = x pulse per second. There is (void setMaxSpeed(int encoderTicksPerSecond)) which is in pulses per second.

            I believe the Device Discovery program has some features to change the motor controller parameters (PID parameters, tetrix vs. Andymark, etc.) (No modules available at moment to verify). Some of these are advanced options that are not for the faint of heart. Others seems to be kind of basic. It would be nice if these could be set from the program and not have to go through a separate program. Ex. DCmotor.motorType(NeverRest60) could be used to specify supported motors. Methods to support individual parameters could support others.

            Comment


            • #7
              Originally posted by Alec View Post
              Hi Phil,
              <RE00> says "Teams must ensure that electrical and electronic devices are used consistent with manufacturer's requirements and specifications."
              Good luck getting a definitive statement of performance out of Modern Robotics

              Their current controller has the same motor driver chips as their Hitechnic controller had. This is a chip capable of 30A continuous current per channel.
              They never had any issues with driving two motors per channel before, so I'm guessing they are just playing CYA these days.

              As for allowing 5 Amps per channel... the Andymark motors can draw up to 11 amps as they reach stall, so any arm or winch that's straining to lift a robot is going to exceed 5 Amps pretty darn quickly.

              We double up motors all the time, and I have yet cause a motor controller to fail, or blow a fuse for that meter.

              Note: This is just my "opinion" after having used Hitechnic and Modern Robotics controllers for 7 years.

              Comment


              • #8
                Originally posted by Philbot View Post
                Good luck getting a definitive statement of performance out of Modern Robotics

                Their current controller has the same motor driver chips as their Hitechnic controller had. This is a chip capable of 30A continuous current per channel.
                They never had any issues with driving two motors per channel before, so I'm guessing they are just playing CYA these days.

                As for allowing 5 Amps per channel... the Andymark motors can draw up to 11 amps as they reach stall, so any arm or winch that's straining to lift a robot is going to exceed 5 Amps pretty darn quickly.

                We double up motors all the time, and I have yet cause a motor controller to fail, or blow a fuse for that meter.

                Note: This is just my "opinion" after having used Hitechnic and Modern Robotics controllers for 7 years.
                Phil,

                We have 2 outreach bots. One of our outreach bots is our competition RES-Q bot from last season, the other is an outreach bot that we made over the summer. Neither of our outreach bots is using a Power Distribution Module (PDM). This is because there is no requirement to use a PDM on an outreach bot and/or there are no Robot Inspectors or FTAs at any of our outreaches. BTW, our bots work just as well, if not better, without a PDM. Nevertheless, we have to use a PDM on our Velocity Vortex competition bot because FIRST/MR requires it.

                "<RE00>" says "Teams must ensure that electrical and electronic devices are used consistent with manufacturer's requirements and specifications."

                The Core Motor Controller may be able to handle a current draw of 30 amps per port, but <RE00> says teams cannot exceed MR's requirement for teams to limit the current draw to 5 amps per port.

                PS> Get some sleep

                Originally posted by 3805Mentor View Post
                For some reason we have always been allowed to put 2 motors per port.

                From miscellaneous robot electrical section of Game Q&A forum post #12

                Quote Originally Posted by FTC2856 View Post
                Hello,

                Is it permissible to attach two legal motors to a single Motor Controller port by soldering the two wires to make a "y" splitter? Please see the attached picture. Thank you.


                Answer: There is nothing in the rules that would prohibit the connection of two motors to a single motor controller port via a splitter cable.

                Note: Care should be taken to pay attention to the current driving limits of the Core Motor Controller. The CMC has internal thermal breaker that will open when excess load is drawn from the controller resulting in the controller being inoperable until the breaker resets. Two motors under stall conditions would likely exceed the CMC current limit!
                Thanks you 3805Mentor for pointing out the GDC's VV Q&A forum post on this topic. Unfortunately this post doesn't mention anything about teams being allowed to disregard <RE00>.

                Comment


                • #9
                  Originally posted by Alec View Post
                  Phil,

                  We have 2 outreach bots. One of our outreach bots is our competition RES-Q bot from last season, the other is an outreach bot that we made over the summer. Neither of our outreach bots is using a Power Distribution Module (PDM). This is because there is no requirement to use a PDM on an outreach bot and/or there are no Robot Inspectors or FTAs at any of our outreaches. BTW, our bots work just as well, if not better, without a PDM. Nevertheless, we have to use a PDM on our Velocity Vortex competition bot because FIRST/MR requires it.

                  "<RE00>" says "Teams must ensure that electrical and electronic devices are used consistent with manufacturer's requirements and specifications."

                  The Core Motor Controller may be able to handle a current draw of 30 amps per port, but <RE00> says teams cannot exceed MR's requirement for teams to limit the current draw to 5 amps per port.

                  PS> Get some sleep



                  Thanks you 3805Mentor for pointing out the GDC's VV Q&A forum post on this topic. Unfortunately this post doesn't mention anything about teams being allowed to disregard <RE00>.
                  I can't find a more specific reference than this so far. We've been told the interpretation of the rules from the game manual as stated in the forum is what the refs shall go by. I'm sure the policy is written down someplace, I'll keep looking.

                  Game Manual part 1
                  Students are required to support their questions by referencing specific rules or posts to the Q&A
                  section of the official FIRST Tech Challenge Forum. Team members are required to ask their questions
                  in a gracious and respectful manner.

                  Comment


                  • #10
                    I just checked Core Device Discovery program. The DCMotor control does have a feature to select Matrix, TETRIX, Andymark (1 only), and Custom motors. Custom lets you set PID values (odd coefficents) and something called RATIO.

                    The Andymark value for RATIO is 25 which does not correspond to any to the standard motors. Any thoughts on what it might be?
                    (response/query also in thread "Robot Controller PID settings?"

                    Comment


                    • #11
                      Originally posted by Alec View Post
                      Thanks you 3805Mentor for pointing out the GDC's VV Q&A forum post on this topic. Unfortunately this post doesn't mention anything about teams being allowed to disregard <RE00>.
                      Well, you would appear to be stuck between a rock and a hard place.

                      1) You have decided that the 5A recommendation is now an absolute rule. Despite the indicated Q&A which does trump the Robot manual.
                      2) The approved Andymark Motors will exceed the 5A limit when placed under a heavy load. (like when the inspectors do a field damage test)

                      So now you get to decide... can you use the Andymark motor on your robot, or not.

                      Comment


                      • #12
                        Originally posted by Philbot View Post
                        Well, you would appear to be stuck between a rock and a hard place.

                        1) You have decided that the 5A recommendation is now an absolute rule. Despite the indicated Q&A which does trump the Robot manual.
                        2) The approved Andymark Motors will exceed the 5A limit when placed under a heavy load. (like when the inspectors do a field damage test)

                        So now you get to decide... can you use the Andymark motor on your robot, or not.
                        It is necessary to have a proper understanding of the rules because the rules affect the design of the bot. I very much appreciate teams sharing their interpretation of the rules because other teams' interpretations often corrects the errors in my team's interpretations, which, on several occasions, has led to a better design of our bots.

                        The NeveRest DC motor is a legal motor. The stall current of the NeveRest motor is 11.5 amps according to the specs, and according to AndyMark's dyno tests.

                        The stall current of a single NeveRest motor exceeds the combined current limit of both ports of the Core Motor Controller (CMC).

                        Since <RE00> has not been rescinded, and since the NeveRest motor is a legal motor, it follows that FIRST does not consider MR's specifications of the CMC to be valid. In other words, as far as FIRST is concerned MR has yet to publish valid specifications for the CMC.

                        So go ahead and draw as much current as you need from a motor port, either by a single legal motor or a ganged set of legal motors. The GDC advises that you'll know when you've drawn too much current from a motor port when the CMC's internal thermal breaker trips.

                        Comment


                        • #13
                          I think there are similar arguments to be made for the Servo controller specs. If I remember correctly anything more than 4 of the regular 485 servos has a larger total stall current than the controller is rated for. It would be nice if FIRST should cleaned up these rules - not a great engineering to specifications experience.

                          Comment

                          Working...
                          X