Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Robogames 2018 Ideas and Suggestions

  1. #1
    Join Date
    Jun 2013
    Location
    Tucson, AZ
    Posts
    163
    Rep Power
    18

    Robogames 2018 Ideas and Suggestions

    Click image for larger version. 

Name:	RTEAM.JPG 
Views:	109 
Size:	11.7 KB 
ID:	7003

    Post your ideas suggestions for Robogames 2018 here. No guarantees we will implement them, but we (R-Team) will try to take all ideas into consideration. If you supply good rationale reasoning behind the idea... better yet.

    I'll start off with just of few of the items on R-Team's list:

    1) Overhead cameras with displays in the corners of the arena for better audience viewing.

    2) Return of some sort of mobility rule. Some of the matches were very static... either due to the less mobile mechs holing up in the corners or the mechs with the betters guns just setting themselves up as snipers. A better idea would be to come up with some sort of mechanism to encourage movement without having to have a "rule".

    3) Target transponders with their own power sources. In a few of the matches, the mech lost power and the target system went down with them.

    4) Rules clarifying what happens when a mech loses power... wasn't quite clear what to do to us judges. Is the match over? Should the mech be allowed to restart with some sort of penalty?

    5) Better clarification in the rules on guns and gun velocity allowed so competitors have clear expectations of what's allowed. We want to allow competitors choice of design but want to limit damage to buildings, arena, and other competitors mechs.

    6) A "reference" design mech. R-Team would like to make an open source mech design so the entry bar isn't so high for new competitors. It would include a gun design, turret, choice of controllers, body/leg layout, schematics, software, etc.. Competitors could use as is or modify as they like.

    7) Explore options for jpieper/jwatte target filter card. The R-Team variant worked fine this year but had a lot of parts and was a pain to build a bunch of them (and it was a 4-layer board). The jpieper/jwatte board appears to be simpler and with the atmega processor on board we may be able to add additional functionality.

    8) Earlier posting of the 2018 rules (by R-Team) so competitors have more time for comments.
    Last edited by GhengisDhon; 04-25-2017 at 11:14 PM.

  2. #2
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,174
    Images
    27
    Rep Power
    267

    Re: Robogames 2018 Ideas and Suggestions

    Enforcing mobility: periodic long-range artillery/missile strikes against the location of each mech with ~20 seconds transit time and an effective blast radius of ~20cm (siren signaling the firing/launch, then 20 seconds to get at least 20cm away from the blast)? Damage would be limited to only the mech targeted at that location, so no effect on pursuers. Would require an IMU on each transponder or effective overhead position tracking to properly implement.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    bleh

  3. #3

    Re: Robogames 2018 Ideas and Suggestions

    An IMU on the target/score boards was mentioned. It could potentially be used for other things, too (like detecting/enforcing 'disabled mech' status?)

    Thoughts: I think the general movement rule could have been OK, but 10 seconds was maybe too short, and the enforcement was not consistent. Make the scoring board apply 1 HP every 15 seconds of "not enough movement" would perhaps be a good first start. Or combine the "healing" and "multiple plates" mechanisms, perhaps with a lowering of the overall hitpoints? This would lead to the winner having to pursue the target. Right now, a legitimate strategy is to score the first hit, then just stay hidden for 8 minutes until you win on points.

    So, without IMU, and with new firmware:
    - Each mech starts out with 15 HP total, with each panel capable of "taking" 10 HP damage
    - Each 20 seconds of no damage taken anywhere, any panel with less than 10 HP heals one HP capability, and the total HP goes up by 1

    The second rule means that, if I have taken hits on two panels, both panels increase their ability to "deliver" hits, but total HP only goes up by one, for each healing interval.

  4. #4

    Re: Robogames 2018 Ideas and Suggestions

    Another idea: Staging and scheduling on a fixed timer.

    Each match has a time set out at the beginning (or, at least, the next 3-5 matches have a time set out.)
    The match starts on that time. "Starting" means that the 10 minute staging time starts. (We may want to reduce this to 5?)
    This allows audiences to know when the next match starts, and allows people to plan lunch, battery charging, bio breaks, frame re-builds, and so forth.
    I'd be OK with a 5-8 minute staging time, and one 5 minute extension/time-out available during the competition. (I think 2 minutes is too little to effectively allow any kind of emergency fix.)
    Presumably the scoring system server/laptop would know when the next match was, and could display a clock and such.
    Rule is, if you don't have a mech on the starting square and are out of the arena at time Start+Staging, you forfeit. (Probably need a 15 second warning for people to clear the arena)

    Benefits:
    - audience knows when matches start
    - no ambiguity about when the match deadline really is
    - contestants can effectively plan smaller versus larger updates
    - significant pressure to stay on schedule!
    Last edited by jwatte; 04-26-2017 at 11:34 AM.

  5. #5

    Re: Robogames 2018 Ideas and Suggestions

    Another rule proposal that would put pressure on quick staging:

    After staging time starts, and one competitor has staged their bot, left their arena, and declared "ready," the opponent loses one hitpoint per full minute before they, too, declare "ready."
    Maybe we could have big red "ready" buttons next to the control stations or something :-)

    Benefit:
    - significant pressure to practice staging and stage quickly

  6. #6
    Join Date
    Jun 2013
    Location
    Tucson, AZ
    Posts
    163
    Rep Power
    18

    Re: Robogames 2018 Ideas and Suggestions

    Quote Originally Posted by jwatte View Post
    Another idea: Staging and scheduling on a fixed timer.
    Agreed. We did a much better job of this in 2016 than this year. This year we let it slide. As we (hopefully) grow and get more mechs, this will be come much more crucial.

    Maybe we can schedule "exhibition" slots where the mechs that get disqualified because they missed their start time can still have a match if they want too.

    Expect the staging/scheduling to be on a time schedule next year.

  7. Re: Robogames 2018 Ideas and Suggestions

    Here are the additional notes that I took:

    • Reach out to Rhiannon early to help with a smooth registration and setup
    • Introduce Pilots to the audience. The audience didn’t always know who was piloting the mechs.
    • Somehow show that the pilots are sitting behind the arena. Perhaps show the outline of the pilots (simple approach), or show their faces in an overlay of the FPV (complicated approach).
    • See what it takes to allow for a twitch stream of the matches.
    • Create a Slack channel to let people know when matches start
    • Bring handouts about the R-Team robotics club
      • Website
      • Github

    • Stickers (of the mechs) for kids
    • Parts lists to hand out (many people asked me for the parts list for Daisy, I emailed them most of it, a hand out would be helpful.)
    • T-Shirts (to hand out as swag) Maybe give one to Rhiannon
    • Assign tasks to team members in Tucson during the November Mech Brawl so that tasks can be complete and tested in Tucson
    • Use pics from pre-qual to start a video about the mechs and explain mech warfare at a high level. Revise the video as needed as people qualify.

  8. #8
    Join Date
    Jun 2013
    Location
    Tucson, AZ
    Posts
    163
    Rep Power
    18

    Re: Robogames 2018 Ideas and Suggestions

    Click image for larger version. 

Name:	RTEAM.JPG 
Views:	33 
Size:	11.7 KB 
ID:	7011

    Thought I would add a few items that I liked/worked well from 2017 Robogames...
    1) Think its been mentioned elsewhere a few times but the bigger arena with roads
    2) The new transponder scoring system worked nearly flawless this year. A thousand times improvement over 2016. Big thanks to artans and jwatte for the work they did on it.
    3) The LEDs on the scoring plates. Visual feedback when your hitting is gratifying. I think its also good for audience viewing.
    4) Most of R-Team upgraded their comm XBees to either the 60mW 2.4GHz XBee Pros or the 900MHz XBee Pros. Both seemed to work well in the noisy Robogames environment with few dropouts/lag.

  9. #9
    Join Date
    Feb 2012
    Location
    Tucson, Arizona
    Posts
    96
    Rep Power
    21

    Re: Robogames 2018 Ideas and Suggestions

    jwatte, you posted this suggestion a while back:

    So, without IMU, and with new firmware:
    - Each mech starts out with 15 HP total, with each panel capable of "taking" 10 HP damage
    - Each 20 seconds of no damage taken anywhere, any panel with less than 10 HP heals one HP capability, and the total HP goes up by 1

    The second rule means that, if I have taken hits on two panels, both panels increase their ability to "deliver" hits, but total HP only goes up by one, for each healing interval.

    -----------------------------

    We just started the process of editing the 2017 rule set into what will be the draft 2018 rule set. It is not clear to me what you are saying. Can you expound or explain in more words what you mean? Thanks.
    Last edited by giantflaw; 3 Weeks Ago at 07:15 PM.

  10. #10

    Re: Robogames 2018 Ideas and Suggestions

    Probably best to illustrate in code :-)

    Here's a sketch for code that could run on the scoring board:


    Code:
    #define HEALING_TIME 20000
    #define PANEL_HITPOINTS 10
    #define TOTAL_HITPOINTS 15
    
    bool panelWasHit[4]; // from interrupts
    uint8_t panelHitpoints[4] = { PANEL_HITPOINTS, PANEL_HITPOINTS, PANEL_HITPOINTS, PANEL_HITPOINTS };
    uint8_t totalHitpionts = TOTAL_HITPOINTS;
    uint32_t lastHitTime; /* for limiting damage to 1/second */
    uint32_t healingBaseTime; /* different from lastHitTime because it increments when healing */
    
    /* each step through the loop */
    
    uint32_t now = millis();
    
    for (int i = 0; i < 4; ++i) {
        if (panelWasHit[i]) {
            panelWasHit[i] = false;
            if (panelHitpoints[i] > 0 && (now - lastHitTime >= 1000)) {
                panelHitpoints[i] -= 1;
                totalHitpoints -= 1;
                lastHitTime = now;
            }
            healingBaseTime = now;
        }
    }
    
    if (now - healingBaseTime >= HEALING_TIME) { /* 20 seconds */
        healingBaseTime = now;
        for (int i = 0; i < 4; ++i) {
            if (panelHitpoints[i] < PANEL_HITPOINTS) {
                panelHitpoints[i] += 1;
            }
        }
        /* crucially, total hitpoints only heal 1/20 secs, even if multiple plates heal */
        if (totalHitpoints < TOTAL_HITPOINTS) {
            totalHitpoints += 1;
        }
    }
    
    if (totalHitpoints <= 0) {
        dead();
    }
    Also, how to detect panel hits:

    Code:
    /* in setup */
    attachInterrupt(PIN_PANEL1, panel1, CHANGE);
    attachInterrupt(PIN_PANEL2, panel2, CHANGE);
    attachInterrupt(PIN_PANEL3, panel3, CHANGE);
    attachInterrupt(PIN_PANEL4, panel4, CHANGE);
    
    
    /* interrupt functions */
    
    void panel1() {
        panelWasHit[0] = true;
    }
    void panel2() {
        panelWasHit[1] = true;
    }
    void panel3() {
        panelWasHit[2] = true;
    }
    void panel4() {
        panelWasHit[3] = true;
    }
    Note that this is all asynchronous and state machine based, so the loop just keeps running, and rate limiting happens by measuring against time stamps, rather than using delay().

    Separately, an intentional feature of this logic is that no more damage is taken once a particular plate has been reduced to 0, BUT keep hitting that plate will prevent the 'mech from healing.
    Last edited by jwatte; 3 Weeks Ago at 10:29 PM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. 2017 Robogames Ideas
    By GhengisDhon in forum Mech Warfare
    Replies: 70
    Last Post: 10-29-2016, 08:54 AM
  2. Discussion Kit Comments/Suggestions
    By Mike. in forum HR-OS1 Development and Discussion
    Replies: 1
    Last Post: 04-27-2015, 05:47 PM
  3. Project Hi all some suggestions on my servos
    By nagash3 in forum DYNAMIXEL & Robot Actuators
    Replies: 9
    Last Post: 05-13-2012, 04:25 AM
  4. Need suggestions for new board
    By sniperscope in forum Arbotix, Microcontrollers, Arduino
    Replies: 4
    Last Post: 05-08-2009, 03:12 PM
  5. Newbie asking for suggestions
    By SamQ in forum Robotics General Discussion
    Replies: 3
    Last Post: 11-01-2008, 09:59 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •