PDA

View Full Version : 2017 Robogames Ideas



GhengisDhon
04-16-2016, 05:32 PM
6543
Robogames 2016 is done and gone.... It was a lot of fun and I felt it went fairly well but its never too soon to start looking forward to next year. We have a lot of ideas to make it even better for next year and I'm sure everyone else does too.

I'm starting this thread to post ideas/suggestions for next year so please keep it to discussion along those lines.

If there's an idea you want to work on just let everyone know your working it and keep everyone updated on progress. Others are free to work on the same idea...

The first idea on R-Team's plate is standardizing the Target plates/filter cards. As was apparent this year, all target plates are not created equal. We plan to
1.) Test the existing configurations of the Tucson plates and Josh Pieper's plate. (The FSR plates are out.)
2.) Test these plates with different configurations - different size piezos, multiple piezos per plate, various mounting configurations
3.) Collect data at various muzzle velocity's and various distance
4.) Collect data at different hit locations on a target plate; corner, edge, center

Some desired qualities of the standard design are:
1.) Repeatable sensitivity at all locations on the target plate from acceptable pellet speeds
2.) Repeatable insensitivity from all other robot vibrations or impacts
3.) Standard mounting rigidity

Maybe some secondary features:
1.) Redundant piezos with a way to see if a sensor has failed
2.) LED hit indicator on the target plate


The second idea is to make the scoring transponder robust to the RF environment of Robogames. It seems daunting, but as Josh pointed out, this is probably a pretty easy fix. We just need to change the code on the transponder so that it keeps a local tally of the hits on the target plate. Instead of transmitting only when it is hit, it periodically sends out its local hit total.

jpieper
04-16-2016, 08:36 PM
I've been thinking of several things with respect to the target plates:

Mikhail and I were trying to figure out what airsoft mechanism would allow the FPS to be continuously varied. Then you could use a chronograph and select FPS with moderate precision for a testing or endurance fixture. Is there some gun which already has a continuously variable power, no matter the mechanism? (i.e. a compressed air solution would be fine).

Some of my panels had their piezo delaminate, even when the acetal surface had been abraded, although the ones that delaminated may not have been cleaned with alcohol before rubber cementing. We probably either need a way to validate that panels are working on site, or do some sort of endurance testing to verify they will hold up to repeated stress.

We had LED hit indicators on each plate, but it is tough to make it visible with opaque acetal front plates. I could imagine switching to a lexan front plate, or perhaps using edge emitting fiber optic routed around the plate to make the outside edge be illuminated? The problem with lexan of course, is that it can't be laser cut safely. I don't know of any easily prototype-able transparent plastics that are impact resistant.

I don't think we necessarily have to test many configurations, we just need to find one configuration which meets all the criteria. If one of the existing panels with tweaks can be made to work, we don't have to make a bunch of variants.


w.r.t. the scoring transponder, we were also considering making an nrf2401 variant, just to make the overall cost lower, be able to frequency hop, and be much smaller. No action necessary, but we may post a prototype sometime, and I'd be happy to just make one for everyone for free if it seems like something everyone found useful.

jwatte
04-16-2016, 09:27 PM
The problem with lexan of course, is that it can't be laser cut safely. I don't know of any easily prototype-able transparent plastics that are impact resistant.


You can route Lexan/polycarbonate on a tabletop CNC router, or you could perhaps waterjet cut it (that seems like overkill though.)
Lexan/PC isn't as rigid as acetal or aluminum or whatever, though; when I've cut thin bits in the past (1/32, 1/16) I've sandwiched it between spoil boards. (You can cut a whole stack at once this way, though!)


we were also considering making an nrf2401 variant

I will say this again :-) ESP8266 is cheap, flexible, easy to program, and doesn't require a custom base station. The ESP-8622-12 also ha enough I/Os that it could be the main controller for the board, integrating everything into one.

If we use that, we could conceivably even define a packet format that lets contestants add payload data for telemetry and even control to it. I e, the first N bytes are contestant ID, current score, and checksum, and the following M bytes can be custom, we could have the serial port on the ESP spit out (and receive) those extra bytes for use by the 'bot and controller, and we could use UDP broadcast to let everyone easily listen to it. (Both scoring system and control system at the same time.)

tician
04-16-2016, 09:54 PM
I will say this again :-) ESP8266 is cheap, flexible, easy to program, and doesn't require a custom base station. The ESP-8622-12 also ha enough I/Os that it could be the main controller for the board, integrating everything into one.

If we use that, we could conceivably even define a packet format that lets contestants add payload data for telemetry and even control to it. I e, the first N bytes are contestant ID, current score, and checksum, and the following M bytes can be custom, we could have the serial port on the ESP spit out (and receive) those extra bytes for use by the 'bot and controller, and we could use UDP broadcast to let everyone easily listen to it. (Both scoring system and control system at the same time.)
Which is why I should get back to work on YETIS, if only my brain would be more cooperative. Think I might need to hack apart one of the crap shocking cellphone toys I bought years ago to give me a jolt when my depression/apathy makes me not want to get up. Far more entertaining would be Ripley carrying a cattle prod while riding on mynyr with its 4S 20Ah LiFePO4 battery, but that would require a lot more work I've not been able to make myself do yet. Would also be nice if hobbyking would finally restock certain 2.4kW out-runner and 3.0kW in-runner motors.

ArduTank
04-17-2016, 12:55 AM
A dremel also works well for Lexan/PC/Acrylic. My local Menards sells small pieces that I have used before. (one is the case window of my PC)

I use either the plastic abrasive wheel or the carbide cutter/shaper plastic wheel found in the extended kit. Or at a hardware store. Both use the Ez-lock manderel.

Would either of those motors be one of the house brand Donkeys, Tician?

artans
04-17-2016, 01:14 AM
RoboGames is generally very busy on 2.4 GHz. All the combat robots use 2.4 GHz RC Controllers, not to mention the event WiFi and spectators that use bluetooth and mobile hot spot devices. It's hard to simulate RoboGame's RF environment. Its probably best find a option that uses another ISM band like 433 or 900 MHz, lessen the chance that we run into interference issues. We can still try the ESP8266 or nrf2401 versions of the transponders, we won't know until we test it out.

I got pretty lucky while competing to not run into severe interference issues this year, my controller XBEEs (was using band 20 (0x14)) only cut out at most 10 seconds during matches.

I used Loctite G02 as the adhesive to glue the piezos to acetal/delrin, it held out pretty well. I hit about every mech's target plates to do final qualifications and checking target plates before matches, felt like I had the most sensitive plates.

jpieper
04-17-2016, 05:55 AM
RoboGames is generally very busy on 2.4 GHz. All the combat robots use 2.4 GHz RC Controllers, not to mention the event WiFi and spectators that use bluetooth and mobile hot spot devices. It's hard to simulate RoboGame's RF environment. Its probably best find a option that uses another ISM band like 433 or 900 MHz, lessen the chance that we run into interference issues. We can still try the ESP8266 or nrf2401 versions of the transponders, we won't know until we test it out.


This is why I'm not very excited about an ESP8266 solution. I think the 2.4GHz range can be fine, assuming you control things at the link layer and design an appropriate protocol. With the ESP8266 you're stuck with the wifi protocol, which is going to have a terrible time in challenging wireless environments.

While seemingly appealing, I don't think it is a great idea to try and let competitors tunnel additional information over the scoring system. It has a hard enough time being reliable without additional complications.

I think the existing xbee solution would be just great with different transponder software. If that were changed, my only gripe is the size of the overall transponder + xbee assembly.

ArduTank
04-17-2016, 10:19 AM
What about these?

https://www.sparkfun.com/products/9099

It should be a direct drop in, with minimal configuration. 900 MHz too.

GhengisDhon
04-17-2016, 10:43 AM
I think the 2.4GHz range can be fine, assuming you control things at the link layer and design an appropriate protocol.

That's my opinion also. Better to stick with the Devil you know... Also all the existing mechs have the XBee transponder already integrated into their design.

As for letting contestants modify the format coming back (such as in the ESP8266 solution), I'm against that for the scoring system. Contestants might inadvertently (or advertently) modify the code giving themselves a disadvantage/advantage.

We've also discussed the Xbee Pro as ArduTank suggests. Its not clear (at least to me) if its a direct drop in placement. We might experiment with them though.

JoeyFitzp
04-17-2016, 11:11 AM
What about these RFBees. http://www.ebay.com/itm/RFbee-V1-1-RF-Module-Compatible-for-Arduino-Atmega168-868MHz-/400717508438?hash=item5d4c9fef56:g:g3oAAOxyrrpThal r They operate at 868Mhz & 915Mhz and are suppose to be direct drop in replacements.

Gertlex
04-17-2016, 11:30 AM
Going to address a bunch of points haphazardly:

You can cut .03" polycarbonate with scissors. Easiest prototyping there is: try it with cardboard, make actual thing with polycarbonate. (That's how the beauty that is my BB hopper was done) (and yes, it's very dremel'able.)

Oooh. We could paint polycarb panels with UV sensitive paint, and then use UV emitting LEDs when hit. Glowing score panels :D (I am not in favor of this level of complexity initially; get the panels easy to produce and mount, first)

I fully support just redoing the transponder firmware. Considerations:
- How do we "reset" the transponder so that it knows when the match has started? Internal timestamps might help... maybe.
- If a transponder can know how many hitpoints it has (rather than just number of hits taken since pwoer-on) a visual indicator of the LEDs staying on once you're down to zero would be great.
- Also, I found the SMD light boards to be harder to see.

It would be interesting to experiement with having mirrors on top of the buildings, angled so as to potentially allow spectators to see inside the urban canyons. Obviously a camera setup would be better for this.

I'm pretty sure the XBee pros are drop in replacements, but their footprint is larger (e.g. not compatible with Arbotix Commander, and probably other stuff).

jwatte
04-17-2016, 11:55 AM
Xbee Pro has the problem of cost. 900 MHz may be less crowded, though -- or not; I haven't seen many 900 MHz solutions do spread-spectrum.

I was using WiFi for talking to my Magellan bot in between runs and I was sitting right between the two buildings. I did not have WiFi connectivity problems. I was using a MiFi device and connecting both the bot and the laptop to that. However, 1 meter transmission distance may have helped -- the MW arena is more like 5 meters (so 1/25th the power) unlesss we can hover antennas above the center.

XBees can still work. I second the suggestion that the physical size is bigger than it could be, but we can live with that. Everybody already has it. We could have the coordinator repeat a "start the match; mech hitpoints are IDA=X and IDB=Y" message to the Xbees while setting up, and the coordinator would stop sending these packets once a second when the respective scoring board starts sending its data.

The scoring board could send a packet every 200 milliseconds for 3 seconds after a hit, and then just send score every 2 seconds, to save a bit on power.

If we spin the boards to a new version, let's use a MCU with more serial ports. I'd love to get hit status using a serial command rather than a 200 ms pulse. (Main reason being latency.) (Another option is one GPIO per panel for hit indication, or any of I2C/SPI)

ArduTank
04-17-2016, 11:56 AM
The current setup has the Xbees in what? Multipoint mode? You could send a "All Reset" style packet though the network with a required confirmation to be sent back, and have Base resend if no/incorrect reply received.

Local HP could be tracked with a register, with the mobile units sending a fresh packet upon update (BotID, HP, etc + checksum) and maybe require a confirmation of receipt packet back.

Maybe footprint can be solved with some upwards spacing?

GhengisDhon
04-17-2016, 01:02 PM
- How do we "reset" the transponder so that it knows when the match has started? Internal timestamps might help... maybe.
- If a transponder can know how many hitpoints it has (rather than just number of hits taken since power-on) a visual indicator of the LEDs staying on once you're down to zero would be great.

One way to reset the transponder is on power up, it resets to zero. It just counts up from there, and the different amount of HPs are handled by the receiving station. This would be simple and we wouldn't have to reprogram individual transponders or worry about 2-way communication between the transponders and the receiving station.

This would preclude the visual indication of when your Mech was dead though...

Gertlex
04-17-2016, 01:48 PM
One way to reset the transponder is on power up, it resets to zero. It just counts up from there, and the different amount of HPs are handled by the receiving station. This would be simple and we wouldn't have to reprogram individual transponders or worry about 2-way communication between the transponders and the receiving station.

This would preclude the visual indication of when your Mech was dead though...

This means robots (or the score system, but the power system is one and the same in most/all cases) would need to be restarted after testing panels before a match starts, though.

GhengisDhon
04-17-2016, 02:17 PM
- Also, I found the SMD light boards to be harder to see.


I did too, both as a judge and a competitor. I think for 2017 we'll go to a standardized LED board as well as put a requirement that the LED boards be visible from the front (at least) so the competitor can get visual feedback that he's hitting his opponent. Or maybe go with the idea of having a light up scoring panel.

GhengisDhon
04-17-2016, 02:22 PM
I was using WiFi for talking to my Magellan bot in between runs and I was sitting right between the two buildings. I did not have WiFi connectivity problems. I was using a MiFi device and connecting both the bot and the laptop to that. However, 1 meter transmission distance may have helped -- the MW arena is more like 5 meters (so 1/25th the power) unlesss we can hover antennas above the center.


HD3 was using 2.4GHz wifi the first day and had a lot of interference/lag issues with it inside. Super Mega was using 5.2GHz wifi and it was a lot better but not flawless I believe. HD3 switched over to the 5.2GHz the second day.

jwatte
04-17-2016, 02:22 PM
This would preclude the visual indication of when your Mech was dead though...


We could still use two-way communications across the Xbee to tell the mech it's dead.
(Using some kind of signal that the mech can use to shut down locomotion at that point would be additional bonus points ;-)

I still think having the base station send "match reset" messages (even if they just reset scores to 0) would be great.


having a light up scoring panel

If the plate is sand blasted/diffuse, then injecting light along an edge or two would make the entire plate light up.

Or perhaps some EL wire around the plate? :-)

artans
04-17-2016, 03:06 PM
For the past Robogames, we reused the 2013 transponder design and added a FTDI header. We made it so you could program the transponder using the Arduino IDE and FTDI cable. The current transponder uses XBee series 1 in sort of a star configuration. Each mech's transponder has a ID that is settable by DIP switches and sends a message to the computer that keeps score.

Information that the transponder currently has accessible for telemetry in the form of pulse is:
When being hit.
Panel being hit.

The flaw of this system was that series 1 XBees does not frequency hop, we were stuck on channel 3 (0x0C). Once you set a channel, it stays on the channel.

It might be okay that we stick to 2.4 GHz and just change the firmware on the transponders to report hits points instead of when it's being hit. On my end I'm going to experiment with shrinking the current transponder and switching to series 2 XBees. With XBee Series 2 we can set up a mesh network with a coordinator that can frequency hop. We could set up redundant XBEEs on top on the buildings as repeaters.

Anyone developing a new transponder should have the same information available for telemetry.
Hit Points
Side being hit.

Everyone is welcome to try out ideas, we don't know what works unless we try out lots of ideas.

Gertlex
04-17-2016, 07:10 PM
It might be okay that we stick to 2.4 GHz and just change the firmware on the transponders to report hits points instead of when it's being hit. On my end I'm going to experiment with shrinking the current transponder and switching to series 2 XBees. With XBee Series 2 we can set up a mesh network with a coordinator that can frequency hop. We could set up redundant XBEEs on top on the buildings as repeaters.

I found that Series 2 Xbees were extremely laggy (or otherwise unusable) in 2012 robogames, and was able to switch to series 1 at the same event, and be fine.

The lag might be acceptable for scoring system. I'd be happy to send you my series 2 xbees if you like, for testing (and you can keep them!). Message me if interested.



We could still use two-way communications across the Xbee to tell the mech it's dead.
(Using some kind of signal that the mech can use to shut down locomotion at that point would be additional bonus points ;-)

I still think having the base station send "match reset" messages (even if they just reset scores to 0) would be great.


This does require changing the scoring system's communication method, though. We'd ahve entire matches where the scoring system didn't get any communication from the robots...

tician
04-17-2016, 08:29 PM
HD3 was using 2.4GHz wifi the first day and had a lot of interference/lag issues with it inside. Super Mega was using 5.2GHz wifi and it was a lot better but not flawless I believe. HD3 switched over to the 5.2GHz the second day.
For video, or only control/feedback? Sending packets in the tens to hundreds of bytes long at 1~5 times a second is a very different situation from sending even 160x120 video at just 5 frames a second.

jwatte
04-17-2016, 08:44 PM
Right -- I'm talking about "receive voltage and hit indication back" not "real-time video" stuff.

jwatte
04-17-2016, 08:57 PM
This does require changing the scoring system's communication method, though. We'd ahve entire matches where the scoring system didn't get any communication from the robots...


Yes, I think the protocols need some upgrade, both over the air, and the LAN snoop-in protocol (if we still want to support that, which I think we should.)

Sending the current state every so often, and making that "more often" a bit after the state changes, is a lot more robust than pretty much any other method. (I know this from games networking!) This goes in both directions.
As long as the current state is small (fits in a single on-air packet) then this is absolutely the best approach IMO.

A packet sent by the base station might look something like:


<header-token> : 0xAA
<length> : 0x9
<mode> : 0x0 -- idle, 0x1 -- match prep, 0x2 -- match active, 0x3 -- match over
<minutes> : BCD number of minutes since start of this mode (00 - 99)
<seconds> : BDC number of seconds since start of this mode (00 - 59)
<compidA> : competitor ID A (0 .. 127)
<compAScore> : current score of competitor A
<compidB> : competitor ID B (0 .. 127)
<compBScore> : current score of competitor B
<crchi> <crclow> : CRC16 of the previous data


This would be send out once every second.

The packet from each bot would look like:


<headertoken> : 0xAB
<length> : 0x6
<botid> : ID of this bot (0 - 127)
<mode> : bot's belief of game mode (0 - 3)
<hits> : bot's belief of number of hits indicated (0 - 25)
<lastpanel> : bitmask of last panel(s) being hit (0x00 - 0x0f)
<crchi> <crclo> : CRC16 of the data


The bot would send this every second, plus one extra packet each time it actually detects a hit.


The logic for each side then becomes almost as simple as the current system, with the addition that bots reset their hit count when central says game mode is 1, and bots may stop scoring/counting when game mode hits 3.

You will also note that I made it so that payload doesn't have the high bit set, which should make syncing after packet loss easier.

Finally, is there any particular reason to not use two Xbees, one for each contestant? The could be on the same, or on different channels. The scoring system would just send the same data to both ports, and run two copies of the receive-and-decode code. That way, we wouldn't have to worry about mesh networking and bot senders tromping on each other when trying to update scores at the same time. The Xbee resend behavior is pretty atrociously slow.

ArduTank
04-17-2016, 10:40 PM
That may actually be a good idea. Have two (or more) instances of the com port communications code available within the scoring hub's software that dumps the collated data into a buffer/registers which the main program then reads from. If you set it up right, this cycle could run every say, 100 ms, even if the data has not changed, or have a flag to tell the main loop to check the scoring status and update accordingly.

100 grit sandpaper works really well for making even poly carbonate diffuse.

I may play around with some of my parts and see what I can get with simulated panel hits. I'm afraid I can't help much with noise testing, as there is only 1 router that is even in range out here in the country, and that's mine. Protocol testing is a go though.

ArduTank
04-18-2016, 09:00 AM
I think we may need to have a list of standards for this system, such as target panel trigger signal type, transponder protocol, etc. That way we aren't running into 'Panel A won't work with Transponder X' or 'Transponder B works backwards with Light Board C'.

jwatte
04-18-2016, 10:37 AM
Honestly, I think the right way to do this is to test a number of different approaches, and then just standardize on combination A-X-1.
The hardest part of that will be making sure there's no hard feelings in whomever ends up being not-standardized.
The way I see it, though, many options are a strict necessity to get to the best trade-off between price, robustness, availability, etc.

ArduTank
04-18-2016, 11:00 AM
True.

This (https://www.sparkfun.com/products/13448) chip might be a good option, as it could be placed underneath the xbee/other RF board to shrink the transponder a little.

jwatte
04-18-2016, 11:32 AM
Doesn't the transponder already use a surface mount Atmega?

Anyway, the AVRs have too few serial ports IMO. There are ARM chips that are both cheaper and more powerful.
For example: http://www.digikey.com/product-detail/en/freescale-semiconductor-nxp/MKE04Z8VTG4/MKE04Z8VTG4-ND/4462067
That one still only has one USART, but it's $0.71 in singles rather than the $6 of an ATMega328p, and scale equally in price in volume.

And if we design a new transponder, I imagine we'll use real tools and real surface mount components and probably four-layer boards, and let a place like MacroFab actually put them together.

GhengisDhon
04-25-2016, 07:11 PM
So have I mentioned that a bunch of us at Rteam are interested in autonomous mechs? From the responses to my post on localization it sounds like tician and jwatte are too. It looked like HD3 was already running some sort of image tracking at 2016 Robogames. From looking at Super Mega's setup I assume the Boston group is looking to do more.

So my question is, as we're looking at redesigning the target plates is there something else we should be adding to them to aid in image tracking? Right now the rules state you can add a color pattern to your opponents target plates. But looking forward is there something else we should be doing to aide image tracking. Adding IR LED beacons? Add LEDs flashing at a particular frequency? Etc.....

Love to hear people's thoughts/ideas.

Gertlex
04-25-2016, 09:28 PM
We could make the Transponder a double xbee board; scoring xbee + control xbee. Leave off the headers on the backside, but let people add those headers if they're doing xbees (or same-footprint things). That'd be a nice space saver! (Though the arbotix has xbee headers already, it is an annoyingly large board)

jwatte
04-25-2016, 09:31 PM
If I used Xbees, I'd need three of them. One for transponder, one for control, and one for telemetry. (Reason being that using Xbees bidirectionally has unacceptably high latency.)

Gertlex
04-25-2016, 09:52 PM
If I used Xbees, I'd need three of them. One for transponder, one for control, and one for telemetry. (Reason being that using Xbees bidirectionally has unacceptably high latency.)

Psh. Just do autonomous :)

jwatte
04-26-2016, 10:59 AM
Just do autonomous

That is on the long-term todo list! And using a Raspberry Pi for the brains is a step in that direction.

KevinO
04-26-2016, 04:26 PM
I'd jump in if it was just autonomous! I could use a combination of ROS packages to make it work relatively easy.

ArduTank
04-26-2016, 08:01 PM
I'm going to just leave this here.....

TX+Cam in one:

http://www.hobbyking.com/hobbyking/store/__89777__Quanum_ELITE_TX_CAMERA_COMBO_Micro_Cam_VT X_25mW_40CH_5_8GHz_NTSC_.html (http://www.hobbyking.com/hobbyking/store/__89777__Quanum_ELITE_TX_CAMERA_COMBO_Micro_Cam_VT X_25mW_40CH_5_8GHz_NTSC_.html)

Receiver:

http://www.hobbyking.com/hobbyking/store/__65994__Quanum_Auto_Scan_5_8Ghz_FPV_Receiver.html

Gertlex
04-28-2016, 09:30 AM
I'd jump in if it was just autonomous! I could use a combination of ROS packages to make it work relatively easy.

It's autonomous as soon as someone makes it so! I volunteer you.

sarendt
05-19-2016, 08:48 AM
Hello all,

I'm mostly posting just so I get updates on this thread - but I always thought it would be fun to have an alternative weapon system, I was thinking a nerf dart with a small magnet on it would be easy for a magnetic sensor on the bot to pick up, it would act like a proximity sensor, could maybe even do a range based damage table?

giantflaw
05-19-2016, 09:51 AM
In past rulesets nerf darts were allowed. I don't remember anyone every taking advantage of it though. One problem is putting a system on the Mech consumes valuable weight/volume resource which affects walking speed. The benefit is low because the number of nerf darts is low whereas the same volume/weight can be used to carry more bbs for many shots at high speed. Some mechs have even opted to add a second bb gun to double the odds of getting valid hits. There has been some talk about adjusting the rules to allow a close-in melee weapon.

_ADAM_
05-19-2016, 09:55 AM
Do you need to use pellets, or can you melee the target panel?

EDIT:


There has been some talk about adjusting the rules to allow a close-in melee weapon.

Saw this after I posted.

_ADAM_
05-19-2016, 09:58 AM
It's autonomous as soon as someone makes it so! I volunteer you.

Would an autonomous robot compete against the tele-op bots? And could you tape colored paper to their target panels?

giantflaw
05-19-2016, 10:33 AM
The target panel has been meleed (sp?) in the past inadvertently by legs kicking them and those points did count. I have an on/off switch behind my left back leg. In one fight at MechBrawl, TwitchMX came right on my back and his leg inadvertently turned my Mech off. At Robogames 2012 Insanity Wolf scored the winning point (1 to 0) by kicking Immortal's target plate because they were both out of BBs.

Currently many Mechs guns are accurate enough to shoot at the target plates at distance but if it comes down to a short range all out fight there would be an advantage for a Mech to move in and use an intentional weapon optimized for close fighting while rendering the opponents gun useless. By moving right up against the front of the opponent the gun barrel may be to long and or not be able to point low enough to hit the attackers target plates.

Autonomous robots are expected to compete with tele-op bots in the current ruleset. You are allowed to tape colored paper or patterns to the opponents target plates in the current ruleset. I think a number of people have been playing with target tracking multi colored patterns in hopes of putting them on the Mech. This year at Robogames HD3 was tracking white circles on opponents target plates. So yes go for it...build a Mech with as much autonomy as you can give it.

"Skill and courage and resolution were no longerenough; the time was fast
approaching when only machines could fight machines."
- Arthur C. Clarke

jwatte
05-19-2016, 10:50 AM
If Melee is a thing, then I'd probably put the target panels as a crown, high up on the mech.
Also, some bipeds will have the target panels very high up out of necessity.

Colored paper for marking target panels is already allowed in the rules.

tician
05-19-2016, 06:02 PM
"Skill and courage and resolution were no longer enough; the time was fast
approaching when only machines could fight machines."
- Arthur C. Clarke




"Real stupidity beats artificial intelligence every time."
-- Bursar 1 - Hex 0 (Terry Pratchett, Hogfather)


Might try playing with a purely optical targeting system again since it reduces mechanical complexity (should increase reliability) and power drain from crap brushed DC motors, and eliminates BB cleanup. Had been thinking about a bunch of bokode/QR tags mounted around the bot with the guns/cannons made from a cheap USB webcam and an RPi-Zero, <del>but no one seems to carry them anymore</del>. RPi-A+ with RPi-Camera is a bit bigger than I'd like, and most camera modules either use BGA too small even for OSHPark 4-layer routing or are not easily acquired. Still tempted to try getting my hands on some MLX75412 for several different projects, but have to go straight to melexis sales to get them. The 1024x512 resolution is potentially small enough for a microcontroller to search for QR codes relatively quickly and the sensors have some very nice options for outdoor video applications when combined with better processors.

Err... Go figure, the new RPi-Zero v1.3 was just released and it comes with a camera connector. I had wondered why the RPi-Zero product pages had suddenly disappeared from the adafruit shop a few days ago; apparently caught them between site updates.

jwatte
05-20-2016, 10:52 AM
MacroFab has a 0.4-pitch, 0.3-diameter BGA rule for their PCBs.
You can conceivably just have them make the PCB, by marking all the components "do not populate" and it'll be a reasonable price! :-)

Separately, the nice thing about having the RPi camera is that you could use it for both aiming/vision, and for a remote controller. The Pis don't have NTSC out anymore (boo hiss!) but you can run them over WiFi.

Another "optical targeting system" would be a modulated laser pulse and optical detectors. Make the laser a well-defined single unit that you buy as the "weapon" of the mech for standardization, and it can enforce firing duty cycles.

_ADAM_
05-20-2016, 11:19 AM
Optical targeting system sounds really cool.

tician
05-20-2016, 12:55 PM
Initially wanted to try modulating the output of some super cheap 650nm laser modules that do not have any active electronics (just a resistor connected in series with the laser diode and power sensing photodiode left disconnected) since I just need to remove the resistor and connect it to a few other components on a board to potentially achieve the quick switching needed for low power, simplex, line-of-sight comms. Two big issues with trying to use the lasers as the comms component for MW are: 1) 650nm is visible, thus prone to interference from other sources, and 2) the small diameter laser dot would require lots of photodiodes on the targets/receivers (and/or some extra optics on the receiver that would add bulk). Had also considered an IR blaster setup a bit like 'laser tag' and/or consumer electronics. Even bought a bunch of 25mm lenses (for generic google cardboard) to place in a small tube to play with producing a relatively well collimated light source (~20mm spot). Several problems including reflections, lots of active electronics on both sides of system (more points of failure), possible interference with user cameras, etc. Had wanted to stuff all of the parts of the blaster (IR LED, laser pointer, assorted drivers, and a Teensy) in a 'standard' 3D printed housing with a few external connectors for power, lights, sounds, and vibration motors. Let users customize the exterior to taste and enable 'charging' of the weapons to permit different hit power levels and/or overheating.

RPi Zero and RPi Camera really seems like the best option at this point and it does still have composite output (https://learn.adafruit.com/introducing-the-raspberry-pi-zero/video-outputs). Could add all those options (laser for targeting, external light effects, external sound effects, vibration motor) without needing any active electronics on opponent bots; just a few stickers if using full-size QR codes or some tiny boxes/enclosures if using bokode. Could send the 'scope' video to the user over composite output and send the 'hit/fire' image captures over wifi to the scoring system for processing/verification. Really need to get around to attempting to make some bokode tags.

jwatte
05-20-2016, 04:13 PM
"just laser" would be too noisy. "Laser with a 30% duty cycle at 3 kHz for a 80 millisecond pulse" would be a lot more robust.
You could presumably use semi-diffuse plastics as a light guide to pick up hits of the laser anywhere on the target surface.
But I think I agree with you that it's a more complex system to design and build, and it also wouldn't be as cool looking -- the lasers would be largely invisible in the air because of the low (safe) power requirements.

jwatte
05-20-2016, 04:16 PM
Oh wait -- the regular pis do have composite out, it's just on the third ("microphone") tip of the audio out. That makes using it for piloting a lot better!

tician
05-21-2016, 04:25 PM
Oh wait -- the regular pis do have composite out, it's just on the third ("microphone") tip of the audio out. That makes using it for piloting a lot better!
Not the tip, the sleeve that is usually ground with ring 2 on a plain stereo connector.

http://www.raspberrypi-spy.co.uk/wp-content/uploads/2014/07/Model-B-Plus-Audio-Video-Jack-Diagram.png

GhengisDhon
05-21-2016, 04:38 PM
Another "optical targeting system" would be a modulated laser pulse and optical detectors.

I really don't see lasers happening. The audience appeal would be limited. Like it or not, we are there to entertain the audience so Robogames can make money and continue....

GhengisDhon
05-21-2016, 04:49 PM
A couple other topics I would like to get input on.

1) Multiple people have requested that we allow CO2 powered guns. I don't have any objections, as long as we put an upper fps limit on the guns so we don't damage the arena/mechs or injure someone. Not to mention the arena is already seeming rather small even with the AEG guns.

2) The past rulesets have stated, " In order to allow autonomous bots, and those using visual tracking, competitors may bring a visual fiducial of any color which may be applied to an opponent's target plates using tape of any color." To me this could imply (but is unclear) only autonomous mechs can use visual fiducials. I think we should clarify it to open it to any mech. Moving from remotely operated to autonomous is a big step... this would allow intermediate semi-autonomous mechs.

jwatte
05-21-2016, 11:04 PM
What would the draw of CO2 guns be?
Wouldn't they just be heavier and harder to control than the AEG guns, plus they would add the safety issue of pressurized vessels.

jwatte
05-21-2016, 11:06 PM
I've seen that drawing, but it makes no sense. If I plug a regular 3.5mm headphone/stereo cable in, it won't work in that case.
Who would design such a thing?

tician
05-21-2016, 11:42 PM
It means audio always works exactly as it always should no matter what you plug into it. When you use a two or three contact connector (mono or stereo), then the video gets shorted to ground by the longer sleeve of the plug but audio works fine. For adding video with a four contact connector (TRRS), they could have just as easily swapped Ring 2 and the Sleeve while maintaining backward compatibility with stereo audio connectors. There are no real standards for wiring TRRS connectors, so they just went with one used by some other products made by Apple or Microsoft. Could rewire an MP3 player's cable to work with video by swapping the Ring 2 and Sleeve wires (not so easy if sleeve is connected to the shield mesh/weave/wrap in the cable).

jwatte
05-22-2016, 01:39 PM
Ah! The standard sleeve is longer than the connector. That makes sense then!

tician
05-22-2016, 09:15 PM
The 3.5mm plug/jack has four spaces/positions allocated for contacts. Mono plugs use the Tip and a three position Sleeve. Stereo plugs use the Tip, Ring 1 and a two position Sleeve. Video+Stereo plugs use the Tip, Ring 1, Ring 2, and a one position Sleeve.

Back on topic, do many spectators really visually track much of the transit of the BB's from cannon to target panel? You get a bit of noise from the gearbox and launch of the BB, then a tap/pop when it hits something, but do you really see too much of it before the BB is just rolling around on the floor?

giantflaw
05-23-2016, 10:24 AM
In Tucson we can see ours in moderate lighting to dark. Even in bright lighting if you know to look you can seen them part of the time. Sometimes we have night fights. The cameras see well enough with light leakage to maneuver, aim, shoot. In the night fights the bbs look like laser lines. In the camera views even in bright light we can track the bb from barrel to impact. I often see the opponents bbs wizzing just past me. For the last couple of years we've been using glow in the dark bbs to enhance the audience participation. In bright lighting it's more difficult to see from the audience but the cameras see them. We have been talking about ways to cover the top of the arena next Robogames to block out the ceiling light to put the arena in moderate lighting. In moderate lighting the audience can see the bbs. 6596 6597 If you go to the MechBrawl, match 7, time 2:18, you'll see what I mean.

jwatte
05-23-2016, 11:17 AM
do many spectators really visually track much of the transit of the BB's from cannon to target panel?

It's my impression that the physical pellets add a viscereal physicality that lasers would not, unless we used stronger stuff (https://www.youtube.com/watch?v=53GJJHwQ8BA).

Also, the Tuscon people use tracers, which are super awesome, and make the BBs easier to see even in daylight.

giantflaw
05-23-2016, 12:24 PM
It's fairly straight forward to make your bbs glow. Use glow bbs. When the bb drops into the breech light them up from both sides for 150ms with two UV LEDs, one on each side. I use 40,000 milli-candle LEDs. Don't know if using less bright LEDs works just as good or not. We also cover up any optical leakage paths from the LEDs to protect people's eyes from seeing the UV light. Most of the other guys breeches are 3d printed with a hole on each side to accept the UV LED. Mine was hand cut out of acrylic. I drilled a hole on each side of the breech and inserted a 10mm wide UV LED on each side. After that I painted the acrylic outside with multiple coats to block UV from escaping. Our fire rates are typically 1.5 to 3 rounds a second depending on who's robot you look at so we can afford to spend 150ms soaking up UV. We pulse the UV LEDs because we have a ATMEGA328 controlling the firing cycle anyways but you could just turn the LEDs on and leave them on anytime you are firing. My ATMEGA328 gun processor monitors the end/beginning of the gearbox cycle with a hall effect and the dropping of the bb into the breech is sensed with an IR sensor. I have a gravity feed hopper with a holed wheel dropper so I only drop one bb into the breech at a time. The next bb doesn't drop until the gearbox fire cycle is back at the beginning and therefore the plunger that seals the bucking is clear to allow the ball in. While the ball is finishing it's ringing bounce at the bottom of the breach it is bathed in the UV light.

A couple of the other guys use a gravity feed hopper also but some of the others use a bottom feed hopper that preloads the string of bbs in a feed tube. The feed tube bbs provide constant pressure on the breeched bb so when the gear box cycles the bbs immediately above the breeched bb do not bounce up due to mechanical bounce. That way when the breech is opened the next bb is push right in and this avoids bb cleaving and misfires. When the cleaving occurs many times the plastic plunger is worn and leads to a poor seal on the bucking.

jwatte
05-23-2016, 01:18 PM
Interesting!

My design uses gravity feed, but with a column of BBs dropping from above, providing some pressure. I use the plunger to cycle -- it shoots forward to fire the BB; when it moves back, the next BB can fall in. I use an IR sensor to detect cycling for rate limiting.

With this design, I could probably put UV LEDs in position for the BB about-to-be-fed, and flash it while the gun is cycling, and then keep a cooler, less bright UV LED on the side of the breech itself (where BBs may rest if not actively shooting.)
Benefit would be lower latency for firing.

tician
05-30-2016, 07:32 PM
So, I've been playing with layout for a bottom-mounting hat for the RPi-Zero v1.3 to turn it into a camera/cannon. I have some free space on the current version and wondering if there is anything someone else would be looking for such as an IMU. Still very preliminary and need to get my hands on an RPi-Zero to verify USB DM/DP test point locations, so not going to be making anything for quite a while.

Currently has:
- one side with only SMD parts and other side with only PTH parts (connectors and 8mm polymer capacitor);
- spring pins to access the USB DP/DM signals on the bottom of the PRi-Zero and route them to a vertical mount USB-A connector between the mounting holes at the end opposite the camera connector and adds proper ESD protection to those data lines;
- footprint for PNVT003 (or equivalent) 3A buck regulator to provide 5V for the RPi and accessories;
- a UDFN-8 (2x3) EEPROM IC for hat parameter storage;
- 4-pin JST-PH for LEDs with level-shifting buffer ICs to provide 5V MOSI and SCK (GND, 5V, G20/MOSI, G21/SCK);
- 2-pin JST-PH for simple laser/light control (5V and N-MOSFET controlled by G05);
- 2-pin JST-PH for speaker with footprint for NCP2820 mono amplifier driven by G12/PWM0_R and using G06 for MUTE;
- 3-pin JST-PH connector with TV and mono output for FPV (spring pin to TV; G13/PWM1_L; GND);
- 3-pin JST-PH connector for 3-phase BLDC motor driver (MTD6508) for small, potent vibration motor (this (http://www.hobbyking.com/hobbyking/store/__71638__hexTronik_2_gram_Brushless_Outrunner_7700 kv_AR_Warehouse_.html) or this (http://www.hobbyking.com/hobbyking/store/__71757__NTM_Prop_Drive_13_12_2400KV_40W_AR_Wareho use_.html)?);
- 3-pin JST-PH connector for UART (no level-shifting or protection);
- 3-pin JST-PH connector for I2C (no level-shifting or protection);
- 2-pin JST-PH connector for 12V input;
- 2-pin JST-PH conenctor for well-regulated 5V input to bypass PNVT003 (no protection circuits with direct connection to USB and RPi-Zero header 5V) or for <0.5A 5V output;

6603

The board is currently looking to be 32mm x 65mm with the bottom-hat and RPi-Zero spaced ~7.60mm or ~10.10mm depending on how the through-hole headers are mounted to the RPi-Zero. Want to make a small printed case to hold the stack with a cutout for the USB-A connector, an easily removable access panel to get at all the JST-PH connectors on the bottom of the hat, and a mount for the camera which will point to the right in the screenshot (cable looped over itself along the top of the RPi-Zero to keep clear of spring pins and other connectors). The entire case should (hopefully) be no more than ~40mm x ~40mm x 80~100mm and completely enclose the board stack and camera and provide external mount points (threaded inserts?).

jwatte
05-31-2016, 10:39 AM
Every Raspberry Pi needs a Real-Time Clock, with the backup battery that goes with it. If you don't, your log file timestamps will all be a jumble.
Unfortunately, a CR2032 takes a lot of board space. (I put mine at the bottom, between the pi and the hat.)

For a bot board, I'd hope to see Half Duplex circuitry for the serial port, and I'd also hope to see a power MOSFET for the gun.
I also put soft power on mine, plus an ADC so I can read battery state and prevent dead LiPos.

JST-PH for 12V input seems a bit on the weak side. On mine, I used 2xV and 2XG pin headers for high-amerage connectors, and a screw terminal for main power.

Speaker is probably needed on the Pi Zero. I put a piezo element + driver on mine, which is good for debugging noises; I expect to use the 3.5mm out for any "real" sound. Zero doesn't have that.

tician
05-31-2016, 09:48 PM
Every Raspberry Pi needs a Real-Time Clock, with the backup battery that goes with it. If you don't, your log file timestamps will all be a jumble.
Unfortunately, a CR2032 takes a lot of board space. (I put mine at the bottom, between the pi and the hat.) Hmm. Kernel modules for quite a few RTCs. Wanting to minimize both part count and board space, so liking the Abracon AB-B5ZE-3S even if it does cost a bit more than cheaper IC with discrete crystal. Broke down again and extended the board to 80mm then completely rearranged everything to make space for BU2032 battery holder, LSM9DS1 IMU, and LPS25HB pressure sensor.


JST-PH for 12V input seems a bit on the weak side. On mine, I used 2xV and 2XG pin headers for high-amerage connectors, and a screw terminal for main power. Nothing will be powered by the hat except through the 5V/3A converter, so JST-PH can easily handle the <2A max draw at ~12V.


For a bot board, I'd hope to see Half Duplex circuitry for the serial port, and I'd also hope to see a power MOSFET for the gun.
I also put soft power on mine, plus an ADC so I can read battery state and prevent dead LiPos. Not making an airsoft or servo controller. It could be used as a scope for an airsoft weapon system with lots of extra processing, but primarily meant to be a purely optical weapon system with light, sound, and tactile effects. I2C and full-duplex UART make it very easy to take commands from other devices and/or to control smaller external devices like an airsoft motor driver board with its own direct connection to main battery instead of routing through the hat.


Speaker is probably needed on the Pi Zero. I put a piezo element + driver on mine, which is good for debugging noises; I expect to use the 3.5mm out for any "real" sound. Zero doesn't have that. G12 and G13 are alternate pins for PWM0 and PWM1 which produce the Right and Left audio channels, respectively, of the RPi-A/B/A+/B+. Just copied the audio output filter from the RPi schematic to provide the FPV audio (left channel) and the input to the audio amplifier (right channel) for a 4 or 8 Ohm speaker.

Deimos
06-22-2016, 05:09 PM
I'm hoping to bring my mech to this one. I've got significantly more resources at my disposal now thanks to my university; most importantly a machine shop and a couple comp-sci guys who volunteered to help out :cool:. Our goal is to have off-board vision processing for targeting and localization by the end of this summer, and we're looking into solutions to replace/augment the femur servo (ax-12a currently) for better navigation of varied terrain and longer runtimes. If we succussfully implement localization/mapping and auto-targeting in a reasonable amount of time I expect we will be bringing a fully autonomous mech to the games.

Tician did you end up continuing work on your carbon-impregnated polyolefin panels? I think they are a promising alternative: inexpensive, thin, and predictable. I would be happy to redesign and order up a new batch if you guys are interested in seeing how they compare.

tician
06-22-2016, 05:48 PM
Pretty much abandoned the PCB with interleaved traces, UHMWPE film, and self-adhesive rubber sheet combination for numerous non-technical reasons. Had them mostly working with ATtiny85 but never fixed the last I2C bug and still a gigantic pain in the ass to fully assemble without a die cutter or laser cutter. Destroyed a couple boards trying to reflow with high temp solder paste and a skillet, but think there are a few more undamaged and unassembled in addition to the three fully assembled and programmed boards. Populating them with an ATtiny13A, or ATtiny85 without I2C, works just fine for emulating a plain FSR panel. Eagle files and BOM for the version I ordered from Seeed should be up on my fork of the mwscore repo on github. Not entirely sure that version of the firmware actually works; should work with ATtiny13A, but pretty much guaranteed not to work with the ATtiny85.

tician
06-22-2016, 07:03 PM
Ooooohh. OSHStencils now offers 4mil stainless steel in addition to 3mil and 5mil polyimide. And a new, less clunky website. Might be making an order if I manage to snag a certain job offer.

A slightly reworked version of my target PCBs to enable 3.3V power supply is up on the yetis branch. Basically puts the LEDs in parallel instead of series, but still uses ATtiny13/ATtiny85 in a dual SOIC-8 footprint (can handle 4.00mm JEDEC or 5.30mm EIAJ). Thinking that I kept placement of all components exactly the same as the older version to enable reuse of stencils.

jwatte
06-23-2016, 11:09 AM
puts the LEDs in parallel instead of series

Presumably with separate current limiting resistors, though?

tician
06-23-2016, 01:54 PM
Low power indicator LEDs and did not want to add more parts, so no. Resistors are sized to keep current well below maximum for a single LED, and intensity differences between LEDs on each channel are not significantly noticeable during the brief periods they are actually lit. Was going to remake the board to use a NXP/Freescale KL02/KL03 in QFN-16 package with each of the four LEDs independently controlled and both UART and I2C interfaces, but never bothered to finish that.

giantflaw
10-13-2016, 06:32 PM
Robogames 2017 date is set for April 21-23 at Alameda County Fairgrounds. Same location as last year. So get your Mechs up and running with whatever improvements you can muster between now and April (6 months). Mechwarfare is still not listed on the main EVENTS page at this time but is listed on the Registration page. I sent a request to Dave to elevate our event to the main EVENT page.

giantflaw
10-18-2016, 08:29 PM
Mechwarfare is now listed on the Robogames 2017 main Events page. If you click on the event it will drill down to the rules from 2010 which is out of date and only a place holder at this time.

GhengisDhon
10-29-2016, 08:54 AM
6720

Here's a list of changes/potential changes we're working on for Robogames 2017

1) Transponder Changes - There will be transponder changes to deal with the noisy environment at Robogames. HPs will be stored locally on the Mech and periodically transmitted to the scoring station. This way, in case of a noisy environment, hits won't be lost bust just temporitly delayed in updating. We don't expect any hardware changes, just a new upload of SW.

2) Target plates - There will be official target plates for Robogames 2017. These will be provided to contestant at the event. We haven't decided on a final design yet, but it will be similar to the 2016 Robogames piezo design. We will release the design as soon as finalized if people want to make some for their own use (but only the officially provided plates will be allowed at the event).

3) Target Plate Attachment - There wil be an official attachment method for the target plates. It will most likely consiste of two velcro strips running the full length of the target plates sides. The recieveing velcro strips on the Mech must be the same size and firmly attached to the mech.

4) WiFi cameras will not be officially supported this year. If contestants want to bring their own WiFi set up, they're free to do so, but any issues fall on the contestant to resolve.

5) Light Mechs - We MAY have a light Mech category. Basically a weight and/or size limit on the Mech. The light weight Mechs will have smaller target plates and correspondigly fewer HPs. We have a couple of club members working on the concept right now (using Dynamixel XL320s). If anyone else is workign on light weight Mechs, please do let us know.

6) Arena Size - We MAY increase the arena size slightly. If we do, it will most likely be 15' x 20'.

7) Arena Layout - We MAY change the building layout/sizes. We've found in the RTeam Scrimmages, more/smaller buildings seems to increase the action.

8) CO2 Guns - If anyone is working on CO2 guns, please let us know. We may change the rules to accomodate.

More to follow....