PRIORITY APPLICATION

[0001] The present application for patent claims priority from Australian Provisional Patent Application No. 2022903124 entitled “Agent Communication System and Method”, filed 21 October 2022, which is hereby expressly incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] The present disclosure relates to a system and method for communicating information amongst a group of agents. In a typical application, a base station communicates with a group of robot agents via a communication network to control or coordinate a task in an environment which degrades, disrupts or denies access to data communication.

BACKGROUND

[0003] Teams of autonomous robots, such as heterogeneous teams, offer unique capabilities to problems associated with exploring unknown, dangerous environments with limited communications infrastructure, as can occur in subterranean environments or disaster scenarios.

[0004] By way of example, subterranean environments present significant challenges for effective wireless communication with robots via wireless electromagnetic signals since they do not provide predictable free-space losses. Instead, wireless communication signals for robot communication in subterranean environments (such as tunnels, caves or mines) can be degraded or attenuated by reflection, absorption, shadowing and fast fading (abrupt spatial/temporal fluctuation) due to having low antennaes in confined spaces on mobile platforms. Furthermore, in certain subterranean environments cut-off and ducting effects can lead to further constraints on wireless communication signals. Cut-off effects in tunnels, for example, require that a wireless communication signal be maintained above a certain frequency (~10s of MHz), whilst ducting effects increases the risk of interference between radios beyond their effective communication distance.

[0005] In circumstances requiring wireless coordination of teams of autonomous robots in subterranean environments, difficulties with wireless communication signalling lead to single robots and even small groups of robots being isolated, in a communication sense, from an operator of a base station for extended periods, thus preventing or disrupting coordination of the isolated robots via a base station. These difficulties can thus present an obstacle to the communication of mission-critical data (collected by the robots) back to an operator base station under harsh network conditions and time constraints.

[0006] It would be desirable to provide a disruption-tolerant communications system which enables effective communication with robots in environments where wireless communication can be disrupted by environmental and or other effects.

SUMMARY

[0007] The following presents a simplified summary of one or more aspects of the present disclosure, in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.

[0008] Aspects of embodiments of the present disclosure relate to communication systems and methods which allow sharing of information between plural robot agents.

[0009] In a first aspect, a method of sharing information between plural agents is disclosed, the method comprising: an agent broadcasting message data into a shared communication network including one or more other agents; at least one agent of the one or more other agents receiving the broadcast message data over the shared communication network; the at least one receiving agent determining that the broadcast message data relates to new and/or updated data for storage in a local database of the at least one receiving agent; and the at least one receiving agent communicating a request to the broadcasting agent to communicate at least some of the new and/or updated data to the at least one receiving agent to update the at least one receiving agent's local database.

[0010] In certain embodiments, each agent is a robot agent incorporating an associated ROS master. In an example, the sharing of information between the plural robot agents includes at least one of the robot operating system (ROS) masters managing the bridging of ROS topics between the plural robot agents. ROS topics may be implemented as incremental streams of information or published as state messages that invalidate older ones.

[0011] In certain embodiments, communication of message data between the agents occurs on a hop-by-hop basis to disseminate the message data across the plural agents in data communication via shared network resources of the shared communication network without requiring end-to-end connectivity. However, it is also possible that embodiments may support end-to-end connectivity.

[0012] An advantage of certain embodiments of the present disclosure is that they may enable the coordination of robotic exploration in difficult three-dimensional environments with degraded communication. In embodiments, socket-options and application-level heartbeats may be used to maintain TCP communication responsiveness even in unreliable network conditions.

[0013] Before continuing further, throughout this specification reference will be made to the term “agent”. Where used throughout this specification, references to “agent” are to be understood to denote a robotic vehicle having an associated independent robot operating system. Non-limiting examples of agents include unmanned ground vehicles (UGVs), such as tracked UAVs, unmanned aerial vehicles (UAV), such as quadcopter type UAVs or the like. In embodiments, an agent may be fully or partially autonomous. For example, in some embodiments a human operator may guide a team of agents, such as a heterogeneous team of robot agents, using commands communicated from a base station. In other embodiments, agents can be commanded or operated using, for example, single agent teleoperation or consensus-based Multi-Robot Task Allocation (MRTA) approach which can coordinate exploration between agents with no input from the operator.

[0014] In one aspect of an embodiment of the present disclosure, the local database of each agent stores message data from persistent ROS topics. Each agent may periodically assemble a data set describing information stored in its respective database for data communication by way of broadcasting to the receiving other agents via the shared communication network. In certain embodiments, the data set assembled by each agent is assembled as a log data (eg. metadata) describing a group log stored in the local database and thus available for synchronisation with the local database of other agents of the plural robot agents.

[0015] In certain embodiments, each assembled data set “summarises” the respective local database contents per-log, wherein a “log” is an append-only data-structure consisting of serialized ROS messages from a specific set of topics originating from a specific agent. It is possible that each data set has a size which is suitable for communication over wireless UDP multicast, even in in circumstances where there are a large number a ROS messages associated with an individual log. [0016] In certain embodiments, the assembled data set comprises an un ordered list of entries. Each entry may represent metadata about a “log”. In certain embodiments, an entry includes an agent “ID” that uniquely identifies the originating agent amongst a peer-to-peer swarm of agents, a log “name” that uniquely identifies the log amongst all other logs originating on that agent, and a numeric “tail” value that represents the index relative to the beginning of the log of the latest message stored in the respective database.

[0017] In certain embodiments, the shared communication network comprises a peer-to-peer, disruption-tolerant communication model which operates on top of a TCP/IP network stack.

[0018] In certain embodiments, multicast UDP is used for "beacon" communication for peer discovery and unicast TCP is used for transport of ROS message data. In embodiments employing both multicast UDP and unicast TCP, agents may dynamically discover one another on the network via UDP multicast and establish peer-to-peer (P2P) connections via TCP unicast. Message data associated with ROS topics configured for bridging may then be multiplexed onto P2P connections according to quality-of-service (QoS) options and link quality metrics provided by a local node. Peer agents may then use this information to request the transfer of certain message data in order to complete synchronisation. For example, if an agent receives a broadcast indicating newer group log data than that contained in the receiving robot agent’s local database, the receiving robot agent will initiate a data transfer of data from the agent broadcasting the newer log data until the local database of the receiving agent is synchronised with that of the broadcasting agent. An advantage of this approach is that it may allow for robust communication of message data in the face of unreliable network conditions and allows for inter-agent data-sharing without requiring end-to-end paths.

[0019] In embodiments, an agent can bridge a particular topic with either a ‘volatile’ or ‘persistent’ QoS. In this respect, ‘volatile’ QoS involves direct, best-effort transport (useful for latency-sensitive data, e.g. robot status, camera feeds) whereas ‘persistent’ QoS involves indirect, fully-reliable transport (useful for mission-critical data, e.g. multi-agent Simultaneous Localisation and Mapping SLAM inputs, artifact detections).

[0020] In certain embodiments, volatile QoS is implemented by transporting individually- compressed ROS message data directly to destination peer agents. In such embodiments a user may specify a mapping from ROS topics to "volatile groups", each of which uses its own queue/connection. An advantage of this approach is that it may reduce transport overhead and tailor buffering behaviour for individual groups. [0021] In certain embodiments, persistent QoS is implemented by storing ROS message data in the local database of each agent and synchronising this database with one or more other agents of the plural agents. In such embodiments, a user may specify a mapping from ROS topics to "persistent groups", each of which may form an append-only log in the database using a key. In embodiments, the key may be based on the ROS topic name and/or a UUID of an agent having the local database in which the messages were originally published. It is possible that a group may be configured to use one of plural storage policies.

[0022] In certain embodiments, the shared communication network is a wireless mesh ad-hoc network.

[0023] Another aspect of an embodiment of the disclosure provides an agent comprising: a processing system comprising one or more processors; a transceiver for data communication with a shared communication network; a memory; a set of program instructions stored on the memory; wherein the set of programmable instructions are executable by the processing system to: process message data received by the transceiver to determine whether the message data relates to new and/or updated data for storage in a local database of the agent; and cause the transceiver to transmit a request for at least some of the new and/or updated data to be communicated to the agent for updating the localdatabase.

[0024] Still another aspect of an embodiment of the disclosure provides a system for sharing information between plural agents, the system comprising: a shared communication network; at least one agent of the plural agents configured to broadcast message data into the shared communication network; at least one agent of the one or more other agents configured to receive the broadcast message data over the shared communication network, wherein the at least one receiving agent is further configured to: determine whether the broadcast message data relates to new and/or updated data for storage in a local database of the at least one receiving agent; and communicate a request to the broadcasting agent to communicate at least some of the new and/or updated data to the at least one receiving agent for updating the at least one receiving agent's local database.

[0025] These and other aspects of the invention will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and embodiments of the present invention will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary embodiments of the present invention in conjunction with the accompanying figures. While features of the present invention may be discussed relative to certain embodiments and figures below, all embodiments of the present invention can include one or more of the advantageous features discussed herein. In other words, while one or more embodiments may be discussed as having certain advantageous features, one or more of such features may also be used in accordance with the various embodiments of the invention discussed herein. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods.

BRIEF DESCRIPTION OF DRAWINGS

[0026] Embodiments of the present disclosure will be discussed with reference to the accompanying drawings wherein:

[0027] Figure 1 is a block diagram of a system according to an embodiment of the disclosure;

[0028] Figure 2 is signal flow diagram depicting an example of communication signal flow between agents of an embodiment of the disclosure;

[0029] Figure 3 is an example data structure suitable for use with an embodiment of the disclosure;

[0030] Figure 4 shows an example of the message flow between an agent and a base station according to an embodiment of the disclosure;

[0031] Figure 5 is a flow diagram of a process performed by an agent according to an embodiment. DESCRIPTION OF EMBODIMENTS

[0032] With reference to Figure 1 there is shown a wireless communication system 10 according to an embodiment. The wireless communication system 10 includes a shared wireless communications network 12, base station 20, and plural agents 30 (shown as robot agents RA 30-1, 30-2, . . ., 30-/z) operating within an operating environment 14. By virtue of the shared wireless communication system 10, each RA 30 may conduct wireless data communication within another RA 30, or indeed with the base station 20 via nodes 50.

[0033] The shared wireless communications network 12 may be implemented using any suitable wireless communication technology or technologies to provide communication access to the RAs 30. In one example, wireless communications network 12 may operate as a Rajant mesh network. Other examples of shared wireless communications networks 12 may be utilised within the scope of the present disclosure.

[0034] The wireless communications network 12 may include fixed and/or deployable wireless communication nodes 50. Fixed wireless communication nodes may include wireless communication nodes 50 which are prepositioned and/or secured to a fixed structure, such as a mast, whereas deployable wireless communication nodes 50 may include self-powered wireless communication nodes 50 which are deployed by robot agents 30, or otherwise located opportunistically, to expand the range/coverage of the wireless communications network 12.

[0035] The operating environment 14 could be a terranean environment, a subterranean environment (such as a cave, tunnel, shaft, underground mine or similar), a subsea environment, or a combination of different environments. In some applications, the operating environment 14 could be a man-made structure, such as a building, a ship, a space craft, a submarine or the like. In a typical application, the operating environment 14 has a structure or other characteristics which degrade, attenuate, disrupt or denies wireless communication between the agents 30.

[0036] In the context of the present disclosure, a base station 20 is a network element responsible for direct or indirect wireless data communication with one or more RAs 30 over the shared wireless communications network 12. Suitable base stations would be well understood to a skilled addressee.

[0037] In one example, the base-station 20, RAs 30, and wireless communication nodes 50 are dual-band 2.4GHz and 5.8GHz Wi-Fi nodes operating on the same channels with a 20MHz bandwidth. It is not essential that a dual band capability be provided since in some embodiments a single band may be used. In certain embodiments, wireless communication nodes 50 include at least one processor executing a peer-to-peer software module allowing data communicated from a passing robot agent 30 to be stored and transmitted to another robot agent 30 which establishes data communication with the wireless communication nodes 50 at a later time. Other examples may be utilised within the scope of the present disclosure.

[0038] The agents 30 could include autonomous vehicles, autonomous vessels, robots, unmanned aerial vehicles (UAVs), unmanned ground vehicles (UGVs), unmanned submersible vehicles (UAVs), unmanned space vehicles or the like. In certain embodiments, each of the plural agents 30 is of the same type. However, it is possible that in certain examples a combination of different types of agents could be used. An advantage of using a combination of different types of agent types is that different spaces, regions and terrains within the same or a different operating environment 14 may be accessed.

[0039] In certain embodiments, each agent 30 includes a sensor system (not shown) including one or more sensors such as a LiDAR sensor, imaging sensor, microphone or the like. Additionally, each agent 30 will typically include one or more processing devices (not shown) forming part of at least one processing system configured to receive signals from the sensor system. For example, in one embodiment, the one or more processing systems of an agent 30 process sense information received from the sensor system to create a map of the operating environment 12. In one example, generating a map involves the one or more processing systems executing a SLAM type algorithm to perform mapping functions. Each agent 30 may utilise a local navigation pipeline to traverse unstructured terrain and negative obstacles within the operating environment 14.

[0040] The at least one processing system of each agent 30 may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. For a hardware implementation, processing may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. Software modules, also known as computer programs, computer codes, or instructions, may contain a number of source code or object code segments or instructions, and may reside in any computer readable medium such as a RAM memory, flash memory, ROM memory, EPROM memory, registers, hard disk, a removable disk, a CD-ROM, a DVD-ROM, a Blu-ray disc, or any other form of computer readable medium. In some aspects the computer-readable media may comprise non-transitory computer -readable media (e.g., tangible media). In addition, for other aspects computer-readable media may comprise transitory computer- readable media (e.g., a signal). Combinations of the above should also be included within the scope of computer-readable media. In another aspect, the computer readable medium may be integral to the processor. The processor and the computer readable medium may reside in an ASIC or related device. The software codes may be stored in a memory unit and the processor may be configured to execute them. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

[0041] Further, it should be appreciated that modules and/or other appropriate means for performing the methods and techniques described herein can be downloaded and/or otherwise obtained by computing device. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a computing device can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[0042] In examples, the coordination of multiple agents 30, and providing situational awareness to the operator of the base station 20 involves sharing information in relation to a global map upon which other shared information is referenced. However, it is possible that the other shared information need not be referenced to or involve a global map. Other types of shared information may include for example, image information, environmental information, radar information, sonar information, or the like.

[0043] In relation to map information, in certain embodiments, map information is shared through a peer-to-peer communications network, with each agent 30 independently solving for a global map, based on the currently received subset of shared SLAM frames generated by each agent during exploration. Although each agent 30 may have a different set of frames at a particular instant, and receive frames from different agents 30 in different orders, frame overlap guaranteed from a common starting area may allow each agent 30 to incrementally construct its own global map solution for the operating environment 12 based on information from all agents 30, thus enabling an agent 30 to interpret information (such as frontiers, artefact detections, or traversability data) referenced to any other agent’s SLAM frame. [0044] In certain embodiments, and as already outlined above, each RA 30 is a robot agent including a robot operating system (ROS) master 32, and a ROS module 34 for managing inter robot agent 30 data communication. In certain embodiments, base station 20 also includes a robot operating system (ROS) master 22, and a ROS module 24. As would be understood by a skilled addressee, a ROS master 22, 32 typically provides naming and registration services for the robot agents 30 (and the base station 20) by managing publishers and subscribers to ROS topics.

[0045] In certain embodiments, each ROS module 34 of an agent 30 is a software application which enables the RAs 30 to locate one another and, once located, communicate with each other peer-to-peer. For example, in certain embodiments, ROS modules 34 of different respective RAs 30 dynamically discover one another on the shared wireless communications network 12 via UDP multicast, and then establish peer-to-peer (P2P) connections via TCP unicast.

[0046] In embodiments, each local ROS module 34 communicates with local ROS master/publishers/subscribers of its respective RA 30 and also communicates with the ROS module 34 of one or more other RAs 30 over the shared wireless communications network 12.

[0047] In one example, each ROS module 34 is a processor implemented module which provides multi-master, disruption-tolerant, transparent “bridging” of ROS topics.

[0048] Data messages associated with ROS topics configured for bridging may be multiplexed onto peer-to-peer (P2P) connections according to quality-of-service (QoS) options and link quality metrics provided by a local node 50. For example, in certain embodiments each ROS module 34 can bridge a particular ROS topic with either a ‘volatile’ or ‘persistent’ Quality of Service (QoS).

[0049] A ‘volatile’ QoS may be suitable for ROS topics that do not require reliable delivery of every data message (e.g. status, teleop commands, and camera images). In one example involving ‘volatile QoS, each ROS module 34 uses a ZeroMQ library and its PUB/SUB sockets to transport data messages to interested receivers (i.e., other agents 30) in a “best-effort” type fashion. Other examples may be utilised within the scope of the present disclosure.

[0050] On the other hand, a ‘persistent’ QoS may be suitable for ROS topics that require reliable delivery (e.g. SLAM frames and artefact detections). In other words, “persistent” QoS involves eventual but reliable message delivery. In certain embodiments, each RA 30 may have a local database (such as an on-disk database) for storing data messages from ‘persistent’ ROS topics, so that they may be retrieved for communication to a peer RA 30 at some later opportunity. Reliable delivery of these data messages may be achieved by the synchronisation of databases amongst ROS modules 34 of the RAs 30.

[0051] With reference now to Figure 2, in certain embodiments, each ROS module 34 periodically assembles a data structure in the form of a ‘manifest’ 300 describing which data messages are currently stored in its respective database 200. RAs 30 (shown as RA 30-1) periodically broadcasts their ‘manifest’ 300 to peer RAs 30 (shown as RA 30-2) via the shared wireless communications network 12 (ref Figure 1). Peer RAs 30 can then use this information to request the transfer of certain data messages in order to achieve synchronization using a pull-based protocol involving a “pull request” 202 and a “pull response” 204. Figure 5 shows an example process for generating a “pull request”.

[0052] A pull-based protocol is expected to allow for a robust implementation in the face of unreliable network conditions and permit for inter-agent data-sharing without requiring end-to-end paths. For example, a pull-based protocol may improve the ability of the system 10 to withstand disconnection.

[0053] Turning now to Figure 3 there is shown an example structure for a manifest 300. In the depicted example, the manifest 300 includes logs 302 having a single owner/writer 304, meaning that there is no requirement to form any kind of ordering consensus. A “trunc” flag 306 indicates if all data for the log 302 needs to be retained or not. In this respect for ROS topics where every data message carries unique information, such as object detections, it may be desirable to retain and synchronise all data. On the other hand, for ROS topics where only the latest message matters, it may be possible to discard “old” data, and exchange only the latest message during synchronisation. A tail field 308 stores the index of the latest message in the local log 302 replica to allow peer RAs 30 to detect when they are trailing behind one another.

[0054] In one example, when a ROS data message configured for persistent transport is “published” on-board a RA 30, the RA’s 30 local ROS module 34 places it into its local database 200 as part of a particular append-only log. Log metadata would be periodically assembled into the so-called manifest and multicast out to peers to inform peer-to-peer synchronisation.

[0055] In some embodiments, a “pull request” 202 (ref. Figure 2) contains the requesting RA’s 30 own manifest 300 and a transfer budget. The RA 30 receiving the pull request determines what data messages are communicated in response to the pull request 202. In one example, the receiving RA 30 fills as much of the transfer budget it can with data messages from its own groups first, and then selects groups randomly to fill up the remainder of the transfer budget. Thus, in this example the RA 30 receiving the pull request 202 makes this selection since the mapping between message indexes and sizes is only known by the RA 30 receiving the pull request 202.

[0056] In one example, the transfer budget may be dynamically chosen to balance the responsiveness and efficiency of transfers across a range of network conditions. When assembling transfer replies, use of the budget may be prioritised such that data from locally sourced group logs is transferred before data from other group logs. Alternatively, the transfer budget may be determined based on a desired transfer duration. The transfer budget may be additively-increased (when it completes early) or multiplicatively-decreased (when it completes late). Alternatively, a fixed transfer size (similar to a BitTorrent chunk size) may be used. It is also possible that byte indexes could be used.

[0057] By allowing the RA 30 receiving the pull request 202 to set a maximum transfer budget, dynamic trade-off efficiency and responsiveness based on prior transfer performance may be achieved. Without network limitations, certain embodiments may achieve a synchronisation rate of lOOMb/s which is anticipated to be sufficient for mission-critical data messages such as artefact detections, sub-map data, and task-allocation information. However, it will be appreciated that different synchronisation rates could be used.

[0058] Additionally, an RA’s 30 ROS module 34 may “publish” information to its local ROS system to enable autonomous decision, including in relation to data-sharing. This includes synchronisation status for each peer, making it possible for RAs30 to decide, for example, if they should return to base station 20 to deliver mission-critical data messages.

[0059] An ROS module 34 can be implemented in any suitable computer software language. In one example the ROS module 34 is implemented in Python 3 using libraries such as ZMQ (for transport protocol selection such as sockets and building blocks of common messaging patterns) and Tornado (ie., an asynchronous networking library capable of managing a lot of input/output events efficiently) could be used to handle concurrency via an asynchronous lO-loop rather than multithreading.

[0060] In view of the above description, it will be appreciated that certain embodiments of the present disclosure provide a multi-master, P2P disruption tolerant communication system which allows for reliable message delivery using a hop-by-hop approach as opposed to an end-to-end approach, meaning that data can be communicated from, for example, RA 30-1 to RA 30-2 (ref. Figure 1) without there being a complete data communications path between them at any given time. Figure 4 shows an example of the message flow between an agent 30 and base station 20 via P2P swarm 400 of agents using ROS modules 24, 34 provide transparent “bridging” of a ROS topic.

[0061] In terms of other features, some embodiments may additionally implement “heartbeats” to detect disruption, automatic compression of ROS data, and connection multiplexing to maintain transport overheads and the number of competing flows on the network low. It will be understood that the terms “comprise” and “include” and any of their derivatives (e.g. comprises, comprising, includes, including) as used in this specification, and the claims that follow, is to be taken to be inclusive of features to which the term refers, and is not meant to exclude the presence of any additional features unless otherwise stated or implied.

[0062] In some cases, a single embodiment may, for succinctness and/or to assist in understanding the scope of the disclosure, combine multiple features. It is to be understood that in such a case, these multiple features may be provided separately (in separate embodiments), or in any other suitable combination. Alternatively, where separate features are described in separate embodiments, these separate features may be combined into a single embodiment unless otherwise stated or implied. This also applies to the claims which can be recombined in any combination. That is a claim may be amended to include a feature defined in any other claim. Further a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b- c, and a-b-c.

[0063] It will be appreciated by those skilled in the art that the disclosure is not restricted in its use to the particular application or applications described. Neither is the present disclosure restricted in its preferred embodiment with regard to the particular elements and/or features described or depicted herein. It will be appreciated that the disclosure is not limited to the embodiment or embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the scope as set forth and defined by the following claims.

The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.