|
|
 |
Remote Control
|
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.
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...
- 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.
- 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.
- 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...)
- 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...
- 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.
- 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.51 |
- Fixed a bug that didn't let you load configuration files for gamepads
|
| 1.50beta |
- Added USB Tower support (for one tower)
- Added Keyboard input as a device (still a bit strange. May never be
un-strange...oh well)
- Added a little Battlebricks button in the lower right hand corner.
Should link you to our website ;)
|
| 1.45 |
- 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"
- Added options for COM3 and COM4 in the Change COM port menu
- Internal restructuring of which class loads/saves config files
|
| 1.43 |
- 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 |
- 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...
- New Make/Break codes. This allows you to send one message when a button is pressed and another when the
button is released.
- 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 |
- Changed the menus around - Added the RC and Info menus
- RC menu now has an option to change the COM port BBRC uses. It also saves this in the
registry for later use.
- 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)
- 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.
- Added a small help window. Nothing fancy, but then again, the program isn't
that complicated...
|
| 1.2 |
- 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)
- Main screen no longer shows the Load Config button - moved to Button Mapping
- Button Mapping supports saving config files
- Main screen now allows resizing. (And the lists stretch to fit)
- Removed most of the options in the file menu - They didn't do anything anyways.
- 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. |
|
|
|
|
|
