look Ma, no OI

Just wanted to share with everyone a little preseaon activity. You’ll notice a radio on the RC side, but it is not being used for data transfer, only for the ESTOP. Hmmm…

Just to give you a quick idea of what you are looking at - two protoype legs of an 8 legged mecharachnid

Flyover link:

Walking link:

Just awesome.

that is impressive!

Are people just not dloading the *.avis? I expected a greater response from people when everyone noticed a wireless ethernet connection to the RC without an OI.

Should I post a pic instead. I figured people would like to see it ‘in motion’ instead of a still shot.

Those are huge files. Even with my cable connection it’s taking about 5 minutes to DL each file.
Maybe an accompanying screen shot would work for some.

That is absolutely incriediable!

How did you interface the wireless access point? is there a second processor to interface it? Are those linear actuators?


Holy smokeado!

If there’s a game that has some seriously harsh terrain, I know who I’m calling.

It looked like you were using a mass of hobby-class R/C car batteries to power the robot. How do they hold up? (I know those 3300 cells do well in R/C cars, but I think this wasn’t their intended use. :smiley: )

And, I guess the question on everyone’s minds…how did you interface Wifi with the RC?

<tangent>With 802.11x hardware being just this side of dirt cheap, could this be the next level of FIRST robot communication? I mean, the current IFI equipment is primo stuff, just limited by the number of channels in the 900 mhz spectrum. I’m sure there are plenty of pitfalls, but the ability to send all of this information this way could make it easier for FIRST to add more fields at the Championship, or–dare I say it lest Dave get ideas–more robots on the field.<tangent>

Did somebody say white paper? :smiley:

Ok - ya, this was a really fun project to do. I would love to divulge all the details, but unfortunately, I won’t be able to.

First I gotta say something about it ONLY taking 5 mins to download the accompanying movies. I realize this is the ‘now’ generation 'n all, but man I can remember connecting online with my 9600 modem and downloading Photoshop 2.somethingorother and it taking all night! Geeze…5 mins…

Aside from how this is actually done, the more interesting discussion is increasing teams at nationals. Obviously there is only some much bandwidth in the 900 Mhz spectrum for the radios, a reason FIRST uses for keeping nationals to smaller numbers (I don’t know the entire details on this matter, but that’s the gist of what I’ve heard). But if we were all using WIFI to talk to all of our robots…hmm…Could y’all imagine! All the differnent fields such as Currie or Newton having different subnets and everyone’s robot which all have IP addresses. Wow, we could have a lot of robots at nationals then. Just something to chew on.

So the 2004 FIRST controllers have a TTL port that you can access from userspace. With few little electronics to convert the TTL to RS232 (TTL = 0 to 5V) and standard RS232 (something like -10V and 10V, I forget at the moment and am to lazy to look it up) you get the signals in the proper levels for communication. Of course there is the driver that needs written since Innovation FIRST doesn’t directly support that port. But the PIC documentation has some useful tips and help. But it’s not too bad. After that is done, there is a neat little device on the market that takes Ethernet to RS232. And then there is a little handwaving on the Laptop side with vitural comm ports and such, but you can literally assign and IP address to the FIRST RC, and you have an alternative way of sending data to the RC. What is even better is the data is coming in the FAST LOOP! Previous you could only get data refreshed from the OI at the 26.2ms loop speed. So now you are only limited to how fast you can service the TTL port.
The other interesting fall out from this is you can essentially double the amount of IO on-board the robot. You could use the OI local to the robot. You can all think about that one for a minute or to. So, I hope you all enjoyed all this and would love to answer any other questions.


Great work there. What are the specs on those linear actuators? (length, speed, voltage, pushing power, cost, and where they were obtained) Thank you.

Those linear actuators have a stroke of about 7 inches, 500 lbs of push force, run at 28V, consume about 8 amps each (which don’t vary on load at all), and cost about $300 a piece. Interesting to note, the linear pots that sit on top of the actuators cost more money than the actuators did.

Oh right speed, uh…they did about 2 in/s, with the mechanical advantage we were running was plenty of degrees/s.

Cool, thanks for the quick response. That is a bit expensive though. I think I saw 3 actuators per leg? That would total about $7200.00 for an 8-legger. Also, where did you pick those up? Thank you.

As far as the batteries go, there are 120 1.2V NiMH 3.3Ahr stacked in such a way to provide 24V at 19.8Ahr. So if you figure our load is about 832 Amps, ~48As to do walking motion, it situates our NiMH cells at 48/19.8 C or 2.4 times their rate capacity, which they can handle just fine. NiMH are about the best battery as far as life, Power Density, surge, and cost.

Oh yeah, I can imagine…

I can imagine what it would be like for our drivers to move the controls, only to have the robot react 500ms later because someone thought it would be fun to stream a webcam from their robot over the wireless network control system, and it’s hogging all the bandwidth! :rolleyes:

Everyone always talks about how great wireless IP would be. Has anyone given that real thought? You’d need a continuous stream of data coming from and going to EACH OI. Since 802.11 is a shared medium, that means you will get collisions between packets. Guess what happens when there’s collisions? Each of the transmitters backs off and retries a random amount of time later. Do you want YOUR robot to be the one that chose to back off the maximum amount of time while your opponent’s robot backed off the minimum amount of time? I don’t.

Consider also that any person in the arena could have a laptop and now try to (intentionally or not) associate with the field’s wireless system. I know that FIRST is a generally trusting community, but the potential for easy abuse here would be large, and it would only take 1 person to decide that it would be fun to associate and flood-ping and watch the match stop to ruin it for everyone. And sure, you can encrypt, but now you have even MORE latency and more horsepower needed to decode.

Next consider that many venues are in college arenas, and most of them probably have wireless networks. Now you’ve got a potential problem of not being able to find a free WiFi channel… oops.

Anyway, I’ll say “no thanks” to WiFi control and instead hope that IFI keeps our current, dedicated-bandwidth-for-each-team system. If channels really are the problem, I’m sure IFI will find a great way to solve that as they do all the other problems they run into.

Where my mgmt would not probably want me to spell out costs, 300 bucks for that type of actuator is not bad at all, in fact, that’s dirt cheap.

Thanks for the insite into wifi. But as far as ‘sabatoge’ goes, heck anyone with a boradboand 900 Mhz vid transmitter could do the same thing now. I’m sure sometype of wifi could be made to work. What about that 802.16 comin out? WiMAX or something.

Just to clear up one misconception, the limit on the total number of teams at the Championship has to do with practical limiits of the facility, supporting logistics and staff to handle large numbers of teams while maintaining the Championship as a “quality event.” The use of the 900MHz radios is a determining factor on the number of robots active on the fields at any one time, but does not impact the total number of teams participating in the event.

That aside, this work is absolutely kick-butt! I got some insights into how the comm link is set up last week (via Rob Ambrose), and it is pretty impressive. The idea of making every robot/RC independently adressable via a unique IP location really opens up a lot of potential for completely new ideas for interacting with the robots, off-board co-processing, massive potential for autonomy support, all sorts of new game designs (imagine a 30 on 30 on 30 game!), real remote operations - imagine controlling the robot from another continent! - etc. Great work!


Does his enthusiasm for all those crazy crazy ideas scare anyone else?

Anyway, that looks nice, and about the CPU time/bandwidth/whatever. For one thing, FIRST already limits what we can send back as far as data goes, cameras too. The processing power to encrypt/decrypt WiFi could be handled by an external CPU managing communications too. About the packet collisions…hmm…no ideas there…anyone else?

Now that’s a quality post. Great wetware Dave!

dont you guys/gals at NASA already do that Dave?