.

BBRC

The remote control for your robot of destruction

This is the remote control application for controlling your BattleBrick remotely through the IR tower. The application is used for controlling any number of BattleBrick robots using gamepad controllers through a single IR tower.

Screenshot
Download:
Sourceforge page for BBRC

How to use BBRC
How to


Current Issues

Well, we've finally decided to do it. With a little work and a borrowed USB Tower from the RIS 2.0, BBRC now supports one (1) USB Tower as an output device. You MUST have installed the Tower drivers from Lego first however. It uses a device that is created when those drivers are installed, so without it, I'm not sure what will happen.

We may in the future (once we get a second tower) figure out how to enable all USB Towers that we find so that you can have as many towers as you want for your arena. Currently, though, we only support one tower. You'll see it in the drop down list for changing the comms port in the menu as USB1.

And in other news, BBRC now supports the Keyboard as one of it's input devices. We got tired of having to always use the gamepads, so I threw in keyboard support. There is a problem though. DirectInput doesn't allow you to grab exclusive access to the keyboard. What does this mean? It means that the other windows in the application also get the keystrokes. What does this mean? That if you press up or down or the Windows key, BBRC behaves strangely and sometimes clicks and beeps. Why you might ask? Because the underlying windows (the edit boxes, the list boxes) are also getting the keystroke and attempting to operate on it. What does this do? Not much. Just kinda upsets us. You'll have to play around in order to see if it upsets you too.

Another, older issue, is that releasing the com port (the little button on the top of the window) does not seem to work in Windows 2000. Again, I do not have Windows 2000, so I am unable to fix it. Microsoft must have decided to make a minor change to the API which blew up my code. *sigh* They really need to talk to me about these things.

Ramblings

Well, getting the keyboard and USB Tower support going is certainly a big step. However, to shoehorn it in to the current architecture was a mess (hence "shoehorn").
I've had to completely break the device input model in order to allow it to handle the larger amount of data needed by the keyboard. Internally, we only support gamepads with about 30 or so odd buttons. Most keyboards today have something like 102 keys. So, right there we're already broke. I've taken to just special casing stuff for the keyboard in the code in order to minimize the amount of OTHER code I had to change. This is Bad(TM).
Amazingly enough, the USB stuff was cake. It fit right into our current output model, I basically just added the option to the menu and that was that. This is Good(TM).
So, what does all this mean? It means that the app is just about ready for a good overhaul internally. Nothing that should be external visibly, but it will make the code much easier to maintain in the future.

So, that's why we're releasing 1.50 first as a beta. I haven't done much testing but I figure people will really want this stuff, so the sonner I get it into their hands the better. So, use it and take it out for a test drive, (at your own risk ) and hopefully within the next few weeks or so, we'll be able to put out a 1.50 stable for everyone to enjoy.

Quick FAQ

Some people have been interested in getting some more details about the capabilities of the BBRC.
Here's the answers to (hopefully) some of those...
  1. Does it only support gamepads, or will it support joysticks too?
    Well, in version 1.50 and later, BBRC now also supports the keyboard as an input device.
    Other than the keyboard, the application only supports gamepads. This is because it only enumerates gamepad-type devices when it checks for DirectInput devices. It could enumerate joysticks also, but the input model is only set up for digital devices right now. It would take a slight modification to get it to understand analog inputs. This is nothing major, however, so it could show up in a future release.

  2. Do the gamepads have to be USB or can they be attached to a game port?
    Gamepads attached to the joystick port should be enumerated. DirectInput makes no distinctions between the two.

  3. How many robots can a single PC control? Is the only limit the number of gamepads that can be attached?
    The number of robots that the application can control is a function of the message blocks that are assigned to each robot. Using the single byte message command provided by the RCX, this gives us 255 messages to send. So, theoretically, we could have 255 robots that each got one message. Currently, the system is set up for 16 robots where each robot gets 16 unique messages.
    Also, we're limited by the speed at which the IR tower can transmit. We're using the 2400 baud mode. Each message we send takes 9 bytes (yes, even for only a single byte, all of the set up and checksums come out to 9 bytes per message...) so, that gives us the capability to send roughly 33 messages per second. So, with message blocks of size 8, that should give you the capability to send a message per second to 32 robots. (Please, be aware that this is all theoretical. The most we've tried it with so far is 6 robots...)
    Finally, the current 1.3 revision of the code handles the gamepad message pretty inefficiently. It is possible to have one gamepad (with someone beating on it) to effectively cut everyone else off. Version 1.4 will change that to a round-robin scheduler with message queues so that everyone will get an equal share of the IR bandwith. (We hope...)

  4. Can you use more than one PC? Or do you have to use more than one?
    We have not tried using more than one PC. One has been fine for us. We have a 7 port USB hub and haven't had troubles yet. We have considered using two PCs linked over a network, such that one PC might have half of the gamepads and the other would have the other half. But, currently, we haven't created this yet. We thought it would be cool though to control your bot from a remote site though...

  5. How is the program on the RCX side different for each robot? Or is there any difference?
    The difference is in the messages each of the RCX programs responds to. The application will set up the gamepads to spew out a different bank of messages which will only be listened to by 1 unique robot. For example, if you have 4 gamepads, you can configure the app to assign messages 1-16 to gamepad 1, 17-32 to gamepad 2, 33-48 to gamepad 3, and 49-66 to gamepad 4. Now, this isn't enforced. Gamepad 1 could send messages 5,10,23,1,89, etc,etc, but the banks make it easier to sort out.
    Now, in the robots, there is a switch statement that listens for one of these banks. The bank the robot is listening for should be unique among all the robots. This is how you get the multiplexing. Every robot hears all of the messages, but just ignores the messages outside it's block. When a message that is intended for the robot is received, the commands in the switch case determine what the robot will do. This is entirely up to you.

  6. Is there any overlap between multiple RCXs or PCs? If six people show up with the same NQC program in their RCX, and the same control software on their PC, how can we tell them apart?
    Again, refer to 5. The differentiation will be the base address that the robots are each listening for. The example code listens for messages ranging from the base address to the base address + 16. You can set the base address in the NQC code. It is a constant defined at the top of the file.

    Hope this helps!

    Version Notes

    1.6
    1. Added the offset parameter to the device config dialog box and configuration files.
    1.51
    1. Fixed a bug that didn't let you load configuration files for gamepads
    1.50beta
    1. Added USB Tower support (for one tower)
    2. Added Keyboard input as a device (still a bit strange. May never be un-strange...oh well)
    3. Added a little Battlebricks button in the lower right hand corner. Should link you to our website ;)
    1.45
    1. Added "Load" and "Save" buttons to the main interface. This gives you easy access to loading and saving config files. Just highlight a gamepad and click "Load" or "Save"
    2. Added options for COM3 and COM4 in the Change COM port menu
    3. Internal restructuring of which class loads/saves config files
    1.43
    1. Added in a button to turn the COM resources BBRC grabs on or off. Helps when you have a program like RCXCC using the COM port at the same time. You don't have to shut down the BBRC in order to get RCXCC to work anymore.
    1.4
    1. New input model. Uses a round robin mechanism to poll the input devices rather than the previous one thread per controller. This decreases the amount of threads used (down to 2 from N where N=number of controllers) and should be more responsive. Previous versions suffered from controller starvation when the number of controllers got larger than 5 or so. Also, there is no message queueing as I hinted at before. The polling thread just sweeps each controller checking to see what states have changed. If you managed to hit and release a button faster than the polling interval, the message will not be caught. It polls every ten milliseconds or so plus whatever time it takes to transmit a message. A message takes about 30 milliseconds to send plus about 10 milliseconds of overhead time... So, the total time for a poll would be 10 ms + (40 ms*number of controllers). So, if you can hit buttons faster than this time, you might drop messages. I might see how making a message queue works, but I won't worry about this until people start reporting problems...
    2. New Make/Break codes. This allows you to send one message when a button is pressed and another when the button is released.
    3. New configuration file format. In order to facilitate the saving of Make/Break codes, there is an extra number in the lines of the config file. So rather than just <button #>,<message #> it's now <button #>, <make message #%gt;, <break message #>. Old files should load properly, they'll just have their break messages set to 0.
    1.3
    1. Changed the menus around - Added the RC and Info menus
    2. RC menu now has an option to change the COM port BBRC uses. It also saves this in the registry for later use.
    3. Internal changes to the way in which the input devices are polled (Took out a sleep to make it slightly more responsive, also changed the way in which the RCX communication object was created and used by the input threads)
    4. Changed the button mapping dialog. Edits now just require clicking on a message, changing the number, and clicking off. More intuitive than having to click the stupid "Change" button.
    5. Added a small help window. Nothing fancy, but then again, the program isn't that complicated...

    1.2
    1. Fixed the configuration file loading. Note that configuration files must also have "BBRC" as their first line. (Uses that as a sanity check so people don't try to load .EXE's or something)
    2. Main screen no longer shows the Load Config button - moved to Button Mapping
    3. Button Mapping supports saving config files
    4. Main screen now allows resizing. (And the lists stretch to fit)
    5. Removed most of the options in the file menu - They didn't do anything anyways.
    6. New About box ;)
    1.1 Internal - not released.
    1.0 Initial revision - Configuration files didn't work right and there was no way to see logged messaged that were too big for the log window.