Wireless Control Sets Automated Vehicles Free

As pointed out in the Wireless Control Supplement to the August 2007 Control Engineering, one of the main motivations for incorporating wireless communications into automated control systems is to free moving system components from tethers. Using electrical cables to carry control signals to and from moving system components hobbles them.
By C.G. Masi, Control Engineering April 1, 2008
Mooncasts and maneuvering in not-so-near real time
When gremlins haunt your handling system, who ya gonna call?

As pointed out in the Wireless Control Supplement to the August 2007 Control Engineering , one of the main motivations for incorporating wireless communications into automated control systems is to free moving system components from tethers. Using electrical cables to carry control signals to and from moving system components hobbles them.

Like a dog tied to a tree by a heavy chain, such components cannot move without interference. Compared to wireless communication links, cables are heavy, stiff, have extremely limited range, and generally get in the way. Cables get tangled, break, are run over, and create trip hazards. Nobody ever tripped over a wireless comunication link.

Nowhere is this wireless advantage more obvious than in moving-vehicle applications. Imagine an unmanned aerial reconnaissance vehicle searching a valley in Pakistan for hidden Al Qaeda terrorists while dragging along a half-mile Ethernet cable. What about trying to control a lunar rover from Earth over a fiber-optic cable? As my daughter used to say when a teenager: “Nuh-unh!”

Today, nearly every high-end moving vehicle has some level of wireless control communications, and future systems will rely on wireless even more. This article describes two applications of wireless vehicle control that are either already deployed, or are in development.

If there is one common thread, however, it is that wireless is used to inform automated control systems, but seldom forms part of the actual control loop. There are a number of good reasons for this characteristic. All of them apply to most control applications, and none of them show any sign of losing validity in the foreseeable future.

  • Keeping control loops short is always a good idea. Wireless links are typically quite long, so they’re not well suited to life inside a control loop.

  • Real time control, which requires consistently fast communication, is necessary in any vehicle application. While wireless communication can operate in real time, long distances, such as between the Earth and the moon, make even wireless communication move at a glacial pace. Therefore, just when wireless is most critical, it can’t be used inside a loop.

  • Possibility of interruption is a serious consideration. Wireless communication is a lot easier to disrupt than hard-wired communication. There are a lot more ways to interrupt wireless service, and they’re a lot more likely to happen. It’s one thing to interrupt a transmission while communicating a task list, say, or set-point parameters. You can always retransmit. Interrupting a vehicle control loop even for just a few seconds, however, can be disasterous.

Author Information
C.G. Masi is a senior editor with Control Engineering. Reach him by email at charlie.masi@reedbusiness.com

Mooncasts and maneuvering in not-so-near real time

With a 2.7s time delay, rover operators on Earth cannot exert real time control.

The Fabulous Thunderbirds’ lead singer Kim Wilson claims to be “Tuff Enuff” to “take you to the moon….” While the T-Birds meant it metaphorically, Fred J. Bourgeois III and his friends at Team Frednet aim to prove that they really are tough enough to take a robotic rover to the moon, and make some valuable observations when they get there. Team Frednet is one of ten teams competing for the $30 million Google Lunar X-Prize offered by the X-Prize Foundation for the first privately funded and managed robotic expedition to reach the moon.

The rules state: “To win the Google Lunar X Prize, a team must successfully land a privately funded craft on the lunar surface and survive long enough to complete the mission goals of roaming about the lunar surface for at least 500 meters and documenting it with a video program, called a “mooncast,” sent back to Earth. “The mooncast consists of digital data that must be collected and transmitted to the Earth composed of the following:

High resolution 360

Self portraits of the rover taken on the surface of the moon;

Near-real time videos showing the craft’s journey along the lunar surface;

High definition (HD) video;

Transmission of a cached set of data, loaded on the craft before launch (e.g., first e-mail from the moon).

“Teams will be required to send a mooncast detailing their arrival on the lunar surface, and a second mooncast that provides imagery and video of their journey roaming the lunar surface. All told, the mooncasts will represent approximately a Gigabyte of stunning content returned to the Earth.”

There are, at the time of this writing, 10 teams officially registered in the competition. Team Frednet is a multi-national team comprised of systems, software, and hardware developers who serve as the leaders and overall coordinators of an international group of open-source developers, engineers, and scientists. Their goal is to bring the same successful approach used in developing major software systems to bear on the problems associated with space exploration and research.

The controls problem the team faces once they get to the moon is how to steer their rover. It takes approximately 1.35 s for a radio signal to span the 385,000 km (239,228 mi) average distance between the Earth and the moon.

“What we’re imagining,” says Dan Smith, hardware engineering lead for Team Frednet, “is a very small rover with dual systems for communication and video, and the capability to orient itself and have some fault tolerance and fault correction built into it.”

The system is more than just one spacecraft. The team envisions three separate components: a lunar orbiter (called the “lunar bus”), a lander, and a rover. These components will start out like Russian matryoshka nesting dolls, with the rover carried by the lander, which will, in turn, be carried by the bus.

The whole assemblage will be lofted into low Earth orbit by an as-yet-undetermined commercial satellite-launching service. From Earth orbit, the bus will carry the project to lunar orbit, where it will deploy the lander. The bus will remain in lunar orbit to help relay signals to and from the team’s base on Earth.

The lander will descend to the lunar surface and deploy the rover. As the sole stationary component, the lander will include radio systems to communicate with the lunar bus (still in orbit), the rover, and directly with Earth.

The rover’s job is to move about on the lunar surface, posing for cameras based on the lander and acquiring imagery of its own. The lander will transmit the rest of the required mooncast data.

The lander will carry preprogrammed commands and procedures. From Earth, team members can send commands to initiate programs and procedures. With the long communication delay, however, they cannot exert real-time control. That capability must be shared between the lander and rover.

“The rover wants to have general autonomy for figuring out how to get from point A to point B, aim its antennas, aim its camera, and send signals back,” says Smith, “The lander is actually supposed to act kind of like a server — watching out for the rover like a mother duck.”

When gremlins haunt your handling system, who ya gonna call?

Wireless transfer of both information and electric power make automated material handling in a harsh environment simple, clean, and efficient.

The dilemma that facing OEM Ipsen International when upgrading a client’s heat-treating facility was how to power automated guided vehicles (AGVs) carrying heavy loads to and from ovens. The client was automating its entire facility to improve productivity and make the company more competitive. The vision was to introduce more fluidity in the factory operation.

Batteries are heavy, need periodic recharging, and have limited tolerance for heat. Festooning a power cable along the AGV’s path to keep it off the floor where it can be run over, get tangled, and create a trip hazard was not viable, either. Sliding contacts in this environment could short out, create a shock hazard, and collect debris before failing due to corrosion.

Tim Adams, Ipsen’s Southeast sales representative, recalls, “We had to ensure that the upgrade was in line with their philosophy of automating efficiency and productivity. Our objective was to bring heat treating up to this standard.”

Ipsen achieved this upgrade in part by replacing methanol with a “Supercarb” process using natural gas to avoid increases in methanol costs. The second part of the challenge, however, was to make heat-treating a lights-out process.In other words, wirelessly!

Ipsen’s solution was to incorporate SEW-Eurodrive’s electronic monorail system (EMS). By combining SEW-Eurodrive’s Movitrans contactless energy transfer system, and drive-based controls, engineers at SEW-Eurodrive had developed a system that transmits energy over an air gap from cables under the floor to power the AGV and its control system. Wireless Ethernet enables remote monitoring and control. The result is an innovative system that is more flexible, cleaner, and requires less maintenance than traditional material handling systems.

Initially designed for off-floor conveyors used for material supply in the automotive industry, the EMS system is now being adopted for other assembly operations, food and beverage packaging, distribution warehouses, and airport logistics. The system is able to handle both light and heavy loads, and single or multi-axis applications.

Ipsen worked with SEW-Eurodrive to jointly design a fully-automated, lights-out heat-treat facility based on EMS technology. “Key to the successful automation was taking the work from the staging area to the proper furnace and then back to the unloading area, where it would be redistributed back to the shop for the next manufacturing procedure,” says Adams. “The fully automated cart becomes the focus of that automation system. What the SEW system did was position the cart at the proper time at the proper location; it was also able to maintain the workflow from the staging area to the equipment and back out again.”

Movitrans uses near-field inductive coupling between cables embedded in the rail structure and pickup inductors mounted under the cart. Each trolley carries its own drive, controls, communications and power electronics, allowing it to operate independently along the rail path through the material handling system.

Decentralized control enables the speed for each trolley to vary individually, and be easily adjusted for changes in production requirements or process variables. Controls are governed by parametrics rather than programming, simplifying installation and start-up. The system’s client-server architecture provides a central database for data storage, parameter changes, diagnostics, initial start-up and unit replacement.

“The system has resulted in a huge labor savings,” says Adams. “It has allowed us to [reduce] labor and focus on loading and unloading the basket, and prepping the work to go to or come from its next or previous manufacturing step. The heat-treating process now requires only one person: an operator or staging individual, who simply stages work as it goes in and comes out.”