Anyone know what’s the best way (and best buy) to make a BRAT biped wireless, meaning no DB9 cable? oh and should the batteries that are on the website work without no flaws? i have a concern about getting enough current out of those puppies (to servos)
Hey Titan,
The batteries sold here will work perfectly with the BRAT. Check out the BRAT page for recommended battery packs.
The cheapest, easiest, way to make a BRAT wireless is to have it controlled via a SSC32 and attack a BlueSMiRF bluetooth to it. That will cost you around $50-60 + $10-30 for a usb bluetooth adapter.
You can also do wireless via WiFi with a WiPort but that will cost you around $100-150, but you will have better range. If you don’t plan on having your bot go far from your computer then Bluetooth is a very good option for you.
-robodude666
Yea, I was doing some ‘research’ on the wiport option, though it seems that i need a board that will need to hook up to the ssc32. Is this board available anywhere?
I think the guy who was making the boards stopped making them, or stopped offering the really good version. You can search the forums for more details. I don’t remember much on it.
There is a PCB design call MatchBoard on the forum for a breakout board for the lower cost Lantronix MatchPort module. That gets you the WLAN range for about 1/2 the cost of the full blown WiPort module, albiet only 1 com port and at 230kbps. The .zip file has the gerber files to send to BatchPCB and a BOM to buy from Digi-key/Mouser. I have this with an SSC-32 on my scout.
The bluetooth option is the least expensive, this is about $35USD more and has the full 100/300m range of a regular WLAN connection.
edit:
thread here lynxmotion.net/phpbb/viewtopic.php?t=2103
.zip file here lynxmotion.com/images/files/MatchBrd.zip
I’ve heard rumors that a BRAT configuration works fairly well with a BlueSMiRF Bluetooth module from SparkFun electronics. 
seamus,
What battery is that in the photo? it looks like a perfect fit for the BRAT. What kind of run time do you get from it?
Well since we are talking rumors, I hear the MatchBoard works pretty well on the Scout as well as a BRAT 8)
http://users.adelphia.net/~eballou/scout/Picture%20415.jpg
http://users.adelphia.net/~eballou/scout/Picture%20414.jpg
The battery is a random “mini R/C car battery” that I picked up from the hobby shop. I think they use them in the 1:20 scale trucks, or something like that. The cells are “2/3-AA” sized NiMH cells with an “Intellect” label, ostensibly labeled as having a 1400 mAH capacity. They’re the same diameter as standard AA-sized cells, but 2/3 of the length. They have the same fit in the channel as other AA-cell packs - about 1/8" gap, easily filled by “squidgy” non-slip padding, which also protects the pack’s shrink wrap from the screw heads. I had to lop off the connector and replace it with one of the right type for my wiring harness, but that was just as easy as it sounds.
Using six HS-5645MG servos, it has no problem moving everything around for a good long while. I don’t know what the total run time is because my testing and programming sessions tend to be somewhat short, and I’ve never actually run an entire charge, from beginning to end, in a single sitting. It seems to be plenty long, though.
do you think it’s possible to also send sensor data with either the MatchBoard or BlueSmirf in some way (I’d love to control my BRAT through MSRS…)? Would you need a bot board or is there a better way to do that? Could the SSC-32 get sensor data in some way? guess not, but…
There are a five GPIO pins (I think it is 5) on the MatchPort that can be accessed via a UDP port connection but you would need a plugin or something to bridge the gap between that network connection and whatever it is the MSRS is expecting to see. Is there an MSRS SDK or does MSRS give you a code template that you can use with visual c++ or c# to make a custom .dll or .ocx or something?
Well, basically, you have to write a ‘service’ (the name for any kind of application, or appropriated hardware in MSRS), written in any .NET language (usually C#.NET), that communicates with the robot in any way (it would be SerialPort for the blueSmirf, and I guess also for MatchBoard?) so that you have this service which sends requests to the hardware or sends notifications to subscribers (all that is done asynchronously). Then you can add generic contracts to control the sensors using the appropriate generic service (ie a service that lets you use the same code for any kind of hardware, eg. the drive service, bumper, webcam etc).
But how could the Matchboard’s Wireless device send data coming from both the SSC-32 and those pins?
You would just use the same SSC-32 service and point it at the virtual COM port instead of the hardware one. The serial data comes in via a virtual serial port and from the application standpoint it has no idea the SSC-32 is communication via wireless connection.
The MatchPort GPIO pins would have to be a different service, having nothing to do with the SSC-32 at all, that just happens to be using another set of ports on the MatchPort. The ‘service’ application would need to find and make the UDP connection to the MatchPort over the WLAN, and then present the service end to MSRS. My MatchPort is setup using static IP addresses so there is no “find” part required, and it just connects to my WLAN AP/Router and I can hit it from any PC on my home network. I would think you could make a configuration dialog for your service to allow you to do the same.
A thought… if you had access to the ssc-32 service source code then you could extend it to be some sort of hybrid (ssc-32_via_matchport) and include the GPIO access as part of it. Then you would have the five configurable digital I/O pins on the MatchPort and the four A/D channels on the SSC-32 all in the same module.
But how could the GPIO pins data be sent on the serial port if the matchboard is already sending SSC-32 data? How could the PC understand which data is coming from where?
Anyway, yes I would probably use the existing SSC-32 service (BTW the source code for every service is available I think, and I already had a look at the SSC-32 code) and add the GPIO pins-related stuff.
the MatchPort is a wireless network enabled device server. The serial port is just a device it supports. The virtual com port driver on the PC that talks to the MatchPort is just using a TCP service that on the MatchPort end is connected to its serial port. The GPIO pins also have a service running on the MatchPort to allow an application to make a network connection and access them. Unfortunately there is no “standard” device to virtualize like a com port or lpt port so there is no virtual driver that you can just load and use standard windows functions to access. You would need to write an application capable of connecting to the network service/port, it’s a UDP port if I remember correctly, on the MatchPort. Like you would use a telnet program to access a telnet service on a server, or an ftp client to access an ftp service. There just isn’t, or maybe there is and I just don’t know about it, just a canned application sitting there to access the GPIO pin service running on the MatchPort. Even if there were you would still need to write the code to work with MSRS.
Greetings, you was right. I get and set configuration of these matchport pins through a tcp/ip connection using port 77F0H. I did it using a great program like the Advanced Serial Port Terminal, just for be sure it works on this wifi chip. Now, the challenge is programming one to do this at my requirement…
Ill keep all of you informated…
Best regards