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

  • gorpong
    replied
    Originally posted by JimInNJ View Post
    Tom had stated earlier that the SDK program for the DS would only be distributed as a binary this year, so couldn't all of this display and timing be the hard coded into the DS opmode?
    Yeah, I suppose that would work. I was thinking of all the times we ran simulations with a normal Autonomous but only a 30-second TeleOp for testing purposes and being able to adjust those timings as the need arose. If there's a way to "Stop" the running OpMode method then that would work just as well. E.g., hard-code in the 30-second autonomous and 2:30 second driver controlled periods into the DS and if the kids, during testing, needed to stop early they could. I know they mentioned there would be the E-Stop capability on each DS so that might do exactly what the Dr. ordered!

    Thoughts, Tom?

    Leave a comment:


  • Philbot
    replied
    Yes, I would see the DS automatically ending the Auto period, and when it does so, it could switch the robots to the "FLASH LED" OpMode, until it's time to start the chosen Teleop OpMode.

    Phil.

    Leave a comment:


  • JimInNJ
    replied
    Originally posted by gorpong View Post
    Hi Phil that sounds like a good idea and as long as the AutoOp period was set by the SDK code and there was a thread to kill it at exactly 30 seconds, then that might work, but we'd need something similar for the TeleOp period as well, right? Otherwise, we still have a situation where not all teams might stop the teleop at the exact 2:30 mark.

    I'm much more concerned about stopping on time than starting on time. It's pretty obvious when a robot starts moving before all the others and before the ref states that it can, so it will much easier for at least one of the 2 refs to see it. It will be significantly more difficult to ensure that all four robots STOP at the same time. Given that, I'd be happier with the new procedures if there was a thread running that had timers that would start when the start() method completed and would then stop calling the loop() method and instead invoke the stop() method and stop everything at a time.

    The settings of those timers could be part of the DS so the refs could validate that all teams had the appropriate settings before the match (no 2:31 or anything) :-)

    Thoughts?
    Tom had stated earlier that the SDK program for the DS would only be distributed as a binary this year, so couldn't all of this display and timing be the hard coded into the DS opmode?

    Leave a comment:


  • gorpong
    replied
    Originally posted by Philbot View Post
    Since there will not be a central FCS to monitor the readiness of teams, it seems to me that the Driver Station needs to provide the Refs some status information.

    ...
    Once all Teams Lights are flashing, the refs can signal Auto Period start, and the kids just hit the big Go button.

    After Auto (automatically timed) , the system can revert back to flashing, until the Refs signal Teleop Start...

    This should reduce the likelyhood of Unprepared teams, False starts, and time overruns.
    The flashing between auto and teleop will also let refs know that robots are all still functioning and ready to play.

    Phil.
    Hi Phil that sounds like a good idea and as long as the AutoOp period was set by the SDK code and there was a thread to kill it at exactly 30 seconds, then that might work, but we'd need something similar for the TeleOp period as well, right? Otherwise, we still have a situation where not all teams might stop the teleop at the exact 2:30 mark.

    I'm much more concerned about stopping on time than starting on time. It's pretty obvious when a robot starts moving before all the others and before the ref states that it can, so it will much easier for at least one of the 2 refs to see it. It will be significantly more difficult to ensure that all four robots STOP at the same time. Given that, I'd be happier with the new procedures if there was a thread running that had timers that would start when the start() method completed and would then stop calling the loop() method and instead invoke the stop() method and stop everything at a time.

    The settings of those timers could be part of the DS so the refs could validate that all teams had the appropriate settings before the match (no 2:31 or anything) :-)

    Thoughts?

    Leave a comment:


  • Philbot
    replied
    Since there will not be a central FCS to monitor the readiness of teams, it seems to me that the Driver Station needs to provide the Refs some status information.

    It occurred to one of my team that one way to do this might be through the Phone's white Camera FLASH LED.

    Suggestion...

    I think that the Driver station still needs to go through a standard match sequence, and manage the transitions.
    The DS should require the drive team to preset an AutoOp mode and a TeleOp mode prior to the game start.

    After selecting these two modes, the team should enter into "Game Ready" mode, where the DS would flash the Camera's LED on both the Robot and DS (not unlike FRC's DS Ready light and Robot Signal Light)

    The DS should now show one BIG GREEN GO button.

    Once the Refs sees the Blue Alliance light flashing, they can have Red Alliance stage their robots.

    Once all Teams Lights are flashing, the refs can signal Auto Period start, and the kids just hit the big Go button.

    After Auto (automatically timed) , the system can revert back to flashing, until the Refs signal Teleop Start...

    This should reduce the likelyhood of Unprepared teams, False starts, and time overruns.
    The flashing between auto and teleop will also let refs know that robots are all still functioning and ready to play.

    Phil.

    Leave a comment:


  • gorpong
    replied
    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?

    Leave a comment:


  • DanOelke
    replied
    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.)

    Leave a comment:


  • hexafraction
    replied
    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.

    Leave a comment:


  • skatefriday
    replied
    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.

    Leave a comment:


  • Tom Eng
    replied
    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

    Leave a comment:


  • korimako
    replied
    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.

    Leave a comment:


  • skatefriday
    replied
    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.

    Leave a comment:


  • hexafraction
    replied
    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?

    Leave a comment:


  • Cheer4FTC
    replied
    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.

    Leave a comment:


  • hexafraction
    replied
    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?

    Leave a comment:

Working...
X