More thoughts on scoring transponders

[jwatte]

I've poked around some more with the ESP-8266 WiFi/MCU parts. They're pretty great!

The Atmega and the Xbee from the current scoring board could be squished into a single part. That board would be cheaper and lighter. There are enough GPIOs on the ESP-8266-12 to support the current six IO/s (four detectors, one blinker, one pulse-out) and the serial port is available for talking to the on-board robot in a little more detail.

Also, the community packed up the available toolset in an Arduino form factor (with the 1.6 IDE, thank God) and it's really easy to build and flash now. (You'll need a switch to pull GPIO0 low while powering on / resetting the chip; that's it!)

The board could be hard-coded to connect to a network named "MechWarfare" with password "robotwars" and we could have a simple GUI configuration tool for setting things like transponder ID and whatnot. Perhaps those could also be overridden by the serial port if needed and desired. The boards would probably broadcast their status over UDP twice a second for any scoring system that wants to listen. They could also listen for broadcasts about match state (waiting / running / time left / ended) Using WiFi B on an intermediate channel (3, 4, 8, 9, or even 14) might be the best option for penetration in otherwise noisy RF environments.

And, here's where I'm getting a little crazy: it could be possible to use this board as the remote control, too. No, it can't do video, but it could use the existing WiFi B/G/N link to receive walk commands and send back telemetry. Add the Piezo-based scoring panels, and we have a seemingly simple, affordable, and robust system for the next five years or so.

[byi]

Cool. My one question is why do we want to switch to wifi? Wasn't wifi infrastructure a major issue at previous events? Of course the bandwidth would be lower than when we used it for cameras, but I don't see a clear advantage.

[jwatte]

Cool. My one question is why do we want to switch to wifi? Wasn't wifi infrastructure a major issue at previous events? Of course the bandwidth would be lower than when we used it for cameras, but I don't see a clear advantage.

At RoboGames, WiFi was a problem, yes, although mainly for the cameras that have high throughput and use TCP.
I ran some experiments with UDP at that event and it worked "better" (10% packet loss or so.)

The first reason I want to switch here is siginficant cost savings. One of these chips is $3, as opposed to the $20+ for the Xbee.
There's also a bit of weight savings and simplicity improvements, which are additionally nice.

[jwatte]

Once I got the ESP8266 working with custom firmware, they are night and day compared to the Xbees. The Xbees just won't do low-latency bidirectional communications. Single direction, like used by the Arbotix Commander, works fine, but I want to know what my battery and servos are doing...

Here's the status panel I built, with voltage/temperature/alert status of each of the 12 walking servos:



Kind of blurry because it was late at night :-) Walking around and waking up the little dog (she's such a scaredycat!)

Now to drop the same thing into the Phantom quad, and I can have my own little family match in the garage :-)

[ArduTank]

Nice. Details??? (hardware in bot and controller, etc.)

[DresnerRobotics]

Once I got the ESP8266 working with custom firmware, they are night and day compared to the Xbees. The Xbees just won't do low-latency bidirectional communications. Single direction, like used by the Arbotix Commander, works fine, but I want to know what my battery and servos are doing...

Here's the status panel I built, with voltage/temperature/alert status of each of the 12 walking servos:



Kind of blurry because it was late at night :-) Walking around and waking up the little dog (she's such a scaredycat!)

Now to drop the same thing into the Phantom quad, and I can have my own little family match in the garage :-)

I just had to drop in and say this looks GORGEOUS.

Seriously well done.

[jwatte]

Ha ha, thanks :-) Given that you did the carbon fiber thing with your portable remote, I had to go a bit more old skool.
It's a single (very wide!) plank of walnut, plus some time on the ShopBot, plus a lot of shellac...

The robot is Onyx 7 -- OpenCM 9.04, 14x MX_64T, dual airsoft AEGs with Onyx Fire dynamixel-protocol fire controllers.
The controller is one 5 GHz receiver with a 7" Adafruit TV display, and one Raspberry Pi with a 10" HDMI panel and some custom software.
Also, I plug in an Xbox 360 controller.
A LiPo goes inside the case for power and it does WiFi when not plugged in, so it doesn't need the cabling you see in the picture.

Baptism by fire: Boston end of May!

[ArduTank]

This solution have the bandwidth to handle both FPV and control at the same time?? If so, what does it take to set this up. I'm all for cheaper simpler solutions.

[jwatte]

No, the video is 5.8 GHz FPV analog. The solution does bidirectional control.

I actually considered doing everything in one, by using a Raspberry Pi with its built-in camera, and WiFi-N 5.8 GHz. However, that's a few too many eggs in a single basket for now :-)

It's still cheaper than the Xbee based transponders, and cheaper and higher bandwidth (and more bidirectional) than Xbee based control.

[ArduTank]

So similar to what I'm doing. Lol. I take it the RPi is hooked to the ESP8266 on the controller side?? This setup able to be moved to a larger PC (laptop), or is it dependent on resources only the RPi has??