While a single, peer-to-peer rover can cover a large territory and gather a wealth of information, an entire fleet of rovers could cover even more ground. However, controlling multiple platforms poses a much different set of criteria. To answer the need to control and communicate with multiple vehicles doing a similar task, the Adaptive Sensor Fleet (ASF) software was developed by NASA researchers, and is able to coordinate several platforms at once. Julia Loftis oversaw the strategic planning of the project.
NASA Tech Briefs:What is the Adaptive Sensor Fleet software, and how does it work?
Julia Loftis: The Adaptive Sensor Fleet software, or ASF, is a supervisory control system for a fleet of mobile platforms. It's a very open, extensible system in that each platform can be completely different — they can be configured with different sensors, they could move at different rates, they can be stationary. They can be of all types in a single fleet. You would define each platform and its sensors in XML, and the control software is then able to control these platforms as a group and optimize their performance to accomplish a goal. Basically, it allows a user to specify a goal of the entire system, and then it directs each platform as how to best accomplish that goal. ASF is a conservative approach. There is a central supervisory function. ASF can accommodate intelligent platforms, or very simplistic platforms, or a mix of the two. Having a supervisor reduces the risk a bit, and can also help with optimization (ability to see the forest instead of just the trees). Other approaches, such as a pure peer-to-peer architecture, rely on a degree of intelligence for each platform. This can be more advanced and/or innovative, but also more risky. In summary, both approaches are valid and for each application you need to weigh the benefits vs. risk.
NTB: Is ASF being utilized now?
Loftis: It is. A good example is the OASIS project, which is a fleet of autonomous boats. The OASIS boats use ASF to monitor harmful algal blooms. The original application idea was for Martian rovers, and then boat idea came along and the ASF worked really well. We were able to adapt the XML and control the boats in the same way. A user would decide what bloom to monitor, or even a satellite might discover a bloom, and based on that, and based on direction to monitor a bloom, the ASF software would the divide up the area of that bloom and give each platform directions as to where to go and give it waypoints.
Now, say that one platform accomplishes its goal faster, or the bloom moves, or some other dynamic event happens — the ASF control software will keep track of the data collected and the area that has been covered, and will continuously adapt what it is directing each platform to do to optimize how that platform is working. We also did a technology demonstration with three miniature rovers. They did path planning and mapping of an area that was a simulation of a Marian terrain. That was a demo; OASIS is the first real application. We don't have the resources to launch into space a fleet of rovers yet, but it is in the future. Monitoring algal blooms, which is experimental, is where we are getting started. Because we don't have to launch them, we can have more boats. I think it is good to start with something that is less risky, more controlled, to see if ASF works well and doesn't get into anything dangerous. Once that works, we might let the platforms be more autonomous and take a little more risk.
NTB: Why was the software developed?
Loftis: Originally, what we were looking at, what we perceived as a technology organization, was future needs. And in any application where you may be searching for something, it's logical that you would have multiple platforms do this rather than just one. We were thinking of applications for rovers on the surface of Mars for mapping or site-surveying — anything where you would have to do local, in situ measurements. We were looking for software that could control a fleet of platforms to do this, instead of a single platform.
Goddard has been very interested in the concept of "sensor webs," multiple sensors that act as a coherent system. In particular, when you can't do remote sensing, for example, if an area is cloud covered, that's when you send sensors in to measure in situ, right where they are. For under cloud-covered areas or sub-surface measurements, that's when you are really going to need to send in fleets of platforms, which is essentially a sensor web. So we are looking at this concept of dynamic, moveable, optimizable sensor webs.
As for me, my job as Code 580 Assistant Chief for Technology is to do strategic planning, which identified the need for such a system, create partnerships, with the OASIS boats led by oceanographer at WFF Dr. John Moisan, find funding and sell the project (IRAD, then AIST), formulate a project with project lead Jeff Hosler and Troy Ames who provided the underlying technology, and monitor its progress while continuing to look for new opportunities for application and funding.
NTB: Describe the ASF architecture and how the process works.
Loftis: I want to emphasize that ASF is different from many approaches that are "peer-to-peer." A peer-to-peer approach would be a single platform, would make its own decisions based on its environment, and would be autonomous. Each platform would be autonomous and communicate to each other. ASF is a supervisory system. It's very good if some of your platforms aren't "smart" and it is very efficient; it can see the forest for the trees.
In XML, ASF is first configured to know what platforms are there, their characteristics like its inputs and outputs, what controls are used. What happens is, a user then sets up a goal or objective within ASF, and says what area he or she wants to monitor, what is being looked for. ASF takes that goal and parses it and divides the work among the platforms that are available. Then ASF will go about sending directions to each platform as to what measurements to take and what waypoints to go to, and it will continue to monitor the fleet as the data is collected and it will fuse the data and present it to the consol operator. It will accomplish the goal, and display all the data.
A central consol controls the platforms. It could be stationary buoy, it could be a remote-sensing satellite, and they all work together. From the remote sense data, we might find out where the algal bloom is; we might collect data from the stationary buoys and we could instruct the boats to go to them. It would be a mixed fleet of all types of platforms. Additionally, ASF would immediately know if a platform failed. It's a controlled means, directing each platform and controlling what it does, to adapt if one gets stuck or breaks. It will have the others fill in and take that work. ASF is monitoring the progress that each platform takes, and it would assign another platform to take over that area.
I should say that ASF and peer-to-peer could be used for the same task complimentarily. We can have platforms that are pretty stupid, and a user just instructs them to go to a waypoint. That is all they can do: navigate there. We could also have some platforms that are very intelligent, and a user can instruct them to find something, and they will go off and find it. We can have various levels of intelligence, but at the moment, all of our platforms communicate though us and don't communicate directly to each other. We don't prevent that, but ASF's strength is in controlling all the platforms.
ASF and peer-to-peer each have their set of challenges. Peer-to-peer may be more challenging in that there is more intelligence required to have an optimized system. Each platform needs to be pretty smart, and ASF is a more basic approach. In some instances, it is going to work better. If you want to integrate legacy platforms that are not intelligent, you are going to need a controller that can take charge and control it in a rudimentary way. The ASF approach is also more deterministic, a little less risky, where we are taking over all these platforms. Peer-to-peer is a more advanced method; each platform is intelligent and acting on its own, and you don't necessarily know what's going to happen. There could be interactions you didn't anticipate.
NTB: How many vehicles can ASF control?
Loftis: There's no limit, technically. In the case of OASIS, it's all going to be limited by bandwidth and communications with the boats, and getting the data back. There is no specific limit, and one vision we have is hundreds of these boats up and down the coastline doing coastal monitoring, either for homeland security or for weather, to get subsurface temperature measurements of the water that would improve forecasting accuracy. Potentially, ASF could control hundreds of platforms.
NTB: What commercial applications could there be?
Loftis: We have a lot of ideas along those lines. I really think homeland security, any type of coastal monitoring, of tracking the source of pollutants, EPA applications, certainly NOAA applications in improving hurricane prediction — all those are good applications for the boats. But then, if you look at robotics, any place where a fleet of robots would be better than a single robot, such as search and rescue, or monitoring the safety of bridges and nuclear power plants, monitoring oil spills, those kind of things ASF really gears itself towards an environment that might be changing and it can handle that. We even had an interesting idea that you could manage fleets of people, where the ASF software, instead of directing a robot, could send a text message to a person. If you had 200 volunteers searching through the woods for a lost child, probably each of them is covering the ground that somebody already covered. ASF could be an executive, through GPS, monitoring where everybody had been and could optimize their coverage. It could work.
For more information, contact Ms. Julia W. Loftis: