Circuit Designs

Exoskeletons Ratchet-up Strength, Endurance

Aviation Week's DTI | Bettina H. Chavanne | April 10, 2009

This article first appeared in Defense Technology International.

The soldier exoskeleton has moved from the realm of science fiction to reality, with contractors like Raytheon and Lockheed Martin partnering with smaller firms to bring products to market. But one big challenge remains: convenient and safe power for these machines.
Helping troops lug the weight of their equipment around is serious business, and the U.S. Army is actively pursuing solutions.
"You can't hump a rucksack at 11,000 ft. for 15 months and not have that have an impact on your body," Gen. Pete Chiarelli, the Army's vice chief of staff, told reporters in January. The Army and Marines are witnessing a rise in musculoskeletal injuries. "There's no doubt our non-deployable rates are increasing."
Heavier body armor and equipment, compounded by the challenging terrain faced by troops in Afghanistan, mean those numbers are going to grow.
For nearly a decade, a project launched by the Defense Advanced Research Projects Agency has been looking at ways to help with the heavy lifting. The Exoskeletons for Human Performance Augmentation, a program whose stated goal in 2000 was "to develop devices and machines that will increase the speed, strength and endurance of soldiers in combat environments," is finally a reality. At the behest of the Army, a team at Raytheon Sarcos, led by Stephen Jacobsen, built an exoskeleton called XOS. Video of the device in action shows software engineer Rex Jameson in the metal suit running, jumping, even speed boxing a punching bag. Jameson also does a lengthy series of reps on a weight machine, pulling down 200 lb. (see photo). "He stopped because he got bored," Jacobsen says, "not because he was tired."
"Qualitatively the suit has good mobility," says Jeff Schiffman of the Army's Natick Soldier Research, Development and Engineering Center, who has worked on the project for several years. He says the XOS provides a roughly 10:1 gain for a human. "The idea is that if you're holding a 200-lb. box, it'll feel like 20 lb.," he says. Schiffman and his team evaluate the suit for its biomechanical and physiological aspects. How comfortable will operating the XOS be for a soldier?
Human factors issues have been relatively easy to navigate, Schiffman says. The Natick team's goal, he adds, is to combine all the processes so a soldier can easily operate and get in and out of the suit without help.
And then there's the matter of powering the suit. The first suit Raytheon Sarcos built in 2002 was not powered. The XOS now is tethered to a hydraulic pump that gets its energy from an external power supply that can run on propane, hydrogen or gasoline (and in later iterations, diesel), says Jacobsen.
"Before you do it right, you have to do it at all," he adds. He breaks down the power issue into several levels. "First you have to show you can do the biomechanics, that it can move like you move," he says. Then you have to determine how large your actuators need to be to accomplish those movements, as well as how much power those basic movements (including step, squat, walk, run, stumble) will consume.
Jacobsen's team built numerous backpacks powered by electricity and fuel, but to get the power they needed, they had to develop their own valve system, which he says was "as hard as anything we did." The servo valves control the hydraulic fluid feed to the actuators. Jacobsen was forced to engineer the valves to meet the size, reliability and efficiency demands he sought for the suit.
Despite the meticulous engineering and effort the valve design required, Jacobsen is certain his system is the best way to power the exoskeleton. "[A hydraulic system provides] a high power and force-to-rate ratio. That's why it's used in machines with energetic requirements."
He hopes to eventually use the suit itself as a power-generating system, to charge batteries as the user runs or while he sleeps. "We have the most versatility," says Jacobsen. "We have the most power-to-weight and torque-to-weight [ratios]. We can drive it electrically with batteries or tether it to an internal combustion engine hydraulically. Every option is there."
Jacobsen has done a study on different methods of generating power. One possibility is for the XOS wearer to have a case to carry around "like astronauts do," intermittently setting it down during work and then relocating the powerpack as the person moves. A powerpack on the wearer's back would be ideal. "He would be totally mobile during the time he had fuel," Jacobsen says.
Although XOS is Army funded, it's not the only game in town. Lockheed Martin has paired up with Berkeley Bionics on an untethered, hydraulic-powered exoskeleton called the HULC, or Human Universal Load Carrier. Berkeley Bionics has worked on strength-augmentation programs before, with products like ExoHiker and ExoClimber. But the HULC is for endurance augmentation -- it decreases the "metabolic cost" to the wearer, the company says. Contained within its product information is the claim that the HULC decreased oxygen consumption of users walking at 2 mph. by about 5-12% when using the test unit without a payload. "When the users [carried] an 81-lb. approach load at 2 mph., [oxygen consumption] decreased by about 15% when using the prototype HULC," the web site reports.
The HULC is not a full-body suit like the XOS. It is a "power-savvy technology that focuses on lower-extremity mobility," says Doug Medcalf, business development manager for Lockheed Martin, which basically means it's a pair of powered titanium legs. Users can squat, crawl and lift heavy objects. Medcalf, an Army veteran, says the HULC has applications beyond the military, including industrial and even medical assistance. The HULC "allows users to carry the weight they need [to carry], but without the wear and tear" on joints and muscles.
The hydraulic power comes from servos powered by lithium ion batteries. "By not having cables and power connections or a high power demand, we can keep [the system's weight] to 53 lb.," Medcalf says.
Aside from power-management issues, both HULC and XOS face environmental challenges. How do you protect sensitive sensors from the harsh operating environment of the battlefield? "The systems and servos are protected, but we're always looking at ways to make them more durable in the most extreme environments," Medcalf says.
Jacobsen says the first level of XOS prototype addressed human-factors issues, the second level of prototype dealt with power and usability in real-world situations and the third, or XOS 3 as he calls it, looks at how to shield the system from the environment and make it cost-effective to manufacture. There are entire parts of XOS 3 that are sealed away from dust and liquid, Jacobsen says. Mass production may also lead to molded aluminum or composite shells, obviating the need for tubes for the hydraulics.
XOS 2 is heading to Natick in October for human factors work, at which point XOS 3 will begin a full test run in Utah, where Raytheon Sarcos is headquartered.
The greatest challenge for the future warrior -- covered in sensors beaming information to various mobile platforms, and leaping sand dunes in a single bound -- isn't the construction of a futuristic suit of armor, it's powering all the energy-draining technology that comes with it.


http://www.theyshallwalk.org/blog.asp?catid=3&blogid=15

Iron Man-ASTHI Prototypes

Iron Man

Iron Man. Indians think of Sardar Vallabhai Patel. Music geeks mentally play the celebrated riff from the Black Sabbath song. But most people think of the Marvel Comic book character played by Robert Downey, Jr. in the movie Iron Man (2008). With the advent of the radical technology of powered exoskeletons as practical possibilities in the near future, Tony Stark in his suit may soon become a reality. Wait... what are powered exoskeletons? They are just what they suggest they are – an exoskeleton energized by a power supply. Exoskeletons have been around in nature for millions of years. Even humans have been using artificial exoskeletons in the form of armour for defence and combat. Now the technology of powered exoskeletons can take it further, to industrial applications and medicine.

Powered exoskeletons primarily do two things-

assist - help workers lift heavy loads, help rescuers lift and move debris, medically assist aged and incapacitated people; and

protect – protect soldiers, construction workers and other people working in hostile or unsafe environments.

These mobile machines can be considered to be ‘wearable robots’. They are usually mechatronic systems that are designed around the shape of the user. Accordingly, the joints and segments of the exoskeleton correspond to those on the user. The machines can have different power sources (finding a suitable power supply is actually one of the challenges involved in this technology).

Currently, there are already a few exoskeletons. For example, HULC™ manufactured by Lockheed Martin, Honda’s Exoskeleton Legs, M.I.T. Media Lab's Biomechatronics Group legs and Raytheon’s XOS.

But it was General Electric that had developed the first exoskeleton device in the ‘60s. Called the Hardiman, a hydraulic and electrical body suit, it was not very successful because itwas too heavy and bulky for military use. One of the first exoskeleton prototypes meant to aid in walking was created by Monty Reed, an army ranger who’d had a parachute accident in 1986, after being told that he would never be able to walk again. He was inspired by Starship Troopers (by science fiction author Robert Heinlein) and created LIFESUIT™1 (or LS1) in the broom closet of his basement while attending college. Monty is now Executive Director of THEY SHALL WALK™, a non-profit medical research organization. At present, prototype LS15 is being developed in their lab.

The HULC™, as explained by Lockheed Martin, its developers, is a completely un-tethered, hydraulic-powered anthropomorphic exoskeleton that provides users with the ability to carry loads over 90 kg for extended periods of time and over all terrains. An onboard micro-computer eliminates the need for a joy stick or other controllers. The HULC™ is capable of performing deep squats, crawls and upper-body lifting. It weighs around 27 kg including the two Lithium Polymer Batteries. The HULC™ exoskeleton transfers the heavy combat loads that soldiers have to carry to the ground through powered titanium legs without loss of mobility. Under a new exclusive licensing agreement between Lockheed Martin and Berkeley Bionics™, there will be further enhancement within the HULC system.

Scientists at M.I.T. Media Lab's Biomechatronics Group, with funding from the American Defense Advanced Research Projects Agency (DARPA), have developed an exoskeleton that promises to lessen the load of travelers and also advance research that will ultimately lead to robotic limbs for improving the strength and mobility of amputees. According to a report in the International Journal of Humanoid Robotics the M.I.T. exoskeleton is designed to be lighter and require lesser power than similar devices already under development. The wearer of the M.I.T. exoskeleton places his or her feet in boots attached to a series of tubes that run up the leg to a backpack. The exoskeleton, powered by a 48 V battery pack, uses an onboard computer, weighs 11.7 kg and requires 2 W of electrical power during loaded walking. The device fits parallel to the legs, transferring payload forces from the back of the wearer to the ground.

Last year, Honda Motor Company Limited introduced a supportive lower-body exoskeleton. This walking assist device is designed to reduce the load on leg muscles and joints (in the hip, knees, and ankles) by supporting a portion of the wearer's bodyweight. It acts as an exoskeleton in the sense that it straps over the wearer's clothes and provides two artificial legs that fit alongside the wearer's own legs. The exoskeleton, which comes in small, medium and large sizes, weighs about 6.5 kg. It is secured with a belt around the hip and thigh, then the user straps into a pair of shoes connected to it. A mini-saddle fits between the wearer's legs. The machine is powered by a lithium ion battery that lasts about two hours between charges, as long as the wearer isn't walking faster than 4.5 km/h.

The exoskeleton that has been most likened to Marvel Comics’ Iron Man himself, is the XOS. It is essentially a wearable robot that amplifies its wearer’s strength, endurance and agility. Built from a combination of sensors, actuators and controllers, the futuristic suit enables a user to easily carry a man on his back or lift 90 kg several hundreds of times without tiring. And yet, the suit is agile enough to let its wearer kick a football, punch a speed bag, or climb stairs and ramps with ease. In 2000, DARPA had requested for design proposals for a powered military exoskeleton. Of the fourteen designs submitted, DARPA had chosen the one submitted by Sarcos, an American engineering and robotics firm. The Sarcos design involved a suit powered by a single engine, including a tank holding 24 hours of fuel that sat near the wearer's buttocks. The suit gave the wearer increased strength and endurance through servo motors powered by the engine. The finished suit was named the XOS Exoskeleton and weighed 68 kg. Popular Science reported that the XOS gave wearers the ability to lift 91 kg "repeatedly with minimal strain". Nearly two years ago, American defense contractor Raytheon purchased Sarcos and is now developing this robot suit for the soldier of tomorrow. The lightweight aluminium XOS, senses the user’s every move and instantly moves with him or her, almost like a shadow or a second skin. It is designed for agility that can match a human's, but strength and endurance that far outweigh any human’s abilities. With the exoskeleton on and fully powered up, the user can easily pull down a weight of more than 90 kg. For the army the XOS could mean quicker supply lines, or fewer load-related injuries when soldiers need to lift heavy weights or move objects around repeatedly. The army hopes that later models can go into combat and carry heavier weapons or even wounded soldiers.

Exoskeletons could also be applied for rehabilitation of stroke or SCI patients. Such exoskeletons, sometimes called Step Rehabilitation Robots, could reduce the number of therapists needed by allowing even the most impaired patient to be trained by one therapist (as compared to the several needed now). Training could be more uniform and specifically customized for each patient. Presently there are several projects designing training aids for rehabilitations centers. For example, the LOPES exoskeleton and Cyberdyne’s gait trainer, HAL 5.

The LOPES project (LOwer-extremity Powered ExoSkeleton) is looking to design and implement a gait rehabilitation robot for treadmill training. The target group includes people who have suffered a stroke and have impaired motor control. The main goals of LOPES are reduction of the physical load on the therapist or patient, increased efficiency of gait training for stroke patients and selective support of gait functions.

Cyberdyne’s Robot Suit HAL (Hybrid Assistive Limb), as has been made public by the company, is a cyborg-type robot that can expand and improve physical capability. Through a sensor attached on the skin of the wearer, HAL catches very weak biosignals that can be detected on the surface of the user’s skin at the moment when the user moves (nerve signals are sent from the brain to the muscles via motoneuron, moving the musculoskeletal system as a consequence). HAL 5 is currently capable of allowing the operator to lift and carry about five times as much weight as they could lift and carry unaided. The full body machine weighs approximately 23 kg and is powered by a Battery Drive Charged battery (AC100V). It can operatecontinuously for about 2 h 40 min. Cyberdyne expects the HAL to be applied invarious fields such as rehabilitation support and physical training support in the medical field, ADL support for disabled people, heavy labour support in factories and rescue support at disaster sites.

Evidently, the powered exoskeleton has great potential, considering how many fields, and hence people, can benefit from the technology. Now there might be sceptics who call all this just blather and argue that it will not be feasible. We only have to remind them how it was with other path-breaking technologies like the computer and the cellphone. The rest, as they say, is (and will be) history. AsJohn Michael "Ozzy" Osbourne once sang, “Iron Man lives again!”

Microcontrollers for the Automobile Ross Bannatyne Transportation Systems Group, Motorola Inc. Introduction The object of this article is to discuss the changes that will occur in the use and implementation of microcontrollers that will be used in automobiles in the next generations of systems. The functions that are required to be maintained by the microcontroller and the type of technology that will enable the function will be addressed. The next ten years will see as steady a growth in automotive electronic systems as the last decade. Driving this growth is consumer demand for enhanced safety features, entertainment systems, added convenience functions and government edicts on emissions controls. Figure 1 illustrates the implementation growth of microcontrollers in automobiles. Three categories are shown; low-end, mid-range and luxury vehicles. Typically, systems that are first introduced on luxury vehicles eventually migrate down into lower priced vehicles. The length of time that it takes to migrate down depends on how quickly the system can be cost reduced and how valuable it is perceived by the consumer.                                 Figure 1 - Microcontroller implementation growth in the automobile Most of the current vehicle electronic control systems are now being enhanced and expanded. For instance, consider airbag systems - it is expected that the two frontal airbags which are common today will be joined by further frontal airbags (feet, knees), several sidebags, rear passenger airbags and advanced sensing systems for detecting occupant position. Similarly, braking, steering, suspension, powertrain and body control functions will all be further developed by implementing more advanced electronic systems. As well as the complexity of systems becoming greater, many altogether new systems will be added. In the next few years, systems such as GPS-based Navigation systems, Stability Management systems, 'By-wire' Braking and Steering systems, Collision Warning, Voice recognition, Internet access, Night Vision Enhancement and Collision Avoidance systems will all start to be introduced. These examples are just a start. Another factor supporting the increase in electronic vehicle in the automobile is the networking of new and existing systems. There are many benefits of networks in the automobile and from a control systems standpoint; it is advantageous as systems can share data in real-time, thus making more intelligent systems possible. For example, an Integrated Chassis Control system layer may be implemented by coordinating the data generated by the braking, steering and suspension systems. Another benefit of these networks is that 'second guessing' becomes easier. Second-guessing is the practice of using data from one system to check the plausibility of the results of an independent system. This data could be used as a back-up under certain conditions. For example, the wheel speed and vehicle directional information used in a Stability Management system could be used to supplement the Navigation system, especially in the event that GPS is lost. Microcontroller functions In order to deal with the new range of system requirements, the automotive microcontroller will be further developed to facilitate new functions. Communications Communications between electronic control units (ECU's) is a growing trend. Multiplexed communications in vehicles was originally developed to reduce weight, interconnections, cost and complexity. It soon became apparent however that vehicular systems could be enhanced greatly with the opportunity to share data from different ECUs, in real time. Unfortunately, a single communications protocol, which can cost-effectively address every automotive application, does not exist. Instead a number of different communications subsystems are integrated together in a modern vehicle. This is illustrated in Figure 2. Figure 2 shows five distinct communications systems, which are implemented on a vehicle. In addition it is likely that there will be a number of additional 'sub-bus' networks for sensors and actuators. Gateways exist between these networks to share information across 'boundaries'. The chassis control functions are grouped on a redundant network, which meets fault tolerant criteria; only safety critical information is allowed on these buses. Likewise a highly robust independent network is provided for the airbag system. Many new automotive microcontrollers will have more silicon devoted to communications capabilities than the CPU! Already, microcontrollers such as the M68HC912DG128 are being offered with two independent CAN (Controller Area Network) modules along with several more synchronous and asynchronous communications systems. These communications interfaces are as autonomous as possible, so that the CPU does not need to devote a great deal of overhead to managing communications.                Figure 2 - The networked vehicle Algorithm complexity The increasing complexity of automotive electronic systems has had a dramatic effect on the throughput requirements and peripheral integration of automotive microcontrollers. Algorithms are now required to handle the inputs from many sensors and communications systems, execute real-time control cycles and control the outputs of many actuators. Figure 3 illustrates the effect that this growing complexity has had on the physical characteristics of microcontrollers. Three generations of powertrain microcontroller are shown. In the space of three generations, the microcontroller has become around 100 times more powerful in terms of CPU throughput, the program memory (holding the algorithm) has grown 40 times bigger and the number of transistors on the chip has increased by a factor of 300. The powertrain application is by no means unique - many controller systems in the vehicle have kept pace with these developments and 32-bit RISC processors are being used for new generations of Airbag and ABS systems. Algorithm complexity is also leading to the widespread implementation of operating systems. Although most operating systems are still developed in-house by the application specialists, the industry will migrate very quickly towards standardization of the operating system and network management. The OSEK/VDX operating system has been adopted by many as the open standard (OSEK is a German acronym for 'Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahzeug'). This standard was developed specifically to decouple the application code (algorithm) from the network management tasks and avoid incompatibility problems between the application code and the hardware. It includes a standardized application programming interface, behavior and protocol. Implementation of OSEK/VDX should facilitate reusability and portability of software and predictable system behavior. It is expected that many automotive microcontrollers in the near future will be implemented with an OSEK operating system. Figure 3 - Automotive microcontroller complexity Smart nodes As well as the growth in electronic control systems and communications networks, which will lead to an increased number of microcontrollers in the vehicle, there will also be a growth in the number of sensors and actuators. In conventional systems sensors and actuators were connected directly to the appropriate electronic control unit, usually by a twisted pair. As the number of sensors and actuators increases, there are several problems, which are faced. Handling their interrupts or sampling their outputs, providing different interfaces for each sensor / actuator becomes problematic, as well as processing / sharing the (usually analog) information which is exchanged between the control unit and the sensor / actuator. As the cost of electronics is coming down and the need for simplification of such systems is increasing, it will become more common to implement smart sensors and actuators. A smart sensor / actuator need not include a microcontroller (but mostly will have a small CPU) and will be connected to the ECU on a bus system. Much of the growth in automotive microcontrollers, which is shown in Figure 1 will be a result of smart nodes. Today's smart nodes are usually composed of a package containing a microcontroller die, sensor die and sometimes an analog-interfacing die (depending on how much functionality is included on the sensor die). It is anticipated that it will be cost effective in the not-too-distant future to integrate MicroElectroMechanical sensors (MEMs) and microcontrollers on a single monolithic silicon chip. Such a concept for a pressure sensor is shown in Figure 4. The sensing element, analog interface and microcontroller functionality are all contained on a single silicon die. Figure 4 - Integrated single chip smart pressure sensor  Safety critical operation Microcontrollers have been at the heart of safety critical systems for many years. Almost all of the safety critical automotive systems in which they have been used have provided a fail-safe function. In the near future, there will be an added requirement for fault-tolerant microcontroller based systems. There is an important difference between fail-safe systems and fault-tolerant systems. Today's Antilock Braking Systems are fail-safe: if an electrical system error is detected, the ECU switches to a safe 'off' mode, allowing the foundation hydraulic brakes to operate without the faulty ABS system interfering. A fault-tolerant system must not only recognize that an electrical fault has occurred, but must continue to operate safely with the existing known fault. Antilock braking systems use redundancy to facilitate a fail-safe system. Typically the CPU at the heart of the system supervises the continual testing of all the major system components. The CPU can only validate these components however, if the CPU itself is known to be 'sane'. Hence a second, redundant CPU is used to validate the sanity of the first CPU. A redundant CPU can either be implemented as a second standalone microcontroller or as an error detection CPU with comparison logic on the same microcontroller. Emerging automotive applications such as Brake-by-wire and Steer-by-wire systems will not be satisfied by a fail-safe system; they will require a fault-tolerant solution, as a hydraulic back-up mode will not exist. Therefore if a fault is detected, the system must continue to operate safely in a 'limp home' mode. Although simple redundancy of components and a voting algorithm can be used, this is normally a very expensive solution (voting requires at least three CPUs). There has been an increasing amount of work done in the field of time-triggered communications protocols (such as TTP/C), which will be used to satisfy fault-tolerant automotive system requirements. A cost-effective microcontroller based control system, which provides fault-tolerance will require control modules (like a TTP/C controller) integrated with microcontrollers to support the new fault-tolerant communications systems. Microcontroller Technology Because of advanced system requirements such as increased communications, algorithm complexity, safety critical requirements and such like, microcontroller technology requirements will be impacted. CPU trends An effect of the increased throughput requirements driven by algorithm complexity is the requirement for very high performance, low cost CPUs. As well as providing a very high throughput and fast interrupt handling capabilities, the CPU must also be conducive to generating efficient dense code when a C compiler is used. As the CPU is now usually a relatively small area of the die with respect to memory arrays, if a CPU is designed in a high-level language friendly way, a significant amount of memory (and hence cost) can be saved. There is also a trend to use high-performance RISC CPUs in automotive microcontrollers in preference to the traditional CISC units. This trend will continue. Traditionally, what has set RISC apart from CISC is the ability to execute an instruction in a single clock cycle and the fact that RISC machines do not use microcode to decode instructions, but are hardwired. It has been argued that the vast majority of most software consists of very simple instructions. The philosophy of RISC is to produce processors that can execute these simple instructions (such as ADD, SUB, SHIFT, etc.) in one clock cycle. More complex instructions such as MUL and DIV were not available on early RISC processors. When an opcode is generated by a line of software in a CISC machine, this opcode is basically an address for a microcode memory (also sometimes called a 'control store') which points to a certain string of control bits that are applied to the execution unit (via a small amount of combinational control logic). These bits include many control signals to ensure that the execution unit performs the desired function. This microcode memory is a regularly structured array, which is straightforward to design and offers flexibility to the designer, allowing him to design the optimum microcode. A RISC processor does not have a microcode memory. Therefore the opcode, which is generated in software, is applied directly to a larger array of combinational control logic in order to generate all the appropriate signals to operate the execution unit. This is a more complex design, which results in a smaller silicon size (as there is no microcode memory) and usually faster operating speed. The distinction of single clock instructions for RISC only is becoming more vague as many RISC CPUs now include complex instructions which can take several cycles to execute. RISC processors only allow operations to be performed directly between registers in the CPU. This means that if we had two bytes in memory that we wanted to AND together, we would have to first load them into CPU registers. CISC machines would normally allow you to AND a user register with a location outside the programmers model. Memory trends The standard microcontroller memory types which have become established in automotive systems are ROM, EPROM and Flash EEPROM for program store, RAM for stack and scratch-pad memory, and byte erasable EEPROM for storage of calibration and security data. As Flash EEPROM is becoming more cost effective, it will ultimately replace ROM as the favored memory solution. Automobile manufacturers often wish to revise software in the field. Unless there is a method of reprogramming the memory array remotely, typically this problem requires the sealed ECU to be removed and replaced. This is a time-consuming and expensive process for the Automobile manufacturer, not to mention a greater inconvenience to the owner. Flash EEPROM provides the technology, which allows such field revisions. This system can be used for software upgrades as well as software revisions. It is now becoming more common for ECU suppliers to build generic platforms, which may have slightly different features, implemented in software. For example, some automobiles automatically adjust the side view mirrors (which turn to point to the rear wheels) when the vehicle is placed in reverse gear. This feature is implemented in software and feasibly could be offered as a 'software upgrade' in the after-sales market. Memory sizes for most automotive applications will continue to grow, leaving the CPU on the microcontroller occupying a relatively small portion of the chip. Figure 5 illustrates a die photograph of the M68HC912DG128, for use in automotive applications. The relative sizes of the memory modules and other microcontroller functions can be seen clearly on the photograph. Figure 5 - M68HC912DG128 Microcontroller  The microcontroller shown has 128K of Flash EEPROM memory in four 32K arrays. Each array can be bulk erased separately. Having only two arrays of 64K would reduce the die size but erasing the memory would not be as flexible. In addition, a 4K RAM is included and 2K of byte erasable EEPROM. Typically a ratio of 32:1 is considered appropriate between program memory and RAM on modern microcontrollers. Certain applications, which are RAM intensive may require more, although modern design techniques are usually helpful in estimating exact codesize requirements early in the design cycle. The memory system in future automotive microcontrollers may be enhanced in certain cases to allow simplified memory verification. In a safety critical system, it may be desirable to check that memory contents are stable and have not been corrupted during the course of operation. There are several techniques that can be implemented to validate memory contents, each having its own merits and problems. The most straightforward way is to implement a parity bit on the entire memory array. Whenever a byte is written to memory, a parity generator adds an extra bit and whenever a byte is read from memory a parity checker will ensure that a parity error has not occurred. Another scheme, which has been widely discussed, is the use of a Linear Feedback Shift Register to perform signature analysis on blocks of memory. Packaging trends It can no longer be assumed that automotive microcontrollers packaging requirements are conventional PCB mounted plastic / ceramic units. Processing is becoming distributed around the vehicle as dictated by the locations of sensors and actuators, and packaging requirements are changing accordingly. A mechatronic approach is now being taken for microcontroller packaging. Mechatronics is a discipline, which has arisen from a need to look at systems as a whole, rather than component parts, such as electrical/electronic engineering and mechanical engineering. It aims to bring about completely optimized systems by integrating the individual components of design into a process, rather than the traditional approach, which often yields a collection of electrical, mechanical and hydraulic subsystems interfaced together with a control unit. There is much opportunity for mechatronic technology to improve today's automobile systems. Figure 6 shows two approaches to an electronic motor controller. On the left, the electronic control circuit uses a number of different interconnect technologies including rivets, solder, surface mount devices and wire bonding to a silicon die. The diagram on the right is an example of a mechatronic solution where an electronic microsystem has been constructed using a multi-chip module and 'connectorized' for robust and efficient interfacing with a motor housing. This type of mechatronic system would usually have many less interconnections than the traditional solution. Both motor control circuits are connected to a bus via a plug. On a modern automobile, this interface is likely to be a communications bus, linking several motor control circuits (such as window lifters, seat positioners and mirrors). Figure 6 - Mechatronic motor solution  Noise reduction ECUs and all electronic components contained within are thoroughly tested to measure Electromagnetic Compatibility (EMC) performance. EMC is becoming a bigger issue for automobile manufacturers as the operating speed of electronic components is becoming faster (higher frequencies lead to increased electromagnetic emissions) and the number of ECUs, which could potentially affect each others operation is increasing. Worst-case, the result of an ECUs operation being corrupted by radio frequency emissions (from either another ECU or external source from the vehicle) could be a potential compromise on safety. Electromagnetic compatibility can be optimized by careful design of the integrated circuit and the printed circuit board. A system is considered electromagnetically compatible if it satisfied three criteria: · It does not cause interference with other systems · It is not susceptible to emissions from other systems · It does not generate interference with itself In recent times, the automobile manufacturers have been putting more pressure on the ECU suppliers to produce units with better EMC performance - this pressure has, in turn, been put on the semiconductor suppliers to produce more robust microcontrollers. At the integrated circuit design level, there are many considerations that can enhance the EMC performance of the design: Using less clocks and turning off clocks when not in use, reducing output power buffer drive, using multiple power and ground pins and reducing internal trace impedance on these pins, eliminating integrated charge pump circuitry and positioning high frequency signals next to a ground bus are all steps which are now taken to improve EMC. Power consumption Until only recently, low power consumption was never considered a priority requirement for automotive ECUs. This has changed on account of the number of systems, which are required to operate when the ignition is switched off. These systems would quickly drain the battery unless special attention was given to their power consumption. The door modules are a good example. These ECUs need to exist in a 'ready' mode permanently in order to recognize a signal from a 'Remote Keyless Entry' device. All automotive MCUs are now optimized for power consumption. This is mainly done by switching off the chip's internal clock source, when the chip is inactive. This also results in reduced noise emission. Power consumption is also a consideration for Airbag ECUs. Airbag ECUs need to function in the event that a crash situation disconnects the electrical power supply for the ECU. A large capacitor is normally used to ensure that under these circumstances, there is enough energy available to fire the bag(s). By careful design attention to power consumption requirements, the size of this capacitor may be reduced, thus reducing ECU cost. Airbag microcontrollers are often selected primarily by measuring maximum MCU performance while operating at a speed defined by a given power consumption limit. Integration All microcontrollers follow a roadmap of integration that has seen the feature sizes drop from several microns to about 0.5 um effective gate width, in today's state of the art devices. This feature size shrinkage is set to continue and will result in lower costs, higher operating speeds and an increased functionality of the chip. One of the challenges which offsets these benefits is the reduced operating voltage requirements (the smaller gate oxide cannot withstand the higher voltage). In order to function at 0.5 um, a 3.3v power supply is required for the CPU. Below 0.5 um will bring a further requirement for 1.8v power supply. This means that additional power supply capabilities of the system are required in order to take advantage of the integration technology advances of the microcontroller. For a number of years, mixed signal devices which include high voltage / high current capabilities have been produced for automotive applications. Mixed signal capable microcontrollers will continue to be developed where it is cost effective to do so and if it makes sense from a system partitioning perspective. Partitioning functions in the Electronic Control Unit (ECU) and satellite modules (sensors, actuators, other ECUs) is not always straightforward. The problem is multi-dimensional as functions may be implemented in different semiconductor technologies, as hardware or in software, and may include other considerations such as the physical location of the function. The first step is usually to isolate each function to be performed (like sampling a sensor output or driving a motor) and then examine each possible implementation. When all functions are identified and their inter-relationship understood, the lowest cost / most efficient solution may be determined. When re-partitioning any existing system, it is important to always look at basic functions rather than existing solutions. New technologies may be available which will allow a better implementation of that function. By using a new type of sensor which doesn't require costly interfacing, a cheaper solution may result. Perhaps the sensor can have a digital interface integrated which will allow the information to be shared on a common bus with other systems. The best solutions always result with close cooperation between semiconductor integration experts and systems experts. The semiconductor vendor is uniquely positioned to assist in partitioning the system. It is possible to integrate power functions onto microcontrollers, digital functions onto analog chips, signal conditioning and digital interfaces with MEMs sensors (i.e. accelerometers, pressure sensors, etc.), and many other combinations of these functions are possible. Software is an important element that must be considered too. As microcontroller bus speeds have increased enormously, it is no longer necessary to use complex hardware to off-load interrupts. The processor may be more than capable of handling these interrupts due to vastly increased bandwidth. Conversely, a great deal of bandwidth may be consumed by software, which can be replaced by minimal hardware. Figure 7 gives an example of a 'system chip', with various types of technology implemented on the same silicon. Figure 7 - System Chip The most highly integrated product is not necessarily the best product. When reduced cost is the sole motivation for integration, there will be a point on the curve, which determines the optimum level. Other motivations for increased integration may exist however, such as reduced chip-count/size, reduced power consumption, general simplification, increased reliability, etc. More highly integrated products also tend to have less generic appeal. This translates to reduced economies of scale and usually slightly higher costs. Often however, this additional cost is more than offset by a more competitive product in the market. Electronic Design Automation Future automotive microcontrollers will be impacted by changes in the design methodology, which is being adopted in the automotive electronics industry. There is a trend to take a systems engineering approach, which is an integrated design methodology incorporating electronic, mechanical, hydraulic and design for manufacturing considerations. Simulation, code generation, optimization and fast prototyping tools are now more commonly used in order to reduce time to market, generate more highly integrated designs, reduce costs and increase reliability. The modern automotive microcontroller must now be supported early in the cycle with software models that can be integrated into simulation environments. A conventional system design is illustrated in Figure 8. Figure 8 - Conventional system design The conventional system design process starts with abstracting a software and hardware specification from the systems specification. Both hardware and software are developed independently and are then integrated and tested/debugged. If a functional problem exists at this stage (as it often does), it is usually very difficult to redesign hardware, so it is most common that software fixes are developed as far as possible. The main problem with this methodology is that both the hardware and the software are being debugged at the same time, thus it is more difficult to determine the source of faults. It is estimated that over 50% of the entire development cycle is spent at this stage. Often, a new microcontroller design is undertaken as part of the 'develop hardware' effort. This design will usually take an existing CPU and existing peripheral functions (i.e. timers, serial communications, etc.) and integrate these together with the required memory arrays for the particular system. These memory arrays are based on the estimated software size, which is being developed independently, so are rarely efficient. Quite often, a new 'custom' peripheral is also developed for integration with the microcontroller. This could be a 'knock' detect module for a powertrain system or a wheel speed interface for an ABS system. In order to resolve the problems of optimizing a systems design, new software-based toolsets have been developed which allow alternative implementations to be evaluated rapidly. The new approach allows trade-offs to be made quickly and an efficient design to be generated with confidence that little or no problems will surface later. The new systems design process that is being adopted is illustrated in Figure 9. Figure 9 - Modern systems design methodology The control algorithm development is now usually a model-based operation. The algorithm is simulated on a workstation in an environment that simulates the behavior of the physical system. The algorithm can be tweaked and simulated in the model on an iterative basis until the algorithm development has been completed. The control algorithm model, usually mathematically based, is then processed using an Automatic Code Generation (ACG) tool that will provide a High Level Language file representative of the control strategy. This High Level Language can be compiled to run on any execution unit based system (such as a microcontroller). In order to verify the code, it is tested in a hardware environment by downloading the code to a rapid prototyping board, usually a very powerful array of processors/DSPs. The rapid prototyping board is connected to a hardware environment of inputs (sensors, serial communications links) and outputs (actuators) in order to verify the operation of the control algorithm. After the model-based algorithm development is complete, it is time to partition the hardware and software. Software tools are again used at the partitioning stage to simulate the system operating with different configurations of software and hardware. The goal is to understand the trade-offs involved in implementing different functions as either software routines or as a dedicated hardware block. For example, a routine that constantly services certain low-level interrupts which occur very frequently might best be implemented as an autonomous (or 'smart') peripheral on a microcontroller. The algorithm is run on a model of a CPU and peripheral modules can also be implemented as behavioral models. The outcome of the hardware/software co-design stage is to determine the final specification for the hardware. In the most part, the software will already exist and have been verified at this stage. The hardware requirements that are identified at this stage will be optimized to meet exactly the system requirements and a new microcontroller can be developed which suit the specification exactly. It is estimated that the overall development time required using the model-based development methodology can be around half of the time required for the conventional systems design methodology. The impact on the microcontroller is that that there will be a requirement for quality software models of not only the CPU but of the peripheral modules, which could be used in the system. The models will be required very early in the design cycle and its likely that there will be many different types of models required for use with different toolsets (i.e. Verilog, VHDL, C++). These models will someday be regarded as essential to the design process as a databook is considered today. Advanced automotive microcontrollers Probably the best example of a 'next generation' modern automotive microcontroller is the MPC555, which was designed for powertrain control and Intelligent Transportation Systems (ITS) applications. A block diagram of the MPC555 is shown in Figure 10. Figure 10 - MPC555 The MPC555 is based on the PowerPC architecture and is composed of over 6.7 million transistors, over 300 times the complexity of a microcontroller used in a comparable application a decade ago. The 32-Bit CPU includes multiple execution units and a floating point unit as well as supporting a Harvard architecture with separate load / store and instruction busses for simultaneous instruction fetching and data handling. The chip is well equipped with peripherals to interface with the rest of the system. There are 32 analogue inputs as well as 48 Timer Processor Unit (TPU) timer controlled input/output channels. Two CAN (Controller Area Network) serial communications interfaces are also included to provide multiplexed communications with other vehicular systems. The program memory is 448 Kbytes of Flash EEPROM with 26 Kbytes of RAM. Certain i/o structures have been added to the chip to accommodate 5v signals around the chip. Although the MPC555 has been developed for a 0.35 um manufacturing process, it is expected that the technology of other system components will develop more slowly and will still operate with a 5v power supply and signaling level. Conclusion This article has discussed the functions which next generation automotive microcontrollers will be required to handle, as well as the technology developments which are being established to provide the processing and ancillary performance needed. The growth in complexity of microcontroller based automotive systems has been enormous and this is set to continue. The next major challenge for microcontroller based automotive systems will be to optimize the efficiency of the controller and associated software by model-based development techniques, open architectures and reusability of hardware/software. Meeting these challenges will ensure that the perennial requirements of the industry are met: reduce cost, increase performance and reduce time to market. References 1. Automotive Electronics Handbook, Jurgen, R., McGraw-Hill, 1995. 2. Understanding Smart Sensors, Frank, R., Artech House, 1996. 3. Using Microprocessors and Microcomputers, Wray, W., Greenfield, J., Bannatyne, R., Prentice Hall, 1998. (ISBN 0-13-840406-2) 4. Noise Reduction Techniques in MCU-Based Systems and PCB's, Kobeissi, I., Motorola Application Note, Austin, Texas, 1997. 5. Measurement and Modeling of Boron Diffusion in Si and Strained Si (1-x), Ge (x) Epitaxial Layers During Thermal Annealing, Klein, K., Journal of Applied Physics, November 1993. 6. Hardware-Software Codesign Using Processor Synthesis, Kuttner, C., IEEE Design & Test of Computers, Fall 1996. 7. Brake-by-wire without Mechanical Backup by Using a TTP-Communication Network, Hedenetz, B., Belschner, R., Daimler-Benz AG, SAE Congress Proceedings, 1998. 8. Alternative Cars in the 21st Century, Riley, R. Q., SAE, 1994.

© 2009 Micro Control Journal. All rights reserved.

Using Servomotors with the PIC Microcontroller

Servomotors are used in most RC cars, boats, helecopters and planes. They are often used to control sensitive adjustments such as steering, but have many other uses in robotics and positioning control systems.

Servomotors are basically geared down dc motors with positional feedback control, allowing for accurate positioning of the rotor, with a range of 90 degrees. They can also be modified to allow for continuous rotation.

Servomotors have three wires; usually red, black and white. The red wire is for +VDC, the black for ground, and the white is for position control. This control signal is a variable-width pulse, which can be varied from 1 to 2 ms. The pulsewidth controls the rotor position.

A 1.0 ms pulse rotates the shaft all the way counter-clockwise. A 1.5 ms pulse puts the rotor at neutral (0 degrees), and a 2.0 ms pulse will position the shaft all the way clockwise. The pulse is sent to the servo at a frequency of approximately 50 Hz. The relationship between the pulsewidth and the rotor position can be seen in figure 1 (below).

Servo Motor Control with PIC16F84

This simple micro-control circuit controls a servo motor according to a 3-state switch. A servo motor acts as an actuator in 3 position. It has 3 wires, one for VCC, one for Ground and another one for position control. The last signal is a single pulse with variable width. The pulse width can vary between 1 and 2 mSec. An 1 mSec pulse width turns the motor axis in -45 degrees position. An 1.5 mSec pulse width turns the motor axis in 0 degree position. A 2 mSec pulse width turns the motor axis in +45 degrees position. The following source code has been written in PICBasic:

Symbol porta = 5
b3 = 150
start:
Peek porta,b0
If bit0 = 0 Then sweepl
If bit1 = 0 Then sweepr
Pulsout 0,b3
Pause 18
Goto start
sweepl:
b3 = b3 + 1
Pulsout 0,b3
Pause 18
If b3 > 200 Then hold1
Goto start
sweepr:
b3 = b3 – 1
Pulsout 0,b3
Pause 18
If b3 < 100 Then hold2
Goto start
hold1:
b3 = 200
Goto start
hold2:
b3 = 100
Goto start

Microcontroller At89c2051 (8051 family) Based Level Monitor

Microcontroller At89c2051 (8051 family) Based Level Monitor

In This post we will learn to developed a simple level gauge or level meter by using 8051 family micro-controller say at89c2051.
The circuit diagram and example c program written in keil c51 is attached here in this post for student understanding and knowledge sharing.

List of components used in this project:
1. The heart of the project as obvious is the microcontroller at89c2051.
2. LED bar graph display
3. Buzzer (siren)
4. Level Input probes (Transducer for level sensing)
5. Nand gated Opto-couplers
6. Transistor 2N2222 (NPN) General purpose transistors. You can use any available NPN transistor like c828 or c1383 etc
7. Crystal 12 Mhz
8. capacitors 33pf
9 LM 7805 voltage regulator IC (three PIN)
10 Relay to control a Motor , ON/OFF
Project Concept:
The present concept implements controlling of pump which pumps water from the sump (under-ground tank) to the overhead tank, using 8951 microcontroller. The control panel, i.e. the main control unit of the system which consists of the primary control switches, pump indicator, siren and level indicators. The visual example of how switches And the indicators can be placed as shown the figure.
As you can see in the above diagram, port 1 (P1.0 to P1.4) is exclusively used as an input port which takes the information regarding the water level in the sump or overhead tank.
Port 3 is used as output port which is connected to the indicator that indicates the water level in both the tanks 10 LEDs are connected with port P3 via P3.2 to P3.7, look the PIN P3.6 in at89c2051 is missing by default .
The programed logic in microcontroller gives the output which is connected to pump indicator, siren and the relay which controls the switching of the pump.
When the system is active and running, it indicates the water levels through bar graph LED in the tanks and it controls the working of the pump.
Besides the program logic and its functions, one important thing regard the level monitoring is its sensor.
In this project a self made sensor is used which is consist of only six metallic strips of 3 cm length. One strip is for DC power and other five strips are for input. When water reaches and touches any of the strip, the circuit is completed and respective optocoupler is activated which gives signal to microcontroller and correspond LED is switched ON. 
When all the strips are dipped in water (all probes are dipped in water) then siren or buzzer runs and motor is switched Off. This is simple level indicator logic and needs more modifications. I will post the updated logic after testing in real system.
The optocoupler is used to make the circuit safe from outside high signals. In this project a nand gated optocoupler is used. But you can use any general purpose optocoupler like L817 etc.
As circuit diagram tell us, we will need two different power supplies in this project. One power supply of 12v dc for the smooth running of microcontroller and peripheral components.
Second power supply of 12v Dc is used for input signal and optocouplers. 
For this i can suggest, that you can use a 12-0-12 transformer, it means a step down transformer having two secondary windings. Or other separate power supplies can be used. 
C-code of this project:
First line is to include the required file for registers of at89c2051. you can use reg51.h file.
//#include
sbit input1 = P1^0;
sbit input2 = P1^1;
sbit input3 = P1^2;
sbit input4 = P1^3;
sbit input5 = P1^4;
sbit indicator1 = P3^2;
sbit indicator2 = P3^3;
sbit indicator3 = P3^4;
sbit indicator4 = P3^5;
sbit indicator5 = P3^7;
sbit siron = P3^1;
sbit motor = P3^0;
main(){
P1 = 255;P3 = 255;motor = 0;siron = 0; 
while (1) { 
if(!input1) indicator1 = 0; else indicator1 = 1; 
if(!input2) indicator2 = 0; else indicator2 = 1; 
if(!input3) indicator3 = 0; else indicator3 = 1;
if(!input4) indicator4 = 0; else indicator4 = 1;
if(!input5) {indicator5 = 0; motor = 1; siron = 1;} 
else {indicator5 = 1;motor = 0; siron = 0; } } }
TAGS:-
8051 Project, 8051 projects,ADC0804,adc0808,adc0809,microcontroller projects, at89c51 projects, 8051 serial port communication,Level Measurement Instruments for Continuous Level Measurement with microcontroller 8051,Liquid Level Monitor,Manufacturer and designer of groundwater monitoring instrumentation ,water level sensor, water level testing, well depth monitor, water level monitor,flow, volume and level monitoring in storage vessels ,Level Sensor, Level Indicator or Liquid Level Sensor, Tank Gauge,ultrasonic liquid level monitoring,level sensors, level switches, level transmitters, level indicators and speed monitoring systems for process control ,Capacitance Level Sensor and Control Instruments,LHe or capacitance-based liquid level sensors, Level Monitoring. Sensors monitor fill levels of liquids and solids in large and small containers,data acquisition and control project based on microcontroller 8051 to build level monitoring system.