Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: More thoughts on scoring transponders

  1. #11
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    283

    Re: More thoughts on scoring transponders

    Quote Originally Posted by ArduTank View Post
    So similar to what I'm doing. Lol. I take it the RPi is hooked to the ESP8266 on the controller side?? This setup able to be moved to a larger PC (laptop), or is it dependent on resources only the RPi has??
    ESP8266 + OpenCM-904 <-> 802.11b/g/n router <-> USB 802.11b/g/n dongle or ethernet cable <-> RPi/PC/whatevs + HDMI LCD + Xbox 360 controller
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  2. #12

    Re: More thoughts on scoring transponders

    tician nailed it -- currently, the RPi is running on ethernet cable. I also have a WiFi dongle, and can use HostAP, to cut out the need for a separate WiFi router. That is a direct connection from the ESP8266 to the RPi. I _could_ actually use an ESP8266 for that too, in AP mode -- I initially developed it like that -- but I decided to forgo that on the RPi side for simplicity.

    The setup could be run on a regular PC, as long as it runs some recent flavor of Linux. The Pi is nice because it's cheap, it's lightweight, and it fits very well in the inch of clearance I have inside that wooden box.

  3. #13
    Join Date
    Jul 2012
    Location
    Richmond, IN
    Posts
    652
    Rep Power
    45

    Re: More thoughts on scoring transponders

    Okay. Linux is good. I have an old thinkpad I've been wanting to use for a battlestation

  4. #14
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    283

    Re: More thoughts on scoring transponders

    jwatte, do you think the ESP8266 is capable of controlling dynamixels at 1Mbps with the addition of external logic ICs for full-to-half duplex conversion? The UART should be capable of that speed, but not sure how much power is left for processing dxl packets after all the wifi stuff. Might not be able to handle much in the way of IK computations, but a simple interpolating motion player shouldn't take up too many cycles.

    Think I'm going to get a pair of ESP8266-02 (3 GPIO with IPEX) for minimal transponders, and maybe a pair of ESP8266-07 (9 GPIO + 1 ADC with CHIP_ANT+IPEX) for fancy transponders. With the ESP8266-02, might be able to control dxl with GPIO15 for TXEN/!RXEN! output, GPIO0 for SENSE_BUS in/out, and GPIO2 for LED_HIT output; or alternately, GPIO15 for TXEN/!RXEN! with GPIO0 and GPIO2 for I2C, and have the LED output board be another ATtiny85 I2C device (if the illuminated panels are not enough).
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  5. #15

    Re: More thoughts on scoring transponders

    do you think the ESP8266 is capable of controlling dynamixels at 1Mbps with the addition of external logic ICs for full-to-half duplex conversion?
    Possibly, but it doesn't have floating point, so I wouldn't bet on doing IK and WiFi at the same time.

    a simple interpolating motion player shouldn't take up too many cycles
    I actually think that would work fine, with the caveat that the WiFi may occasionally take a handful to a dozen milliseconds.
    If you run your pose at 30 Hz, that's probably not a problem; if you run at 60 Hz, that's more iffy.

    Think I'm going to get a pair of ESP8266-02 (3 GPIO with IPEX) for minimal transponders
    GPIO0 and GPIO2 for I2C
    One drawback of this module is that I2C is all software emulated. I think the later modules have hardware SPI, though (at least that's a billed feature of ESP8266-12E)
    I'd look at the ESP8266-12E myself -- no need worrying about the lower-pin-count versions. The cost is basically the same (unless you make thousands.) The only other module with legs would be the -7, because of the better antenna.

  6. #16
    Join Date
    Jul 2012
    Location
    Richmond, IN
    Posts
    652
    Rep Power
    45

    Re: More thoughts on scoring transponders

    What about passing the servo positions directly through?? Let the PC/RPi/Mac/etc on the other end do all the calculations for the IK, and just use the ESP8266 as a serial passthrough, ala Wifi xbee?

  7. #17
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    283

    Re: More thoughts on scoring transponders

    Once the module is connected to the server for bot/match configuration and the initial panel configuration is finished, then the I2C would only be requesting one byte per target panel at 5~10Hz and occasionally writing one byte to panels when hit (possibly also to fire?). Going with the ATtiny13A semi-intelligent buss would be even less taxing, since it is simply 'check if buss pulled low for >10ms. if so, delay(5) until panel releases buss then pull buss low for remainder of ~1 second hit period to keep everything flashing. nearest multiple of 10ms is identity of the panel.'.

    The main reason for liking the -02 module is that it appears that I can squeeze everything (ESP8266-02, OKI-78SR-5, 3.3V regulator, RESET and BOOT buttons, I2C headers and level translators, dxl connector and its ICs, FTDI header, and assorted passives) in a 30mm square (mostly) single-sided PCB with four M2 mounting holes on 25mm spacing. If so, holy crap. Wifi transponder with semi-intelligent/I2C panels and dxl controller/telemetry in a single small and cheap package. Since there is the FTDI header with an extra pin and jumpers/resistors to connect everything, the PCB should work just as well as plain comms and 'hit pulse' (and 'fire') for another board if the dxl controller attempt fails.


    Full dxl packets at ~30Hz would probably be a bit much to dump through the ESP8266 wifi and still provide smooth or reliable motion. Sending poses then letting the ESP8266 interpolate from its current position might be feasible.
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  8. #18

    Re: More thoughts on scoring transponders

    The other quesiton is whether the Mech Warfare Consortium would really like the idea of co-running competitor-derived code on the same CPU as the scoring-related code. There's a lot of things that can go wrong there, even with just accidental bugs (not considering someone who wanted to bend the rules.)
    I think if the official firmware allowed data pass-through, it'd be OK to use the same module for scoring and control, but running non-standard code on the module is likely not a good idea for that reason.

  9. #19
    Join Date
    Sep 2010
    Location
    ಠ_ಠ
    Posts
    2,317
    Images
    27
    Rep Power
    283

    Re: More thoughts on scoring transponders

    Quote Originally Posted by jwatte View Post
    The other quesiton is whether the Mech Warfare Consortium would really like the idea of co-running competitor-derived code on the same CPU as the scoring-related code. There's a lot of things that can go wrong there, even with just accidental bugs (not considering someone who wanted to bend the rules.)
    True, although an illuminated target panel will flash when hit regardless of any other influences except losing 5V power. If the other panels and/or top LED board fail to mimic the hit state, then pause the match and pull the transponder or start counting bursts of LED flashes.

    Quote Originally Posted by jwatte View Post
    I think if the official firmware allowed data pass-through, it'd be OK to use the same module for scoring and control, but running non-standard code on the module is likely not a good idea for that reason.
    Was thinking of a few user selectable configuration states within a single standard sketch...
    1) target panel type - legacy/simple, semi-intelligent, or I2C panels.
    2) transponder to bot comms - legacy mode with only pulse output and ledhit output, FTDI header TX/RX pass-through with regular match status updates from server, simple interpolation engine using 'EEPROM'/FLASH stored motions/poses transmitted during match setup, or simple interpolation engine using transmitted motions/poses in somewhat real-time.
    3) transponder to controller comms - regular hit/status updates: with no user feedback, with FTDI header TX/RX pass-through, or with DXL current positions + highest servo temperature with ID + highest servo 'load' with ID (or round-robin bulk updates?).
    4) Then the usual things like transponder ID number, bot name, team name, network SSID, network password, server IP, port number, game mode, etc.

    Everything gets filtered through the server, so would have central control over all messages sent to bots along with their target panel, motion, and weapon statuses. Power up the transponder, connect your control station to the network, start up a python script (or custom code) that connects to the server and creates a virtual serial port/pipe on your control station for eventual read/write access to your bot's transponder comms, use the script to log into the server with bot name or transponder ID, verify transponder connection and configuration, verify operational status of bot, panels, and weapons during pre-match testing, then secure bots/weapons and wait for match to start. Server would only pass user comms to transponders, or permit arming of weapons via I2C/DXL, during pre-match checks or while match timer is running.


    The ESP8266+DXL was partly for MW, but mostly just the idea of enabling lots of little bots (e.g. Darwin-Mini) to roam around with better comms for coordination. Who knows if any of this will work remotely as I'd like... I seem really excitable/jittery from the prozac today, so not filtering things as well as usual...
    Please pardon the pedantry... and the profanity... and the convoluted speech pattern...
    "You have failed me, Brain!"
    [git][mech][hack]
    gives free advice only on public threads

  10. #20
    Join Date
    Jul 2012
    Location
    Richmond, IN
    Posts
    652
    Rep Power
    45

    Re: More thoughts on scoring transponders

    Maybe try a black box?? Recording hardware that records the targeting system, required to be tested before and after each match/qualification run, and the box itself is regulated, built, and maintained by the organizers.

    This could be standardized to the point of a connector hooked into the scoring/control system that this hooks into, with all the proper monitoring lines. After the match, the boxes are collected and their data is downloaded to a organizer supplied PC (likely the main server). Any discrepancies can be handled from there however the rules would be written.

    This box could even be downscaled to a really small and light form factor (barely bigger than an ATTiny)

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. New Scoring Panels
    By Deimos in forum Mech Warfare
    Replies: 54
    Last Post: 03-03-2014, 10:32 PM
  2. Scoring systems?
    By jwatte in forum Mech Warfare
    Replies: 2
    Last Post: 12-10-2012, 12:34 PM
  3. New scoring method
    By praelian in forum Mech Warfare
    Replies: 2
    Last Post: 01-25-2010, 03:26 PM
  4. Discussion My Roboard: First Thoughts
    By WGhost9 in forum Robot Computers
    Replies: 14
    Last Post: 04-15-2009, 07:45 PM
  5. Discussion thoughts about RoboGames
    By JoeStrout in forum Robotics General Discussion
    Replies: 33
    Last Post: 09-26-2008, 07:33 PM

Tags for this Thread

Posting Permissions

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