From Murray Wiki
Jump to navigationJump to search






MVWTfest January 2007

The Caltech Multi-Vehicle Wireless Testbed (MVWT) is a testbed for networked control, computing and communications systems. It consists of up to 12 mobile vehicles with embedded computing and communications capability for use in testing new approaches for command and control across dynamic networks. The system allows testing of a variety of communications-related technologies, including distributed command and control algorithms, dynamically reconfigurable network topologies, source coding for real-time transmission of data in lossy environments, and multi-network communications. A unique feature of the testbed is the use of vehicles that have second order dynamics, requiring real-time feedback algorithms to stabilize the system while performing cooperative tasks.

The MVWT is part of the the Caltech Vehicles Laboratory and consists of individual vehicles with PC-based computation and controls, and multiple communications devices (802.11 wireless ethernet, and Bluetooth). Several different types of vehicles have been developed, including wheeled mobile robots, a thrust vectored vehicle on castors and a hovercraft. The laboratory contains access points for the 802.11, overhead visual sensing (to allow emulation of GPS signal processing), a centralized computer for emulating certain distributed computations, and network gateways to control and manipulate communications traffic.


Project Report MVWT2008

All changes made and also previous documentation can be found in the 2008 project report (12/19/08 - Zgraggen):

From Previous Projects

Wireless Router:

  • We have been having some problems with the wireless router not working at random. We have replaced the old one with a new one in Nov. 2006 but the new one appears to be showing some of the same symptoms. Here are the settings on the router after a hard reset: 1. under wireless...basic wireless settings, set the network name to be caltechmvwt so the vehicles can find the router (they are set to connect to this router name by default). 2. under wireless...wireless MAC filter, set it to Permit Only pc's listed to access wireless network. Then you have to enter the MAC addresses of the wireless cards you want it to access. This security is a good idea so that other people can't connect to the computers on the wireless network. Some of the robots have no passwords on them for ease of use, so they could get hacked into. You can turn off the MAC filter briefly for debugging, but please turn it back on asap. 3. Under Administration...Management, set the router's password to be the standard for the lab.
  • update 3.21.07 it looks like the wireless router's problem may have been caused by electrical problems from a suspect docking station sawyer bought on ebay. The docking station, which was also having other problems, was electrically connected to the router by ethernet and could have been transmitting transients, etc.

Vision Computer:

  • Password for the computer is lab standard password. Run vision_static.exe on the desktop to broadcast vision packets.
  • The power supply for the cameras, plugged into the ceiling, failed around Nov. 2006. Symptoms at first were error message, "imSyncHost no response: 'other' error." and then occasionally a few picture frames would show up. Turns out that error message really means: "Oh, the cameras might be turned off." Suggestion to Matrox: maybe this isn't such an uncommon error, and you could actually check to see if the cameras were off, so we don't spend weeks banging our heads on the wall about it? Thanks!
  • A few extra vision boards were bought from ebay in case that was the problem and they are in one of the drawers near the vision computer. There is also a backup motherboard.
  • Occasionally, the computer freezes during vision. You just have to reset it.
  • During debugging of the above problem, we found that: the diagnostics software finds lots of errors which confused us greatly during debugging, but turned out to have no bearing on the "imsync" error we were seeing. It seems to work fine in spite of the error diagnostics messages we were getting.
  • (26/10/08 Pleines) The vision software is running and detects all head that are around in the lab. However, the packets broadcasted seem to contain no useful data.

Other hardware:



We have written several papers that describ the MVWT and provide additional information on how it is configured.

MVWT I (Kelly robots):

  • A Platform for Cooperative and Coordinated Control of Multiple Vehicles: The Caltech Multi-Vehicle Wireless Testbed, Timothy Chung, Lars Cremean, William B. Dunbar, Zhipu Jin, Eric Klavins, David Moore, Abhishek Tiwari, Dave van Gogh, Stephen Waydo.Conference on Cooperative Control and Optimization, 2002.
  • The Caltech Multi-Vehicle Wireless Testbed, Lars Cremean, William Dunbar, David van Gogh, Jason Hickey, Eric Klavins, Jason Meltzer, Richard M. Murray. Conference on Decision and Control (CDC), 2002.

MVWT II (Hovercraft):

In addition, several papers have been written using the MVWT to collect data and test out new approaches to communications, computing and control:

  • Position Tracking for a Nonlinear Underactuated Hovercraft: Controller Design and Experimental Results, Antonio Pedro Aguiar, Lars Cremean, Joao Pedro Hespanha. Conference on Decision and Control, 2003



Here are some pictures of the testbed and the different vehicles. Click on the thumbnails to get a larger version.

Vectored thrust vehicle (Kelly)
Hovercraft vehicle
Wheeled vehicle (Steelebot)
Schematic view of the testbed
Picture of the testbed with two vehicles
Formation control with three vehicles