PDA

View Full Version : How to get 12 or more Mechs competing next year.



Robot Dude
07-15-2009, 09:26 AM
I've given this some thought and have come up with an idea. Out of the box, paradigm shift, thinking here. The main problem is with getting the video from the bot to the pilot. It appears to be a major hurdle to overcome for all of the builders.

The contest organizers are already providing a Zigbee based target system for the bots. Because it's only tracking hits to a sensor it seams severely under utilized. I don't know much about wireless communication for data and or video, but it stands to reason that it should be possible to make a dedicated device to do this and make it part of the hit tracking system. The cost would be more, but it would enable many more to compete.

In other words the contest organizers should make a system to handle the video and hit recording to take the burden from the builder. The device should have a master controller that talks to the satellite boards on the bots, gather hits, and grab the video and provide it to the pilot as a standard NTSC video signal. The pilots would only need a cable with RCA connectors to run to a cheap video monitor. The data direction would be receive only from the bots. Is there a faster version of Zigbee that could do this? The transmitters (on the bots) would be as small as possible using surface mount technology. They would have a video input that any inexpensive camera could connect to. Cameras are available for as little as $20.00. Alternatively a digital camera like what is used on the CMU cam could be used, although probably more expensive and more difficult to interface.

The circuit could stack on the target for a single easy to mount part, additional sensors could plug right in. If additional bandwidth is available the device could actually provide a serial port or network node that could also be used by the pilot. Rather than a 3" square I would recommend a 3" octagon. Round objects are much easier to place on a bot than a square.

By making a single system that pilots plug into it eases the build requirements significantly. I do not expect anyone to reply with "it's impossible" or "it can't be done" because it is basically what the contest organizers expect each competitor to do on their own. Why force all builders to reinvent the wheel here. Please don't just attack this idea and immediately shoot it down. Instead try to be positive or at least provide constructive criticism.

Anyway I think it's an idea at least worth exploring by the people who live eat and breath this wireless stuff. I'm just an idea guy. lol

ScuD
07-15-2009, 09:42 AM
As I stated in another post, I don't have the knowledge required to make any statements regarding the video data transfer.

However, I did have a question for those familiar with the Xbee products.

As I understand, these are not true Zigbee products, in that they don't support the entire Zigbee protocol (cutting down on licensing costs, perhaps?)

Anyway, I've been looking into the Microchip MiWi protocol, which is similar to Zigbee, but also lacking a few of the "bigger" Zigbee features, it sparked my interest since there's a board readily available for 8€ or so.
I'm talking about the MRF24J40MA (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en535967)
Downside is, you still need to implement the MiWi stack on an external controller.

So, if one was to build something as per Robot Dude's suggestions, wouldn't it be cheaper to use one of these, and implement the protocol in the controller that's used for the hit count/sensors anyway ?


Then again, the MiWi protocol is only "available" for PIC micro's, plus I guess you'd have more than enough code on your hands handling the video..

ScuD
07-15-2009, 09:44 AM
Did a small google search, apparently it's very possible to transmit video over zigbee:

PDF file here (http://www-seungjun.com/products/zv_module_eng.pdf)

Trying to locate more info on this right now..

lnxfergy
07-15-2009, 10:03 AM
Scud, per your XBEE/Zigbee questions: Zigbee is just a wireless protocol, sorta like 802.11b or 802.11g. It is designed for lower costs/lower speed transmission that 802.11 protocols, the intend being that you can hook your toaster to your fridge to your ipod wirelessly (at least, my understanding is that ZigBee is supposed to be the 2.4ghz protocol for new and upcoming wireless embedded devices) An XBEE device simply is compliant with the base protocol, but adds some easy to use IO on top of it. Different XBEE devices provide different levels of network topologies.

-Fergs

lnxfergy
07-15-2009, 10:09 AM
By making a single system that pilots plug into it eases the build requirements significantly. I do not expect anyone to reply with "it's impossible" or "it can't be done" because it is basically what the contest organizers expect each competitor to do on their own. Why force all builders to reinvent the wheel here. Please don't just attack this idea and immediately shoot it down. Instead try to be positive or at least provide constructive criticism.

There is a HUGE difference between slapping an IP cam on a bot, and building a wireless webcam from scratch. I'd expect that most people can do the first one, and that there are only a handful on this board who could pull of the second in a way that is highly reliable.

I know I don't have such skills (or time/money for prototyping). Thus, to have such a thing happen, someone has to step forward, and show that they have the time/skills/dedication to have such a thing happen, since I put together the first scoring system (after a previous person was unable to find enough to time to do so, there's just not that much time in a day for most people, we're all sorta busy). It's also gonna be hard to test such a system prior to RG, unless we call up a real standards testing body and borrow thier equipment. I'd imagine a great way to kill a competition would be to have everyone show up and then find out the camera they have doesn't work...

-Fergs

ScuD
07-15-2009, 10:28 AM
@ Fergs: thanks for the info on the Xbee, I'll order a few of the microchip samples to play around with in that case, the xbee is hard to get back here and (a lot) more expensive..


As per the post: on my way back from work I was thinking about this a bit.
All I can remember from video is an experiment a few years back to get a PIC to output a pal signal. I remember the 1µs ticks being very close to the time frames needed (meaning, code loops would prove too slow, you could only use NOP's)

So going with that knowledge, I imagined an ADC that can sample at 1µs, constantly streaming this OTA through the zigbee link. That would mean a 1MBps, or 8Mbaud continous connection. I guess without compression there's no way it's gonna happen.

Even with encoding I have no idea of the datarates that, say 320*240 @ 25fps needs in for example MPG4.

Interesting food for thought, but I do agree on this being a hard one to tackle, even with all the spare time in the world.

lnxfergy
07-15-2009, 10:36 AM
Interesting food for thought, but I do agree on this being a hard one to tackle, even with all the spare time in the world.

Yeah, this is true-blue EE stuff. Especially when you consider the amount of engineering and testing that goes into building any Wireless device, just laying out the PCB can take an entire team. The encoding/compression of the video is a serious project on it's own.

If you resort to using off-the-shelf wireless & video components, and something like an ARM to do the encoding, I'd imagine you'd end up with something similar in size/weight to the existing webcams like the trendnet. There isn't that much wasted space on a trendnet camera, the power/ethernet connection board is probably the only majorly bulky part you could remove in your own design. The camera part itself is smaller than the module used on the AVRCAM/CMUCAM.

-Fergs

Robot Dude
07-15-2009, 10:47 AM
I haven't limited my thinking to any technical limitations because I don't know what they are. lol It may be a dead end, but I wanted to put it out there to see what developed. It seams so simple in theory. Add video to the hit counter circuitry, by upgrading to faster modules. :P

ScuD
07-15-2009, 11:14 AM
There's a dutch expression that goes like this : "Niet gehinderd door enige kennis van zaken", which, literally translated, means "not held back by any knowledge on the subject".

It's usually meant in the bad way, but originally it has it's origins in something along the lines of "thinking outside the box", so don't worry about it ;)

With the abundance of cellphone camera's these days I'd say the size restrictions indeed lies in the processing part.
Lynn talked about the Propeller, haven't really read up on it yet, though I do know it can be used to create video.
If it could reverse the process easily as well, that'd be a good thing..

dcalkins
07-15-2009, 12:06 PM
In other words the contest organizers should make a system to handle the video and hit recording to take the burden from the builder.

Heck, why don't the organizers just build the whole bot? And pilot it too? I mean really, what's the point of RoboGames - it's not like it's to show the proficiency of the robot builders. It should be just one big video game.

DresnerRobotics
07-15-2009, 12:07 PM
I like the idea, it would be great to have a single "Mech Warfare Unit" to add to bots and have them more or less competition ready... I think the problem here is the skills and time required are much more than I can personally handle. lnxfergy and Adrenalynn are my partners in crime with the technology we're using here; Fergs has a PhD he's supposedly working on, and Adrenalynn is equally busy with her job... I simply don't think we have the resources to develop such a piece of technology, push it into small-run production, and have it tested in a noisy environment.

The Trendnet camera is VERY solid for the price, and relatively small once stripped down, which more or less solves the video problem for the vast majority of people. Even then, Wifi is still somewhat prone to interference, having the scoring system on a 'failsafe' separated system ensures we have an accurate score that isnt effected by external interference. Fergs and I will be working to improve this and package it as a complete plug and play (including target panels) system for next year.

I'm still open to suggestions though, if someone with the time, resources, and know-how wants to step up and take a shot at such a thing I'll not be a one to discourage them.

DresnerRobotics
07-15-2009, 12:13 PM
Heck, why don't the organizers just build the whole bot? And pilot it too? I mean really, what's the point of RoboGames - it's not like it's to show the proficiency of the robot builders. It should be just one big video game.

I think Jim's intention here is simply to make the competition accessible to a wider variety of people. It would be great to drop a Camera/Scoring unit and a gun onto an existing humanoid and be ready to rock and roll, and would certainly open the doors to more people. A lot of 'our kind' tend to procrastinate, and the bar is set VERY high for competing in Mech Warfare, so lowering that bar a bit is fine by me.

Adrenalynn
07-15-2009, 12:48 PM
I can probably field the majority of video questions. [begin qualification statement] I've been doing video (analog and digital) for more than twenty years, have 30+ patents in 17 countries, and have designed both hardware and software for the space. My code flies on a handful of satellites currently delivering broadcast to a bit more than half the globe.[/end qualification statement]

There's a lot that needs to be considered. The first is NTSC... NTSC is inherently analog. In order to ship NTSC out over wireless, we either need analog radio spectrum (rare these days), or we need to digitize it.

In the unlicensed analog spectrum, we hobbyists are limited to a couple channels in UHF. Those channels are actually not that bad, because they're primarily unused, but *very* low power.

In the unlicensed digital spectrum, we have to digitize the video, but we get two channels in 900Mhz, four channels in 2.4Ghz, and 16 channels (32 with mux) in 5.6Ghz. 1.2Ghz is law-enforcement, although you can buy and [illegally] operate two channels there.

The higher we go in frequency, the more we suffer from the foibles of microwave. 2.4Ghz doesn't handle moving antennas well at all. And the band is so crazy crowded hideously ugly jammed that basic "digitize and blast" doesn't work well in most venues. 5.6Ghz is becoming more crowded, but is still pretty good. 5.6Ghz allows for unlicensed general purpose spreadspectrum so is much more robust. That said - it doesn't like its antennas to move even less.

As we get into microwave, we also have to face the reality of ground absorbtion - especially on that rubberized floor and how low we're putting our antennas. That's the reason I suggested patch antennas pointing at the ceiling with a centralized patch on the ceiling connected back to the router. Another reason for this methodology is side-signal rejection of stray RF. Still not going to cut it for "digitize and blast"...

802.11g/n is actually pretty darned robust. It's dual-band (2.4/5.6), and has some inherent error checking. It's a true digital format, both at the hardware layer and at the packet layer. It also doesn't care less what it's trying to blast through, so if you have video out there, it's just going to blow holes in it for fun as it hops across the spectrum.

NTSC video purely digitized is about 160mbit/sec. So we need to compress it.

DV compression is 25mbit/sec. Very decent quality, but still not manageable.
So we get into the Motion Picture Expert Group compression technologies - MPEG.

MPEG1 is an old method. No advanced motion prediction. Stomps on the color space. Falls apart much past CIF resolution. That's why it's commonly used for the CDROM video encodings. It starts looking useful at about 1.5mbit/sec. Licensing fees are fairly inexpensive.

MPEG2 is the standby. It's used on DVDs, and primarily in digital broadcast HD. It looks nearly as good as DV at 19mbits/sec. At 3-5mbits/sec we can start getting into DVD quality, and at about 1.5mbit/sec on the bottom end it falls apart.

MPEG4 is the "Internet Standard". There are multiple forms of MPEG4 (called "profiles") and everyone and their brother has extended it in some way. Advanced motion prediction is the norm. "Postage Stamp Video" can be achieved at about 36kbit, but it doesn't look good. The MPEG codecs work by using index frames sent at some rate, and only frame changes (sprites) in between. Generally, when 30+% of a frame changes, a new index frame is sent. 36kbit isn't really 36kbit. MPEG4 video on the Internet looks as good as it does because it gets buffered. There's a delay as we "look ahead" and try to average the stream out, and send index frames before we need them - because index frames tend to be at least 4x larger than intraframes.

Live MPEG4 is much harder because we can't do this. This is the realm of hardware compression now. We can start getting live 320x240 (about 4CIF) video at around 500kbit/sec average. Licensing is very expensive.

h.264 is the "codec of a million names" - and is really just a new MPEG4 profile with some new motion prediction. It can cut the bandwidth requirement for the above down to about 250kbit/sec. Licensing is crazy expensive.

This post is getting long, so I'm going to leave wavelets and hybreds out.

Now - that 250kbit/sec really needs peaks up around 1mbit/sec. But we're trying to send at least 15fps. We have no backchannel for live video - it's LIVE. We can add a backchannel to tell the encoder to throttle up/down, but that's in the past. So we need Quality of Service Assurance.

The xbee isn't going to provide realtime QOS natively, so we need to implement it ourselves if that's the hardware and packet layer we choose.

Is sending out reliable video a doable project? Yes. It could be developed for $2500-3000. It would operate in 802.11g/n. Each unit would cost around $1200 in Q:100.

Of course, we can buy a high quality encoder board out of china for a few hundred dollars that is reasonably light, and then hang a "spy camera" on it for another $50 that is of marginal quality, or an awesome camera (ExWave CCD) for ~$150ish.

I suggested this system last year. Only one person (Tybs) bit on it. No one else wanted to spend ~$500 on a video system...

If someone can beat this technology - Mech Warfare is the least of their concerns. We sold my patents and prototypes for $30M+ last time... ;)

Whew. There's a short primer on the realities of video. I started glossing towards the end. Happy to answer any questions in that arena!

DresnerRobotics
07-15-2009, 12:56 PM
Yeah I did go the Wifi Video Encoder unit + High quality camera route originally... problem was, for $500 it was only marginally better than the $100 Trendnet camera, and 3x the size. Weight wasn't substantially more, but the video encoders have a HUGE PCB footprint.

Adrenalynn
07-15-2009, 01:11 PM
Yeah, they do. A lot of that is needing to spread that wicked leaky analog RF stuff out away from the digital side.

The really big advantage you had was the quality of the camera rather than the encoder. That camera was inhibited by the transport - it could do *much* more.

I notice I didn't cover picture-push vs streaming and drag mjpeg into the fray. Maybe I'll do a follow-up and explore that...

Under MPEG4 and h.264, I should have extended why the "30+%" was important. As our 'bots run along, 100% of the frame is changing. Which means we're sending full-rate index frames all the time. Which means we get no intraframe, and we get no motion prediction - so we're really just doing mjpeg (motion jpeg) which is picture-pushed jpeg.

Which, incidentally, might be the way to go. I bet a Prop could do JPEG2000 compression at [email protected]~10fps or a little less. Easy to implement, I should look at that. We might squeeze JPEG2k onto a couple shot-gunned xbees, but we'd still get no backchannel and no error correction...

ScuD
07-15-2009, 01:23 PM
Lynn, thanks for that HIGHLY informative post. I'd +Rep you, but you're off the charts allready..

It's grand to get someone to explain the workings in laymen's terms, now I've read this, it all seems so "simple" and "obvious" (well, the basic principles at least)



We sold my patents and prototypes for $30M+ last time... ;)



I'm starting to wonder what your house looks like...

scowby
07-15-2009, 01:30 PM
I saw a post here about using a TrendNET wireless webcam to aid in computer vision. I can't remember where the post is, but could you guys use this as some sort of "standard" camera setup?

lnxfergy
07-15-2009, 01:49 PM
I saw a post here about using a TrendNET wireless webcam to aid in computer vision. I can't remember where the post is, but could you guys use this as some sort of "standard" camera setup?

It pretty much is the "standard" as in it's being the only one known to be light enough and reliable enough to work well. Issy, Giger, CLYDE, and Shadow Scout all had a TrendNet. Jes's mech (which wasn't able to be at RG) also uses one. After the weekend, and fighting with an Airlink, Bheka will shortly have one.

-Fergs

darkback2
07-15-2009, 08:09 PM
@ jim,

This time lat year we were still talking about using those cheap wireless cameras that only come in four channels, and wouldn't have possibly worked. Last year, the trend net cameras seamed to do the trick pretty well, and in a way worked independently of the bot itself...so long as they had power, you had a pretty good chance of getting your video. It was whicked slow at times, but for the most part it worked.

I too proposed that we either collectively purchase a camera system, or that one be available for rent, and was met with the following responce...

The robots are all too different from one and other.

The simple truth is, that while there will be 10 issy's next year, especially now that fergy has released the code and how too, so really, the "organizers" have already done just what your asking for. well...nt exactly, but you get it...build an issy, and buy a trend net. problem solved!

DB

lnxfergy
07-15-2009, 08:24 PM
@ jim,

This time lat year we were still talking about using those cheap wireless cameras that only come in four channels, and wouldn't have possibly worked. Last year, the trend net cameras seamed to do the trick pretty well, and in a way worked independently of the bot itself...so long as they had power, you had a pretty good chance of getting your video. It was whicked slow at times, but for the most part it worked.

I too proposed that we either collectively purchase a camera system, or that one be available for rent, and was met with the following responce...

The robots are all too different from one and other.

The simple truth is, that while there will be 10 issy's next year, especially now that fergy has released the code and how too, so really, the "organizers" have already done just what your asking for. well...nt exactly, but you get it...build an issy, and buy a trend net. problem solved!

DB

Well jeez... I would hope we don't have 10 issy's next year. I posted that tutorial/code as a starting place or example, if a bunch of people just build/download/fight, that'd be pretty disappointing, cause issy had plenty of issues.

I think the problem with a collective purchase or centrally managed video solution, is that it will almost certainly require further cash outlay from the event organizers (read: tyb). A number of competitors were unsure until right up to the end whether they would be competing... and most of the people who early on said they would be a competitor did not end up doing so.

As for the trendnets video issues.. I think Adrenalynn had a pretty decent idea with putting polarized antennas on them and a polarized antenna for the router on the ceiling. It would probably improve the video quite a bit. Unfortunately, it either requires lots of router antennas on the ceiling, or a centrally managed router and network backplane.

-Fergs

Connor
07-15-2009, 09:38 PM
As for the trendnets video issues.. I think Adrenalynn had a pretty decent idea with putting polarized antennas on them and a polarized antenna for the router on the ceiling. It would probably improve the video quite a bit. Unfortunately, it either requires lots of router antennas on the ceiling, or a centrally managed router and network backplane.

-Fergs

I think it would be best to go with a centrally managed router with multiple wireless cards and ethernet jacks. The router I used was not your average WiFi router and had plenty of power to handle it.. and in fact, they often used for outdoor wifi deployments etc.. I can customize them to fit our needs and have a wide range of power and sensitivity for the wifi cards. One thing we did notice is if you where using your own router and your PC was wireless to it, and wireless to the video Camera, your frame rate would suffer.. This is a common issue because Wifi is half duplex and the wifi card has to keep switching from transmit to receive which cuts the throughput in half. When we used ethernet to the router and then wireless to the camera it helped a great deal.. So, I highly recommend using that setup next event. We use 2 separate antenna's on the celling and use non-overlapping channels. Each mech gets it's on SSID which assoicates it to one of the antenna's that way we don't have to worry about the 2 cameras flooding the wifi.

Thanks, Connor

Adrenalynn
07-15-2009, 10:18 PM
I was digging up my cycling stuff, and even found the perfect antennas in a box. I have three of them. (for the ceiling deployment) 1ft square, 24dBi dual-band.

Connor
07-15-2009, 10:51 PM
I was digging up my cycling stuff, and even found the perfect antennas in a box. I have three of them. (for the ceiling deployment) 1ft square, 24dBi dual-band.

Dual Band won't help much because the camera's are only b/g.. not a. So, no 5.xghz... What's the beam width those antennas and the connector type.. (So I can see about getting cables at some point)

Thanks, Connor

Adrenalynn
07-16-2009, 01:55 AM
Yes - but they're n/pre-n-ready.

I'll post the propagation charts probably tomorrow after I look 'em up.

I have bulk cable and connectors - you just tell me what you need. I can do SMA, RPSMA, TNC, or N (male and female) Never worry about that - I *always* carry an entire toolbox full of connectors and gender-changers for _everything_. ;)

Robot Dude
07-16-2009, 09:38 AM
@ Adrenalynn

I had no earthly idea sending low res video digitally took so much bandwidth. I thank you for taking the time to explain it in great detail. I am purchasing some of the TrendNET cameras to play with. We'll update the BRAT mech page when it's operational. Thanks again for the info.

Robot Dude
07-17-2009, 08:11 AM
Just an idea... The TrendNET 212 has audio. The bots own microcontroller can easily provide DTMF touch key, FSK Caller-ID, Baudot TTY Code to send the hit plate information. A single pc could listen to all of the cameras on the competing bots with ease (I think) as the video could be ignored. To reduce the risk of lost information instead of sending each hit the bot receives it could just send the accumulated hits, i.e. it would send a number representing how many hits the bot received every 10 seconds. In addition to hits the system could also be used to send info from the bot to the pilot, such as battery level.

So if this worked it would eliminate any hit counter zigbee devices alltogether. The builder does have to prove the bot sends the appropriate signals when it's been hit, but I imagine that is already part of the bots check in.

Down side is people would have to reinvest in an audio capable wireless cam. The cost is more. A more robust wifi antenna array could improve the wifi reliability. I think I read something about this being implemented anyway. I should have read more older threads before jumping in to "try to help" sorry about that.

@ Adrenalynn

I look forward to your thoughts.

lnxfergy
07-17-2009, 10:14 AM
Just an idea... The TrendNET 212 has audio. The bots own microcontroller can easily provide DTMF touch key, FSK Caller-ID, Baudot TTY Code to send the hit plate information. A single pc could listen to all of the cameras on the competing bots with ease (I think) as the video could be ignored. To reduce the risk of lost information instead of sending each hit the bot receives it could just send the accumulated hits, i.e. it would send a number representing how many hits the bot received every 10 seconds. In addition to hits the system could also be used to send info from the bot to the pilot, such as battery level.

So if this worked it would eliminate any hit counter zigbee devices alltogether. The builder does have to prove the bot sends the appropriate signals when it's been hit, but I imagine that is already part of the bots check in.

Down side is people would have to reinvest in an audio capable wireless cam. The cost is more. A more robust wifi antenna array could improve the wifi reliability. I think I read something about this being implemented anyway. I should have read more older threads before jumping in to "try to help" sorry about that.

@ Adrenalynn

I look forward to your thoughts.

Unfortunately, that means people have to spend an extra $70-100 on a camera with audio, to replace a $20 xbee. They'll still need a micro to read the panels and then create DMTF output, and it's not very well regulated then either. I'd like to think nobody would cheat, but what happens if they just make a mistake. Also, i'd be worried about how loud you'd have to make the DMTF to be heard over the battle bots. This would also force us to have a central router if the scoring machine has to listen in on all cameras. I'd imagine that would also slow the network/camera down signifigantly.

-Fergs

jes1510
07-17-2009, 10:35 AM
I think the following is pretty much all that's needed to get people off the ground floor with building a mech:

1. Standardized targets that are prepackaged and pre-tested. Publish known dimensions, weights, etc for designs. All competitors use the same thing and buy them already done. The design on this system is non-negotiable and all mech designs must be done in a fashion that allows them to be integrated.

2. Chassis reference designs. Have a reference design for a biped that works and a quad that works with code available.

3. Standardized communications protocol. The protocol should be standardized with good noise immunity with error detection and compatible with the reference designs in library format.

All of the above are being worked on in one form or another. Everything else should be left up to the builder.

lnxfergy
07-17-2009, 10:52 AM
1. Standardized targets that are prepackaged and pre-tested. Publish known dimensions, weights, etc for designs. All competitors use the same thing and buy them already done. The design on this system is non-negotiable and all mech designs must be done in a fashion that allows them to be integrated.

The dimensions/weights are already out there, but just to follow up: Transponder board: 2.4"x2.4", max height of 0.75", mounting holes in each corner, 0.15" in from the edges, w=~25g. Scoring panels are 3x3", weight of 2009 panels was about 20g on 1/8" lexan, which was overkill, I'd imagine the newer panels will be <15g each.


2. Chassis reference designs. Have a reference design for a biped that works and a quad that works with code available.

3. Standardized communications protocol. The protocol should be standardized with good noise immunity with error detection and compatible with the reference designs in library format.If Jim's bot is able to carry full payload for 15 minutes, he'll probably have your biped reference design (as well as the budget design) with an absolutely stand-out tutorial on how to build it. The Issy tutorial (http://forums.trossenrobotics.com/tutorials/build-articles-130/build-your-own-issydunnyet-3257/) is mostly done, lacking a walkthrough of the code. The code has been updated to be Sanguino compatible and is on my SVN server already. DB also has a tutorial on building squidword (http://forums.trossenrobotics.com/tutorials/how-to-diy-128/building-a-mech-using-dbs-bracket-system-3099/).

-fergs

Robot Dude
07-17-2009, 11:54 AM
Unfortunately, that means people have to spend an extra $70-100 on a camera with audio, to replace a $20 xbee. They'll still need a micro to read the panels and then create DMTF output, and it's not very well regulated then either. I'd like to think nobody would cheat, but what happens if they just make a mistake. Also, i'd be worried about how loud you'd have to make the DMTF to be heard over the battle bots. This would also force us to have a central router if the scoring machine has to listen in on all cameras. I'd imagine that would also slow the network/camera down signifigantly.

-Fergs

Yes the camera costs more, I already mentioned that. But I'm not suggesting this to save the cost of the zigbee, but to reduce the rf in the area. If everything was handled by the cameras, it's got to be simpler and more reliable.

Yes they will need a microcontroller, but don't these bots already have one. Using the already present micro reduces the weight and pc board real estate of the bot.

How loud? You're kidding right? The DTMF decoder would connect to an audio output from the server... A very simple inexpensive device actually. A central router has already been discussed as a good idea.

Edit: If you mean on the bot end. The micro would send the DTMF directly to the cameras mic input. Yes a simple hack to the camera.

How would monitoring audio from a camera that is already designed to send it slow the network/camera down at all.

I don't mind criticism, but maybe you could substantiat some of these concerns.

DresnerRobotics
07-17-2009, 12:08 PM
I like that we're thinking outside the box here, much appreciated input Jim.

My concern about this is it would more or less indicate we'd definitely need a single centrally managed router, which could in turn run into bandwidth issues... not 100&#37; sure of that, but its a possibility. Also if possible, I'd prefer any provided 'all in one' unit to still be an optional thing, not a complete requirement... something like this would move towards it being very proprietary.

One thing to keep in mind is that the current system does not suffer from any cross interference from the wifi system.

lnxfergy
07-17-2009, 04:53 PM
How loud? You're kidding right? The DTMF decoder would connect to an audio output from the server... A very simple inexpensive device actually. A central router has already been discussed as a good idea.

Edit: If you mean on the bot end. The micro would send the DTMF directly to the cameras mic input. Yes a simple hack to the camera.

I did mean the bot end, but was not thinking about hacking directly into the camera mic input. Generally the mic's on these cameras are near garbage, and without a hacked input, the pickup would probably not be very good. You'd also have to worry about two bots getting in close enough proximity that they pick each other's output up. Of course, if you hack the input, that aleviates the issue -- but also requires people to solder into a $180 camera.


How would monitoring audio from a camera that is already designed to send it slow the network/camera down at all.

Because now you are routing the packets to two locations, these cameras operate as a server to which PC's connect. If you have both the competitor and the scoring dep't connected at the same time to each camera, you have 2 connections, and thus the camera is pounding out 2x as many packets. Now, add 2 competitors and 2 conenctions with the scoring computer, and you have 4 full stream video connections running, and then try to do 2-on-2 matches, we are up to 8 full streams. I doubt the camera has the ability to stream just the audio, if it did though, it'd eliminate some of the bandwidth needs... I'd also be concerned about how exactly the audio would degrade... with the video, it degrades by dropping frames/parts-of-frames, with audio, you have no frames exactly, I'd be concerned that you'd have a tough time pulling DMTF out of a garbled audio track, especially if the time-base starts to become highly skewed.

-Fergs

lnxfergy
07-17-2009, 05:24 PM
While outside the box is great, we have to also consider what can be accomplished by amateurs and hobbyists, all of whom do this part time as a hobby. We also have to be sure that any device forced on a competitor holds up inside the RF nightmare of robogames, and if it fails to do so, it does not affect the competitor signifigantly. That said, here's my final thoughts on this discussion:

The current scoring system is <$100, and the wireless is highly reliable. The amount of data sent by a scoring transponder is extremely small (about 10 bytes at 38k4 baud), thus it is likely not causing much interference with the wifi cams. The issues we had at the event were A) a bug in the receiving software and B) the panels being unreliable. The bug will be fixed, and really I plan to be improving the overall transmission protocol, we were kinda down to the wire with building the system last spring. The panels issue has to be dealt with regardless of what we do, but I think the FSR panels show great promise. The panels are what they are, I don't think we can greatly improve the weight on them without seriously raising the costs. The transponder board is smaller than a panel, current draw is fairly low, weight is similar to a panel and as I've said a few times, you could lighten it further by removing the regulator and proving your own 5V supply. For the quantity we are doing, I think it is entirely unreasonable to expect that Andrew is going to handle assembly/costs for a smaller SMD version - even then, the XBEE and headers are most of the size of the board. We chose to go with the existing board because it was cheap, available, and easily assembled.

I think integrating the camera/scoring together is entirely the opposite route we want to go. It would lock us into a limited number of cameras. While I frequenly promote the Trendnet camera, I don't think it's the only solution out there. the reason I suggest the Trendnet is that when most people ask "which camera?" they ask because they don't want to spend a bunch of time/money testing out unknown variables. Andrew has gone through an Airlink camera (poor video), a very high end encoder/pin-hole-cam version (too big), and eventually settled on a Trendent on Giger. I'm sure there are other cameras currently available, but most are likely either larger, heavier, or more expensive. I would hope that as this technology evolves over the next few years, IP cams will become smaller/lighter and cheaper -- but that's a massive corporate initiative, not something that will be done specifically for this competition. Again, it's all R&D costs (people, parts and more people).

I think we also have to be careful not to lose focus. We had dozens of threads about weaponry last year, that were outside the box. In the end, 90% of these folks did not produce a working mech. I think that our current focus should be on promoting documentation on how to build the walker. Really, once you have a walker with enough payload capacity, you just slap the IP cam/guns/scoring on. Plug a router in, hook your laptop up. You can even just view the IP cam through a web browser, and then use a handheld controller to drive. The tough part for competitors is to make sure they have a walker that A) can walk reasonably well, is stable (and can hopefully upright itself if it falls over much) B) has enough payload capacity C) with that payload, has enough power capacity to fight for 15 minutes D) carries enough ammo to score enough hits and E) has fine enough control that you can target easily. Once they've got those basics, time is best spent making the bot walk quicker, and testing to be sure everything is reliable.

-Fergs

Adrenalynn
07-17-2009, 05:26 PM
I'm planning a more thought-out response. I did want to jump in with a quickie directed at Fergs -

The audio is generally either mpeg layer 3 or GSM. The former at a higher bandwidth, the latter usually at 3-8kbit/sec.

Believe it or not, although lossy compressed, you can squeeze many types of encoding over it, even some PSK/FSK at a reduced rate. I've successfully sent 1200 baud over them, even well enough to get a fax through. GSM is generally the compression you'll find on digital cell phones. It's very light-weight algorithmically.

It's throwing away fidelity rather than frames, in much the same way that mpeg video throws away fidelity first. Your experience with the camera throwing away frames was primarily because you adopted picture-push [jpeg] instead of mpeg streaming.

And speaking of that - the receiver could be centralized, just talking off the top of my head. And I believe you could also have made a connection to the camera from linux via streaming with a little more work. mplayer could probably have been convinced to receive the streaming video and audio - and ffmpeg/ffserver could have worked as a centralization point which would only require one stream from each camera and then resend it out broadcast over the wired network.

That said - I have some issues with this suggested plan, not all unrelated to yours. I'll need to post back later though as I'm runnin' out the door.

ScuD
07-17-2009, 05:58 PM
I tend to agree with Fergs on the biggest issue at this point being increasing payload.

I'm still writing the tutorial on my ubersimple quad design, and wasn't really planning on rebuilding the thing with all things I've got going on (the bioloid firmware, the bioloid quad in itself, the CPG's, and I've still got a miniature balancing bot, in complete analog electronics hooked up the breadboard) but I do remember I could put a pair of Vans shoes on top of it (and those aren't the lightest...) and it walked with ease, as the servo's only act to raise the foot off the floor.

So I might just rebuild it, to get better pics for the tut, and to do some testing on payload..

Also, as per bipeds, springs might help out. Not the easiest task, but given the correct springs and attachment point, in theory you should be able to offset most of the positions that require the highest power (eg ankle servo's)

Overall I think the best way to go would be complete mechanical overhauls, but that's something that's gonna take time.

A few low-priced, simple designs to get more people into the competition seem key to me, to get this more popular and as such get more people, more minds, better designs, and better improvements.

redwolf3
07-19-2009, 06:22 PM
Hey Guys-
Thought I'd chime in on this subject a little. I was one of those people who was going to build a mech for the event, but sadly work got the best of me and I was never able to gather enough time to get a mech together for the event.

On the topic of processing camera data, it might be worthwhile to take a look at Circuit Cellar from a month or two ago. They had some articles on robots, and one of the articles was someone who had taken a propeller, and set it up to process video signals and streaming them back to a computer for processing / analysis. From what I remember, it was black and white video, but if memory serves, the article also indicates that the total video processing thread could have easily handled 50 fps of black and white data. And this was all done using only one of the 8 cogs on the propeller.

From this design, I was thinking it might be possible to separate out the color streams from a camera into multiple individual streams, one per color (or possibly, one stream per sector of the video stream), and then use multiple low-bandwidth connections to stream the video.

Obviously, this is not a fully thought out idea, just the beginnings of one... but thought I'd at least pass along the Circuit Cellar article if nothing else.

Adrenalynn
07-19-2009, 06:53 PM
Linkage? There's no NTSC input on the Prop that I'm aware of, although it can do software NTSC output.

robologist
07-20-2009, 12:25 AM
Think this might be it (http://www.circuitcellar.com/archives/viewable/226-Bachiochi/index.html)? Was lucky the article was a freebie.

Adrenalynn
07-20-2009, 02:27 AM
I hope it wasn't that one. That's just a discussion of the toy video game console throwback that is the Hydra.

No video input there that I could find. No encoding, no digitizing, no broadcast. Just a review of NTSC. Unless I missed something [big] in my speedread.

redwolf3
07-20-2009, 09:04 AM
Actually, that was not the article. The article I was referring to can be found here:

http://www.circuitcellar.com/archives/viewable/224-Sander/5.html

It appears that part of the reason he could do what he did was the way the camera generated its signal, although the article seems to indicate that its just an NTSC signal output on a composite channel... but I don't personally have a lot of experience in this realm, so I can't say how much of his information is real, and how much of it is garbage science.

I was incorrect in the 50fps statement... it appears that he was referring to the amount of post-processing fps his computer system could handle with the filter he was applying.

As a note, I did take a look at the site he obtained his B&W camera from and it appears they have another similar camera which appears to have the same type of output, but is a color camera instead. Might be worth looking into (although I don't think this ultimately solves the bandwidth issue persay).

Anywho, as I say, this may not be useful or relevant, but thought I would share it anyways.

ScuD
07-20-2009, 11:01 AM
That article is actually just handling the first step - digitizing the analog video signal.

The problem we're facing is compressing the signal enough so we can limit the bandwidth needed to get the signal over the air, through zigbee, wifi, or other.

Interesting read though, I'll have to look into it a little deeper when I have some time.

Robot Dude
07-20-2009, 11:26 AM
Sorry guys. I'm not one to have the time to properly set up quotes and stuff. Sorry... I read where Adrenalyn suggested she was interested in taking the video from the builders...

> I'd like to take over the onboard bot video wireless networking. I've been thinking about the architecture and interference on 802.11* and have some suggestions there... ...Having multiple routers stacked on each other, we were probably jamming ourselves as much as anything...

So you all can get off my back for the bandwidth and server overhead stuff. If she said it was a good idea, well she should know...

I thought utilizing the audio portion of the camera was a brilliant idea. All in one robust reliable system. But to each his own I guess. I don't have near the free time to post here, so I can't really join in any conversations. Sorry for that as well.

We just received our TrendNet camera. I will be back to post video of the BRAT soon. Thanks for your time. Peace!

lnxfergy
07-20-2009, 11:55 AM
Sorry guys. I'm not one to have the time to properly set up quotes and stuff. Sorry... I read where Adrenalyn suggested she was interested in taking the video from the builders...

> I'd like to take over the onboard bot video wireless networking. I've been thinking about the architecture and interference on 802.11* and have some suggestions there... ...Having multiple routers stacked on each other, we were probably jamming ourselves as much as anything...

So you all can get off my back for the bandwidth and server overhead stuff. If she said it was a good idea, well she should know...

She's just talking about providing a router, with a slightly customized antenna setup. It's still just a IP-Cam>PC per each competitor, just both would be over the same router, really no different than the setup any of us ran, except with a better antenna configuration. It does not imply multiple PC connections to a single cam (or passing the video through a PC-based server), which integrated scoring over audio does.

Looking forward to seeing the BRAT with Trendnet.

-Fergs

robologist
07-20-2009, 12:24 PM
Ya know, the early Surveyor robot had a omnivision cam pumping video through or around an LPC2106 to an XBee module, through an OV529 chip (http://www.ovt.com/language/products/ip_detail.php?id=3) on some sort of board. Looks like it might have been a now unavailable development board. Not sure if this is any help.

Maybe it was just the ov7670 sensor (http://www.ovt.com/uploads/parts/OV7670_PB&#37;282.2%29_web.pdf), not quite so sure now.

Adrenalynn
07-20-2009, 12:32 PM
Yeah, that's not too far from what I'd like to build for the event. So who's gonna step up and fund it?

Robot Dude
07-20-2009, 12:39 PM
Yeah, that's not too far from what I'd like to build for the event. So who's gonna step up and fund it?

What's it gunna do (big picture scenario in laymans terms) and how much is it? Feel free to PM me.

redwolf3
07-20-2009, 11:30 PM
Is there a specific resolution requirement you guys are trying to meet with this solution? I mean, obviously the more resolution, the cleaner the picture, but is there some minimum resolution you are shooting for?

Adrenalynn
07-21-2009, 12:39 AM
I would think 320x240 would have to be the absolute minimum I could tolerate. And I'd be inclined to upscale that at the monitoring end.

@RobotDude

Before I run my mouth off that direction - I'm investigating modules right now to see what work's already done for us and what has to be done, which impacts R&D of course. I'll ping back on this shortly thanks!

lnxfergy
07-21-2009, 09:44 AM
Is there a specific resolution requirement you guys are trying to meet with this solution? I mean, obviously the more resolution, the cleaner the picture, but is there some minimum resolution you are shooting for?

Issy used 320x240, which I upscaled to about 800x600 on my screen.. It was drivable. When you are upclose and fighting, no problems, it's when you're further away. At several feet out, it's tough to tell "is that the other mech's front/back?"... and of course you'd want to run up from behind and get in a few shots... making a forward assault is a good way to lose HP of your own.

-Fergs

Robot Dude
08-06-2009, 10:35 AM
How to get 12 or more mechs competing next year...

Add a hexapod League! lol :D

Nice one Tyb!

http://forums.trossenrobotics.com/showthread.php?t=3465

Quintesson
09-16-2009, 02:31 AM
1st post. I've been following this thread since I read about it in either servo or robot magazine. Anyway I understand the spirit of the rules as far as having a 1st person camera POV. Just a thought but wouldn't it be easier to have an 5 camera setup. 1 overhead and 1 camera per corner with the feed going to a video pit for all the entrants. I know it would be 3rd person POV but its still within the spirit of the rules of not viewing the arena directly. Anybody that has already invested in a wifi camera setup could get 5 hit points rewarded for their efforts. I think just by alleviating that technical challenge you'll increase the number of entrants significantly.

Adrenalynn
09-16-2009, 02:53 AM
Welcome to the forum!

What I've observed in robotics competition is that they tend to get more difficult from year to year, not less. A handful of pioneers are proved that the competition ruleset is well within the realm of reality. The moment someone demonstrates that, expect the bar to be raised, not lowered.

That's my experience, anyway...

nagmier
09-16-2009, 10:54 AM
Another thing you are going to want to consider Quintesson is weight! 5 camera! Bipeds last year had trouble moving with just 1 camera and guns, sure if you are going the RX servo route you could afford the weight but then you get into the often used phrase "Get a walking, shooting mech going then think about how to make it better"

lnxfergy
09-16-2009, 11:14 AM
Another thing you are going to want to consider Quintesson is weight! 5 camera! Bipeds last year had trouble moving with just 1 camera and guns, sure if you are going the RX servo route you could afford the weight but then you get into the often used phrase "Get a walking, shooting mech going then think about how to make it better"

Nagmier, note that he wasnt talking about putting 5 cameras on a mech, he was discussing putting cameras in the arena so mechs wouldnt carry a camera...


1st post. I've been following this thread since I read about it in either servo or robot magazine. Anyway I understand the spirit of the rules as far as having a 1st person camera POV. Just a thought but wouldn't it be easier to have an 5 camera setup. 1 overhead and 1 camera per corner with the feed going to a video pit for all the entrants. I know it would be 3rd person POV but its still within the spirit of the rules of not viewing the arena directly. Anybody that has already invested in a wifi camera setup could get 5 hit points rewarded for their efforts. I think just by alleviating that technical challenge you'll increase the number of entrants significantly.

The spirit of the event was to create a real-life version of mechwars. Since we can't (yet) build affordable bipeds and quads that we can actually ride in, the 1st person POV camera 'simulates' such. I don't forsee us ever dropping the 1st person POV camera requirement. I think that the camera aspect is probably the least of the technical challeges -- adding a wireless camera really isn't that difficult, given the ability to carry the payload. Getting a stable, reliable walking robot, that can be controlled well, is the real technical challenge.

The new Hex-Mech division should lower the entry bar, but we can never completely eliminate the cost of entry -- and a competitive mech can still be built for far less than most of the competitive robo-one entries.

-Fergs

darkback2
09-16-2009, 11:15 AM
Welcome to the forum!

What I've observed in robotics competition is that they tend to get more difficult from year to year, not less. A handful of pioneers are proved that the competition ruleset is well within the realm of reality. The moment someone demonstrates that, expect the bar to be raised, not lowered.

That's my experience, anyway...

But the bar was already lowered. There were threads gallor a year ago about how hexapods would make the challenge too easy, yet we now have a hexapod class.

I think the problem with getting rid of the camera requirment is that it fundamentally changes the game in a way that hexapods does not. Driving a robot using a pre installed 3rd person camera system makes manouvering around the arena easier not to mention a different experience.

I think the first person POV cameras makes the game immersive both for the participants and spectators once we have a screen up where they can easily see it.

DB

Adrenalynn
09-16-2009, 11:28 AM
It's a different competition. If it was hex-vs-biped or hex-vs-quad, then yes - it would be lowering the bar. Making it hex-vs-hex creates a new contest rather than a lowering of the bar.

DresnerRobotics
09-16-2009, 11:31 AM
It's a different competition. If it was hex-vs-biped or hex-vs-quad, then yes - it would be lowering the bar. Making it hex-vs-hex creates a new contest rather than a lowering of the bar.

Exactly. And just to mix things up, we'll likely have an 'Open League' where you can choose to run a biped against a hexapod and see how you fair. It's all about having fun ;)

nagmier
09-16-2009, 03:14 PM
Ahhh I see where in my haste I missed that, mental note no posting during lunch... thnx for pointing that out

darrellt
09-16-2009, 08:15 PM
My team is attempting to use an android phone as the video camera/control system. You can check out Qik.com for proof it is possible to stream video from a phone. Qik has like 10 seconds of lag so we will have to write our own app, but its nice to know it will at least be possible.

Adrenalynn
09-16-2009, 08:52 PM
Sorry if I wasn't clear. I'm at least passingly familiar with cell phone video streaming [;) at those that know me well]. I was more looking for a demonstration of a full fledged autonomous mech ready to compete before I commited.

I think you'll find your cell cam has some additional lighting-vs-color challenges.

darrellt
09-16-2009, 10:25 PM
Adrenalynn-

I just wanted to share another possible video system for manual control. I do not have autonomous mech at this time. Qik is an android app I found while trying to determine the feasibility of cell phone is as a video source.

The advantages of the android phone over the wireless cam are that you get an accelerometer, compass, 500mhz arm, gps and built in battery all in one compact unit, and you may already have one in your pocket.

The disadvantages are, Poor iso performance of the CCD, compression artifacts, lag, risking the phone with every battle.

robokoi
09-18-2009, 10:24 AM
Before we get too far OT...

I'm not sure of the current setup, but another way to get more participation might be to get prizes donated? I caught the writeup in Robot Magazine (very cool, btw!) and a case of caffeine juice isn't much of a draw, at least for me. Maybe kits, discounts, gift certificates, or something?

Since I haven't been there, does RoboGames get sponsors only for the whole setup or can individual competitions do that?

DresnerRobotics
09-18-2009, 10:46 AM
Before we get too far OT...

I'm not sure of the current setup, but another way to get more participation might be to get prizes donated? I caught the writeup in Robot Magazine (very cool, btw!) and a case of caffeine juice isn't much of a draw, at least for me. Maybe kits, discounts, gift certificates, or something?

Since I haven't been there, does RoboGames get sponsors only for the whole setup or can individual competitions do that?

For year 1 competitors it wasn't about having some sort of prize to win. It's about the challenge of being there and competing for the first year in a competition with an extremely high entry bar. I didn't even end up competing, but simply seeing it happen was a massive reward for me. The case of energy drinks was just a joke.

We already have a few sponsors who have helped out in numerous ways, so to answer your question yes, competitions can also have sponsors. We'll look at possibly adding prizes for the next year, but it all depends on what we can get donated. Running this competition is a considerable cost, in both money and time, to myself and those helping me run it.

To be perfectly honest, I'd just as soon not attract the type of people who would only join this competition for the chance of winning a prize, I personally think it's much more about the challenge of building a working mech and the fun in competing.

darrellt
09-18-2009, 01:08 PM
To be perfectly honest, I'd just as soon not attract the type of people who would only join this competition for the chance of winning a prize, I personally think it's much more about the challenge of building a working mech and the fun in competing.

In any other robotics competition, getting a chance to remotely pilot a mech and battle it out with other mechs WOULD be an awesome prize!

Dont' get me wrong, robo-sumo and battle bots etc, are cool. But when I was a kid I did not dream about sumo and battlebots. I dreamt of mechs.

DresnerRobotics
09-18-2009, 01:15 PM
In any other robotics competition, getting a chance to remotely pilot a mech and battle it out with other mechs WOULD be an awesome prize!

Dont' get me wrong, robo-sumo and battle bots etc, are cool. But when I was a kid I did not dream about sumo and battlebots. I dreamt of mechs.

Exactly, and the excitement of mech combat + the engineering aspect is what I hope draws people to this competition. ;)

LinuxGuy
09-18-2009, 01:39 PM
If you are going to have prizes at all, make them small enough that somebody would not want to participate just for the prize. Perhaps have a nice trophy that is given to the winner, which would br held for a year or longer if a person keeps winning that particular event. A $100.00 - $350.00 gift certificate would be nice prize, with the amount being dependent on the event complexity/difficulty. Treat the trophies as championships that would be passed along to future winners, which would keep the cost of creating them down.

Another idea for possible reasonable prizes would be stuff like Trossen gives for it's contest winners in the $100.00 - $350.00 range. Higher value prizes for 1st place winners and going down from there.

Personally, I would like the idea of gift certificates as prizes because then a person could buy what ever they want/need for their projects. As for myself, I would not enter a contest that has a prize I do not actually want or would not use in a project, regardless of its value.

These prize ideas would be nice enough and would hopefully not bring in those who just want the prize. Otherwise, just go with nice trophies that would be worthy of being displayed by the winner(s).

8-Dale

Adrenalynn
09-18-2009, 01:50 PM
RoboGames medals were awarded.

DresnerRobotics
09-18-2009, 02:02 PM
Yeah Medals are handled by Robogames (they're nice too), but I just don't want the competition to be based around winning a prize. It might be nice in the future, but will never be a priority for me.

There are always going to be people who want a prize to enter in a competition, and then there are people who compete for the sake of the challenge. I'd just as soon only attract the latter crowd.

Adrenalynn
09-18-2009, 02:06 PM
I guess I'm old-fashioned. I always thought the prize was winning...

LinuxGuy
09-18-2009, 02:38 PM
There are always going to be people who want a prize to enter in a competition, and then there are people who compete for the sake of the challenge. I'd just as soon only attract the latter crowd.
I definitely agree. I would rather go for a good challenge than a prize, but a small prize is always nice to have too. :) Maybe sometime not to far away, I will have a robot that will be worthy of a competition. I don't think it will be WALTER, but could be ASTRID when she is complete. I'm not into the mech thing though, so no real interest there for me.

I definitely think competitions should be about the challenge, learning new things, and having fun. :D I'd be interested in competitions oriented towards rovers and hope to someday have a robot capable of competing in RoboMagellen or less complex events.

8-Dale

Adrenalynn
09-18-2009, 03:15 PM
I'm not into the mech thing though, so no real interest there for me.


It's probably best, in order to keep from skewing results, that we leave the input on Mech Warfare awards for Mech Warfare competitors, wouldn't you agree?

LinuxGuy
09-18-2009, 03:30 PM
It's probably best, in order to keep from skewing results, that we leave the input on Mech Warfare awards for Mech Warfare competitors, wouldn't you agree?
Actually, I don't agree here. I think the whole awards and prizes topic can be applied to any competition, whether for mechs, rovers, etc.

I've already started a fresh topic for rover competition ideas. :)

8-Dale

Adrenalynn
09-18-2009, 03:39 PM
Good. Then let's keep this on topic for Mech Warfare. Thanks!

mannyr7
09-18-2009, 08:39 PM
We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too. - John F. Kennedy, September 12, 1962

This is the spirit that drove me to compete in mech-warfare. And the fact that walking, shooting robots rock! No prize necessary.

robokoi
09-19-2009, 07:20 AM
For year 1 competitors it wasn't about having some sort of prize to win. It's about the challenge of being there and competing for the first year in a competition with an extremely high entry bar. I didn't even end up competing, but simply seeing it happen was a massive reward for me. The case of energy drinks was just a joke.

We already have a few sponsors who have helped out in numerous ways, so to answer your question yes, competitions can also have sponsors. We'll look at possibly adding prizes for the next year, but it all depends on what we can get donated. Running this competition is a considerable cost, in both money and time, to myself and those helping me run it.

To be perfectly honest, I'd just as soon not attract the type of people who would only join this competition for the chance of winning a prize, I personally think it's much more about the challenge of building a working mech and the fun in competing.

Don't get me wrong. I'm here for the challenge of designing and building something like this. Just figured I'd throw out the idea.
There's probably more to running this show than you're letting on, too, so huge thanks from all of us, even if we didn't make it year 1, getting to see it online was great! If there's things that need doing... post 'em so we can help.



I guess I'm old-fashioned. I always thought the prize was winning...

And winning is the ability to COMPETE in this game! ;)