Collaborative Robotics
Low Level Collaborative Robot Construction
The design of a team of collaborative robots requires detailed attention on both the high and low level elements of the design, although it is more often the high level design which is most studied as that deals most openly with research questions, in particular the method of collaboration between robots. However, without low level support for this type of collaboration, any robots constructed would ultimately fail to meet criteria which may later prove to be essential.
The majority of this document discusses the design choices made, and the reasoning behind them, in the low level construction of a scaled robotic monster truck which is to be built as part of a team of collaborative robots. This team, although initially developed on the scale models of a monster truck will also ultimately be used on holonomic wheeled vehicles and walking robots in the same format. Furthermore, due to the expectations that collaborating robots may collaborate with robots of varying physical size, the possibility of implementation on board smaller robots has also been taken into account.
Given these constraints, added to plans to allow the collaborating robots access to one another's sensors and even in some cases actuators, the robots were designed with a modular control system. The system allocated a single PIC16F628 microcontroller chip to separate sensors and actuators but stopped short of separating every individual sensor or actuator to avoid efficiency problems later, even though this may be less pleasing in the abstract design sense. As a result, sensors such as ultrasonics, which are likely to exist on board a robot in multiples, were allocated to a chip in groups of four. Similarly, the motor control system was implemented on a single chip, despite the separation of steering and drive control on this vehicle.
With this modular design of components in place, naturally, it is essential that individual components can collaborate within the robot to enable its successful operation. This required a communications protocol, which needed to not only efficiently pass on information, but also cope reliably with the environment which a mobile robot would expect to find itself in. Furthermore, due to the modular construction of the robot, it would be significantly more convenient if components could be added and removed in a "plug and play" fashion, avoiding any need for reprogramming of connected devices or even the high level controller (an PDA on board the robot in this case) on addition of a new device.
The on board network between the chips was constructed in a ring formation, with each message passing through each chip then back onto the wire (fig 1). With every message passing through every chip, it became possible to ensure that every device had been discovered at the start of operation, therefore allowing for automatic detection of components at power up.
Simultaneously, the ring construction also provided a degree of redundancy, with two wires connecting every chip, rather than the single wire with the more traditional bus. Initially, we intended to make sure that should a wire become broken, or a chip damaged, the remainder of the system would take note of an unusual length of time between messages and, using two transistors to form a bypass (fig 2), switch the system into simple bus mode. At this stage the high level controller would be notified so that a message could be given to the operator of the need for repair, although the system would continue to function adequately, and in fact when a chip was missing from the circuit this proved to continue to function successfully.
However, this plan was later dropped in favour of a more traditional ring redundancy mode, where the transistors could be used to connect a second spare wire on the ring and allow traffic to if necessary travel in both directions to avoid a faulty chip or wire (fig 3). This decision was made largely because of the huge programming overhead required to enable the previous model as the PIC chips have limited memory space.
To facilitate the implementation of this system, a PCB (printed circuit board) was designed to be suitable for every sensor and actuator in the system. This board, intended for components which required parallel I/O with the chip, included input and output leads for power and communications and also separated every I/O pin for easy access (Figure 4).
Because of the nature of the serial communications required by both the GPS and the PDA itself (and potentially other future devices) which could not be integrated into the overall circuit, there initially some dilemma over the use of a second board to provide parallel communications between two chips which could then each carry out serial communications with separate devices. However, ultimately, with the PDA set up to transmit and receive at the same baud rate as the ring, the PDA could then be added to the ring with little extra cost to its function - given that it is likely be the instigator or the destination of the majority of the traffic on the ring in the first place. A second, simpler, PCB was made to enable the PDA to interface with the main ring directly.
Several alternative solutions were considered for the GPS module, including implementing a second serial device on board the PIC manually, as PIC chips with two serial ports were too large for our needs. However, this proved impractical, so we chose instead to piggy back the GPS PIC chip onto the main ring PIC chip, forming a simple bus between the two using PORTA (fig 5).
Taking a hardware standpoint for a moment, the PCB, combined with the carefully designed wiring of the ring itself and power circuits, are intended to make construction of further robots as quick and easy as possible, with the addition of new devices as simple as adding a cable and a duplicate PCB.
At this stage it becomes necessary to consider the design of the robot from a software rather than hardware standpoint. Once again, it is not the details of individual sensors and actuators but their combination which provides the real design issues.
Given the described hardware setup, the successful design and implementation of a networking protocol becomes crucial to operation of the entire robot. The protocol developed for this application, to be used both on the ring, features an unusually large header to message size ratio, but makes use of this header by including detailed checksums. This was deemed to be appropriate as the accuracy of any given message in this system would be more critical than reaching any given sensor or actuator a few nanoseconds faster in a system which naturally operates at a maximum frequency of approximately 2Hz. The networking protocol (Table 1) features a header only checksum, limiting the forwarding calculations required of each individual chip, plus two message checksums and a TTL (time to live) value which is decremented at each chip. This combination of protection methods will eliminate both dead messages continuing to take up network bandwidth and the possibility of receiving a garbled message and therefore taking the wrong action.
Table showing protocol
In order to maintain the "plug and play" aspects of the system, there was also a requirement for the system to be capable of setting itself up from power up. This initialisation is instigated by the PDA as might be anticipated. The PDA sends a message out to a destination address of 0x00 (power up default for all chips) telling them to set their address to the value in the message field and then pass on the message incremented by 1. The PDA's own address is always set to 0x01. The value of the highest addressed chip in the system is then passed on to the PDA. Given this information, the PDA can then contact each chip in turn requesting an ID byte. The ID byte will then be used by the PDA to look up details of the commands and responses expected from the sensor or actuator and their capabilities on a web service which operates at a known URL. Thus initialisation of the system is performed with the minimum of prior knowledge on the part of any of the components.
The design of this robot control system is such that it can easily be put into place on board any mobile robot with the weight capacity to support it, a relatively low minimum requirement once the ability to communicate remotely with the PDA is enabled. With this simple form of standardisation, it is not only faster and easier to build and control a mobile robot, it will also be much easier to enable the robots to interact and collaborate with one another. This will allow the robots to digest sensor information from other robots, and even in special circumstances to control the actuators of another robot in order to complete a wider task as a team and may be more common when larger robots are working with smaller ones.
