Announcement

Collapse
No announcement yet.

Video Code Walkthrough of the FIRSTĀ® Tech Challenge (FTC) Robot Controller

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

  • #16
    Originally posted by Cheer4FTC View Post
    Hi Jonathan,

    In the video, I see a DcMotor class and a Servo class. Is there a single Servo class or will there be a separate class for continuous servos that operate differently from the 180 degree servos? For example, at the end of an OpMode, a standard servo may be stopped by simply no longer updating its setting, while a continuous servo that was set to a value will keep running if the value is not reset to a particular value corresponding to a stopped state (and unfortunately that stopped state value may differ from servo to servo). Just curious how this will be handled in the new paradigm.
    Right now there is one servo class. When the stop button is pressed, we stop sending a PWM signal to the servos. Having a unique servo class for continuous servos seems like a good idea.

    Comment


    • #17
      Originally posted by Jonathan Berling View Post
      Right now there is one servo class. When the stop button is pressed, we stop sending a PWM signal to the servos. Having a unique servo class for continuous servos seems like a good idea.
      That would one of my first extensions with simple clockwise(), counterclockwise() and stop()
      methods if FTC didn't provide that in the SDK.

      Speaking of which, when can we get a beta of the SDK again?

      Comment


      • #18
        Originally posted by Jonathan Berling View Post
        Right now there is one servo class. When the stop button is pressed, we stop sending a PWM signal to the servos. Having a unique servo class for continuous servos seems like a good idea.
        Thanks for the response. The continuous servos end up behaving like DcMotors more than Servos (no position feedback, really setting motor power rather than setting a position). It would be cool if there were a ServoContinuous class that reflected this (e.g., with setPower method with range from -1 to +1 like a DcMotor rather than setPosition method with range from 0 to 1 like a Servo).

        We also found that different continuous servos would not always stop moving at the middle PWM value ( for example, we had to set some to 133 instead of 128 in RobotC to get them to stop). It might be helpful for such a class to have something like a "zeroSetting" parameter than can be set, and then when the program is stopped the continuous servos are automatically stopped by setting their PWMs to their individual zeroSetting parameter values. Just some ideas...

        Comment


        • #19
          Originally posted by Cheer4FTC View Post
          Thanks for the response. The continuous servos end up behaving like DcMotors more than Servos (no position feedback, really setting motor power rather than setting a position). It would be cool if there were a ServoContinuous class that reflected this (e.g., with setPower method with range from -1 to +1 like a DcMotor rather than setPosition method with range from 0 to 1 like a Servo).

          We also found that different continuous servos would not always stop moving at the middle PWM value ( for example, we had to set some to 133 instead of 128 in RobotC to get them to stop). It might be helpful for such a class to have something like a "zeroSetting" parameter than can be set, and then when the program is stopped the continuous servos are automatically stopped by setting their PWMs to their individual zeroSetting parameter values. Just some ideas...
          At least on the old HiTechnic controllers, there was an I2C command that would actually turn off power to the +5 and ground pins on the servos, completely shutting them down (this happening on a per-controller, not a per-servo basis). Using this function might be better because setting a "default" PWM value might be a problem for some configurations. Or, is that already what happens?
          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


          • #20
            Originally posted by hexafraction View Post
            there was an I2C command that would actually turn off power to the +5 and ground pins on the servos
            This is the command we are using when the user presses the stop button.

            Comment


            • #21
              Originally posted by Cheer4FTC View Post
              We also found that different continuous servos would not always stop moving at the middle PWM value ( for example, we had to set some to 133 instead of 128 in RobotC to get them to stop).
              Originally posted by Jonathan Berling View Post
              This is the command we are using when the user presses the stop button.
              There should be no issue in this case--the continuous servos won't be getting power at all, or am I mistaken?
              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


              • #22
                Originally posted by hexafraction View Post
                There should be no issue in this case--the continuous servos won't be getting power at all, or am I mistaken?
                Yes, it sounds like the servos will stop appropriately when the stop button is pushed. Yeah! It still might be nice to have a zero setting and a servoContinuous.stop() method that sets it to the zero setting for use in the middle of autonomous or teleop though.

                Comment


                • #23
                  How is the distinction made between motors with and without shaft encoders? Is the encoder a separate "sensor", are there different classes for encodered and unencodered motors, or does reading the encoder of an unencodered motor just return bogus data?
                  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


                  • #24
                    Originally posted by Jonathan Berling View Post
                    This is the command we are using when the user presses the stop button.
                    Was any consideration given to using the WifiDirect Group functionality
                    to implement a replacement for the field control system?

                    e.g. You have a group owner, the referee, which functions as
                    an access point. All four teams join the group and the group
                    owner is running a simple app that sends start/stop commands
                    to the teams (clients).

                    You'd have 9 clients, and yeah, they'd all be communicating
                    through the group owner. I'm not sure at what point wifi direct
                    groups saturate bandwidth, but while the FCS had it's problems, it served
                    a real need. I'm somewhat disappointed to see us taking a
                    bit of step backward in this regard.

                    FRC has managed to work out the kinks with their FCS, moving
                    to wifi devices that aren't private one-offs (samantha) would seem to
                    indicate improved reliability.

                    It would be interesting to know how this discussion went within
                    FIRST headquarters.

                    Comment


                    • #25
                      Originally posted by skatefriday View Post
                      Was any consideration given to using the WifiDirect Group functionality
                      to implement a replacement for the field control system?
                      Also wondered about this. Another idea might be to use some sensor on the control phone to start/stop? e.g. the camera sees green/red, or the gyroscope is flipped, etc? worry about 'scoring that last ball' events and more subjective ref duties after this year's game.

                      Comment


                      • #26
                        Originally posted by skatefriday View Post
                        Was any consideration given to using the WifiDirect Group functionality
                        to implement a replacement for the field control system?

                        e.g. You have a group owner, the referee, which functions as
                        an access point. All four teams join the group and the group
                        owner is running a simple app that sends start/stop commands
                        to the teams (clients).

                        You'd have 9 clients, and yeah, they'd all be communicating
                        through the group owner. I'm not sure at what point wifi direct
                        groups saturate bandwidth, but while the FCS had it's problems, it served
                        a real need. I'm somewhat disappointed to see us taking a
                        bit of step backward in this regard.

                        FRC has managed to work out the kinks with their FCS, moving
                        to wifi devices that aren't private one-offs (samantha) would seem to
                        indicate improved reliability.

                        It would be interesting to know how this discussion went within
                        FIRST headquarters.
                        Hi Folks,

                        The new system utilizes a point-to-point control model. The purpose of adopting a point-to-point system is to make it easier to host an FTC event. While there are certain advantages to having a centralized Field Control System, an FCS-based control system requires that the event manager provide, set up and troubleshoot the field control system for every event.

                        For now, FTC has chosen to go with the point-to-point control system in an effort to help make it easier for our affiliate partners to host an FTC event. The sports start/stop model will also help the FTC events flow more like a high school athletic event.

                        Note that the new platform technology could be adapted to operate with some type of centralized field control system. However, for now, the decision has been made to go with the point-to-point control model.

                        Tom

                        Comment


                        • #27
                          Originally posted by Tom Eng View Post
                          Hi Folks,

                          The new system utilizes a point-to-point control model. The purpose of adopting a point-to-point system is to make it easier to host an FTC event. While there are certain advantages to having a centralized Field Control System, an FCS-based control system requires that the event manager provide, set up and troubleshoot the field control system for every event.
                          Right, and in it's simplest form the control system would be a single ZTE speed
                          in the hands of one of the refs, or any other volunteer. Note that the point to point
                          model is really just a simplified Wifi Direct connection with a single group owner and
                          a single client. Wifi Direct specifically provides for the group owner to be an
                          access point for multiple clients turning it effectively into a small LAN.

                          This doesn't seem to be too much of a burden. Of course, there's a lot of
                          software behind this, but that's the purview of someone like John Toebes, or
                          his doppleganger. The event organizers just need a single additional piece of
                          equipment running a simple app that starts and stops matches. All other
                          communication is using the group owner's Wifi Direct framework to forward
                          packets to appropriate team robots.

                          And this opens the door for a full-on FCS for larger events or more
                          capable organizers, which I think is a big win. FIRST wants it's events to
                          be part spectacle. And a portion of that spectacle is wowing visitors with cool tech
                          and large displays.

                          This could even be optional. Don't have a spare ZTE device to run the
                          match with? Devolve to point to point connections. Have that ZTE device?
                          Run the full setup.

                          Comment


                          • #28
                            Originally posted by skatefriday View Post
                            This could even be optional. Don't have a spare ZTE device to run the
                            match with? Devolve to point to point connections. Have that ZTE device?
                            Run the full setup.
                            My concern with this is how different events (e.g. qualifiers in a region) will be operating on different rules, unless, say, events published information on whether they would make a best-effort attempt to have a central FCS.
                            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


                            • #29
                              I don't see loosing the FCS as a big deal. I'm excited to just be rid of the dang Samantha modules (which were arguably better than Bluetooth - but just barely) This year might be a bit of a learning experience. If the "Sport start/stop" model doesn't work out then there would be no hardware changes necessary to go back to a central FCS. I

                              think the problem with the FCS was not that hard for affiliates to set it up but rather that everything worked fine the night before and then as soon 4 robots all put traffic on that WiFi channel that stuff went to heck and it wasn't easy to figure out why or how to fix it. Then everyone is stressed because the competition is being held up with everyone watching while you try random stuff until something works. From my experience most of that is because the Samantha modules just stink.

                              I have 2 concerns going forward with this point-to-point system.

                              1) How do we help teams who were working fine the night before or in the pits but their robot doesn't work well or is laggy because they had the poor luck of being on a WiFi channel that has environmental noise (i.e. the leaky microwave or something similar).

                              2) If several of the teams for a particular match end up being on the same WiFi channel and one of them is sending a lot of data between their driver phone & the robot phone then they could cause the other teams to be laggy. In FRC they have bandwidth limiters to prevent that from happening. You need a centralized system to do that (or mandatory software on the Android devices.)

                              Comment


                              • #30
                                Originally posted by Tom Eng View Post
                                Hi hexafraction,

                                I believe that when the autonomous period ends, teams will stop their robots and the referees will score the autonomous points. Once the refs have completed the scoring for automous, there will be a second start for the teleop phase of the match.

                                Tom
                                Hi Tom,

                                I was an FTA and FCS operator for many competitions this past season and there was a whole lot of frenetic activity and action in the last second of both autonomous and tele op, what provisions are going to be made for teams that don't stop their robots exactly on time and possibly score points when they really shouldn't? As there's only 1-2 refs per field, how can they watch all four teams simultaneously to be sure that every robot stops at exactly the same/right time? I know in the Hangout you mentioned that the "Sports start" was used before so we shouldn't be concerned about it. But it's not really the start that has me concerned -- it's the finish and, more importantly, the fair finish where things stop at exactly the same time and not a second later. In a normal sports situation it's obvious who won based on who crossed the finish line or touched the wall first, but with FTC it's about points scored and things accomplished, and even one team finishing a half-second later can be huge. In Cascade Effect a single ball into the center scoring tube was worth about 24 points. Lots of matches were turned on that amount of points.

                                Thoughts?

                                Comment

                                Working...
                                X