PDA

View Full Version : Mech Warfare Scoring Transponder 2017



artans
03-02-2017, 12:23 AM
6893

This is a new transponder design for this year's RoboGames. You can also choose to use a older transponder from last year's RoboGames as this year's design is mostly put in new voltage regulators and to replace the headers with the Dynamixel connectors.

After I finish testing the initial couple of transponders, I will place a order for more to be made. Does anyone need a transponder? Current MacroFab is charging $41.73 to make each transponder. Send me a private message if you are interested.

We will probably have a couple of transponders at RoboGames if anyone needs one.

If you want to make your own transponders, I've posted the files on github:
https://github.com/artanz/MWTransponder2017

Here are the initial prototypes I've received from MacroFab and some some initial testing.

6894


https://www.youtube.com/watch?v=HSoDwutJWOQ

jwatte
03-02-2017, 11:12 AM
I imagine you're using the same firmware as last year (although my boards probably need a firmware upgrade as they are serveral years old.)

What causes the delay between impact and blink? I'm surprised it isn't instantaneous, like the green LEDs.

artans
03-03-2017, 04:17 PM
Please update your the firmware on your transponder if you're planning on reusing it.

Please load the following arduino sketch (scoring_transponder_2017.ino) onto your transponder:
https://github.com/artanz/MWTransponderArduinoSketch

The mwscore software (python) code has been updated for the optional rules.

The delay between the impact and the blink is because the code is written that way, where the pulse created (also green led) first, then the code blinks the led board. The delay is about 200 ms before it blinks the LED board.

jwatte
03-03-2017, 04:23 PM
The delay is about 200 ms before it blinks the LED board.


Can I request that we please remove that delay? As a shooter, it's much more helpful if I get immediate feedback of a hit.

Brooks
03-03-2017, 05:28 PM
I see the XBee in the photo. Having read somewhere about the high RF environment at the games, what's the best RF interface to use these days?

jwatte
03-03-2017, 11:29 PM
The theory is the 900 MHz version of the XBee. However, a "Pro" version of the 2.4 GHz XBee might also work okay. Note that the "Pro" versions don't fit on some of the default Arbotix hardware (like the controller) because they are too long towards the bottom.

The scoring system has to use the specific frequency that it's set up for at the game by the firmware. Also, it looks like the DIP switches are in the way of using a Pro Xbee on the scoring transponder.

Gertlex
03-05-2017, 01:43 AM
Thanks for the update!

I'm using an older one... and I don't have the Arduino environment set up (lol). Any chance I can get a .hex file I can just dump onto it? :D

Edit: This is a silly big ask since it assumes you'd have the chance to build specifically for any slight variations the older board I have has. That's asking too much, perhaps. Sorry!

jwatte
03-05-2017, 12:25 PM
I tried building it in Arduino 1.8 using the Uno target, and it doesn't build because <TimerOne.h> is not an existing header file.
It does exist for Teensy, though, so I imagine it used to be available in earlier versions.

That being said, downloading Arduino is not exactly a massive chore, as long as you download a compatible version...

Looking at the code, building for Uno doesn't seem right, anyway, because it uses eight analog pins, and Uno only has six. So what board is it based off of?

KurtEck
03-05-2017, 01:16 PM
TimerOne installs with Teensyduino:

It is installed with the other Teensy libraries. So for example on my new machine it is at:
d:\arduino-1.8.1\hardware\teensy\avr\libraries\TimerOne

Not 100% sure, but doubt that the Arduino IDE will find and use these libraries for other "avr" hardware, such as under d:\arduino-1.8.1\Arduino\avr, such as for the UNO

jwatte
03-05-2017, 02:04 PM
I'm only using the ARM boards for Teensy, which is how I saw that it was available in that install, but you're right, there are some AVR boards for the Teensy too.
So, I tried setting the board to Teensy 2.0 (and Teensy 2.0 ++) and build but those boards don't have the PinChangeInt.h header, so that doesn't work, either.
I think without more detailed build instructions, we don't know how to actually build the transponder code :-(

KurtEck
03-05-2017, 02:54 PM
I was able to get it to build for UNO

I simply copied the TimerOne library directory from the Teensy location and put it under the Arduino directory.

i.e. copy d:\arduino-1.8.1\hardware\teensy\avr\libraries\TimerOne
to d:\arduino-1.8.1\hardware\Arduino\avr\libraries\TimerOne

Then built it...

jwatte
03-05-2017, 08:26 PM
I simply copied the TimerOne library directory from the Teensy location and put it under the Arduino directory.

Okay, that makes my stomach squirm. That's not how package management is supposed to work ...
That being said, using a timer isn't that hard, and writing the function needed right on top of the AVR timer registers would be pretty simple.

KurtEck
03-05-2017, 08:35 PM
Or you can simply install the library from Paul's (PJRC) github project: https://github.com/PaulStoffregen/TimerOne
And put it into the standard Arduino location: <your sketch directories>/libraries/TimerOne

jwatte
03-06-2017, 10:24 AM
And put it into the standard Arduino location

Yes. That is the part that is ix-nay from a project management point of view.
Modifying a stock installation is never a good thing, and should be avoided if at all possible.

Why is that so? When I do that, I suddenly run a "forked" version of the Arduino IDE.
I might accidentally use the library in some other project, without realizing, and then when I publish it, other people won't know what to do.

A better option would be to create a new separate library called "TimerOne" that I put in my user-supplied Arduino libraries.
Or, even better, copy "TimerOne.h" into the project directory of the firmware. That'a allowed by the license at the head of that file.
(It also needs a copy of TimerOne.cpp I think.)

artans
03-06-2017, 11:31 AM
Thanks for the update!

I'm using an older one... and I don't have the Arduino environment set up (lol). Any chance I can get a .hex file I can just dump onto it? :D

Edit: This is a silly big ask since it assumes you'd have the chance to build specifically for any slight variations the older board I have has. That's asking too much, perhaps. Sorry!

I don't mind building you a Hex file, I'll give you the Hex file output from the Arduino IDE. You can just load it with the AVR ISP. Did you have the original 2013 version of the transponder?

I'll build the hex file version for the original 2013 transponder and throw it onto the Github.

In terms of the libraries needed for the transponder, just download and throw the following libraries into the Arduino user libraries folder. If you want to load the new transponder sketches to your transponder, download the following libraries:
https://github.com/PaulStoffregen/TimerOne
https://github.com/GreyGnome/PinChangeInt

Just FYI, I converted the original transponder firmware here to arduino sketches for our transponders.
https://github.com/MechWarfare/mwscore/tree/master/transponder/firmware

Our versions of the transponder use the Arduino bootloader and a FTDI cable to program. I felt it would make it easier for more people to work on the transponder if the code was written and loaded with Arduino IDE.

jwatte
03-06-2017, 11:36 AM
download the following libraries:
https://github.com/PaulStoffregen/TimerOne
https://github.com/GreyGnome/PinChangeInt

Pull request incoming :-)

artans
03-06-2017, 11:40 AM
I see the XBee in the photo. Having read somewhere about the high RF environment at the games, what's the best RF interface to use these days?

I don't think we've found out yet what's the best interface to use with the RoboGame's RF environment. The best thing we found that can do is go to 5.8 GHz analog video for your video link. In our club we're currently experimenting with 900 MHz and XBee Pros for control.

The scoring system this year will still use XBEE S1. The way we're going to mitigate RF issues is store the HP of the Mech on the transponder itself. In previous years, it would only report hits to the scoring computer. If we have RF issues during RoboGames, the transponder will still keep track of the HP and eventually report the right HP to the scoring computer. The new transponder code will also light up the LED board as soon as the mech hits 0 HP if all RF communications fail on the transponder side.

ArduTank
03-06-2017, 07:12 PM
Good idea.That way even if the main pc has crap data, the bots will still keep the good.

I suggest adding a known header and a checksum to the packet setup. For simple clearing of the damaged packets so as not to rely on the transponders getting it right 100% of the time.

jwatte
03-07-2017, 12:04 AM
I suggest adding a known header and a checksum to the packet setup.

First, there already is a known header in the protocol (you can read it in the github repo!)
There isn't a checksum, but the Xbee underlying protocol uses checksums (CRCs, actually) already.
It's very unlikely that something would be corrupted and the Xbee wouldn't catch that.

Second, the protocol decode could conceivably be more robust.
Specifically, I can imagine this bit going wrong:


if (Serial.available() > 0) {
Serial.readBytes(receive,5);
if(receive[0] == 0x55) {
...


Spefically, this doesn't re-sync if there's a byte lost anywhere. It will block in readBytes() forever.
Also, if there's some junk bytes (line noise, old UART data, etc) then it will never sync up, because it's out of sync, and each packet is exactly 5 bytes.
A better way might be something like:


if (Serial.available()) {
unsigned char ch = Serial.read();
if (ch == 0x55) {
Serial.readBytes(&receive[1], 4);
...


This will discard bytes until it gets a 0x55, which is start-of-packet.
It's still not perfect -- reading two bytes and verifying that they complement to 0xff, and if not, moving back to looking for a 0x55, would make it even more robust.
And, of course, reading "whatever is there" into a buffer with an end-write-pointer, and only actually looking at the buffer once there are 5+ bytes, would be most robust.

However, the Xbees actually let you frame the on-air packets, by setting the options correctly (short send timeout, packet min size 5 bytes, in this case,) which will work around most of those problems. Making the "read one byte, then four" change probably still makes sense, though.

Gertlex
03-09-2017, 11:19 PM
How are we setting the ID of the individual transponders? I was under the impression that the 2013 ones were tweaked by hand for this. Or do the xbees have a unique serial that we were just checking?


I don't mind building you a Hex file, I'll give you the Hex file output from the Arduino IDE. You can just load it with the AVR ISP. Did you have the original 2013 version of the transponder?

I'll build the hex file version for the original 2013 transponder and throw it onto the Github.

That would be great! Thanks! Yup. AFAIK it's an original 2012 transponder (they were only made that one year I think?) shown in this thread: http://forums.trossenrobotics.com/showthread.php?5295-2012-MWScore-System-Ordering-Info.

jwatte
03-10-2017, 11:38 AM
The transponder board I have, has a 8-switch DIP switch bar for setting the ID.
It looks like the 2012 doesn't have that, so I imagine that's why the note says the new firmware is only compatible for 2013 and up.
I imagine you will have to latch on to a competitor ID and let us all know what it is so we can avoid it :-)

Separately, yes, Xbees actually have a unique serial number, and the chance of two competitors colliding if we pick the lowest byte out of that will be 1:255 :-)

Gertlex
03-12-2017, 11:58 AM
Ohh, I had forgotten about the DIP switch version. Thanks!

I have PM'ed artans, as I think ordering the new version is just the best way to get this taken care of.

artans
03-12-2017, 01:20 PM
As a reminder, we'll be providing the target panels during matches during. For RoboGames you're responsible for getting a Scoring Transponder, LED board (new Ones or the old ones from 2013 are okay), and any wiring/harnessing between the transponder and target panel/led boards.

The scoring panels and new transponders use the Dynamixel connector. You can build the harnessing or buy it.
Trossen sells the Dynamixel cable wiring. Pick the length you want.
http://www.trossenrobotics.com/p/100mm-3-Pin-DYNAMIXEL-Compatible-Cable-10-Pack

This is a picture of the new LED board.
6900
I can provide them to you or you can make them yourself.
https://github.com/ghengisdhon/rbots/tree/master/LED%20Board

Update on transponders. I've received some transponder bare PCBs from Oshpark and I'll be putting them together when I can sometime this week.
6901

I should get transponders from MacroFab by the end of the month.

jwatte
03-12-2017, 05:24 PM
The wiring harness is new!

I happen to have Dynamixel-to-3pin cables, that I had made with the batch of Onyx Fire boards. Those plug into the 2013 transponder fine. I presume those would count as wiring harness, as long as the cable is long enough...

Of course, making a board that translates isn't hard either, but adds more stuff that needs to fit on the 'bot. I'm really not a fan of 19 little boards :-)

Aaaanyway: Are you perhaps also making scoring panels for sale? I'd love to have some to try with before the competition, and I'm not sure I'll have time to make my own, especially with the surface mount piezo board.

artans
03-19-2017, 06:33 PM
We've found a issue with the new 2017 transponder over the weekend. With the new target plates with LEDs, hitting one target plate is fine but if you hit two target plates at once due to ricochets it's enough to brown out the transponder. The flaw is in the regulator part that I picked, it turns out the higher the input voltage you have the less current it can output. When the input voltage is lowered to ~6 VDC, the 2017 transponder works fine. The regulator can also be powered off the FTDI connector or ISP connector with 5V to bypass the regulator.

Current it's recommended that you use the 2013 transponder or 2013 transponder r-team varient, it appears fine with hitting two of the LED target plates at once. If you want to use the 2017 transponder, lower the input voltage to 6V to maximize the current the 5V regulator can output. Generally don't run the transponder off your main battery power.

If you've asked me for a transponder, I can send you a 2013 transponder (r-team varient) or 2017 transponder. I'll send you a cheap chinese switching regulator board if you want the 2017 one to make up for the design flaw.

jwatte
03-20-2017, 10:59 AM
Or you can use a cheap American regulator:
https://www.pololu.com/product/2844
(I actually ended up putting that regulator on my mainboard to power the OpenCM, because it gets really hot when powered from 16V otherwise, even though the regulator they use is rated at 20V, it has the same heat dissipation issue.)

Or, just use a 6V linear regulator with more heat sinking, soldered to the cable... 'mech configuration is all about heat sinks, right? :-)

Brooks
03-20-2017, 02:36 PM
Water cooling! No one else will have a mech with a radiator - I guarantee it!

tician
03-20-2017, 04:50 PM
Water cooling! No one else will have a mech with a radiator - I guarantee it!
...until I regain a consistent income...
<thunderclap>
muahahahahaaaa!

Brooks
03-20-2017, 07:53 PM
Depleted-uranium BB's? Of course it would be hard to explain why your BBs were going right through your opponent's target plates...

Surround the gun barrel with a water cooling jacket? Like WWI machine guns?

I need to look at the rules!

tician
03-20-2017, 08:09 PM
More like cooling actuators than cooling weapons.

artans
03-31-2017, 12:10 PM
I got the new transponders in from MacroFab, if you wanted one, please let me know and confirm your address to me with a private message.

Transponder + LED board will be $50.

RoboGames competitors will be priority.

jwatte
04-14-2017, 12:24 AM
What will the mechanics of connecting to the LAN of the scoring server be?
Specifically, will it be WiFi, or Wired, or both?
I need to prepare my controller Raspberry Pi for the right kind of connection, because I want to use the scoring server connection to indicate the current scores in my control station.

(Obviously, not the highest priority of all the things left to do, but good to plan for!)

artans
04-15-2017, 11:57 PM
What will the mechanics of connecting to the LAN of the scoring server be?
Specifically, will it be WiFi, or Wired, or both?
I need to prepare my controller Raspberry Pi for the right kind of connection, because I want to use the scoring server connection to indicate the current scores in my control station.

(Obviously, not the highest priority of all the things left to do, but good to plan for!)

It'll be wired, I'm bringing a router/switch for people to connect. It'll be nice if you bring it, less for us to bring up from Tucson. Think you might be the only person who connects to the scoring system that way.

jwatte
04-16-2017, 12:57 AM
I can bring something switch-ey and perhaps wifi-ey and some cables. (Unless I forget :-)
(If I forget, I won't be mad if I can't connect to the score status because it will be my fault!)