MULTI-SENSOR NAVIGATION SYSTEM FOR AN
MULTI-SENSOR NAVIGATION SYSTEM FORAN AUTONOMOUS HELICOPTERJoerg S. Dittrich, Eric N. Johnson, Georgia Institute of Technology, Atlanta, GeorgiaAbstractIntroductionAutonomous Unmanned Aerial Vehicles(UAVs) require avionics systems that enable themto maintain a stable attitude and to follow a desiredflight path. This paper considers the design anddevelopment of such an avionics system thatprovides navigational and terrain information to theflight computer of a rotorcraft UAV.This document introduces the applied designand integration methodology used to develop anavionics system that provides navigational andterrain data to the flight computer of a VerticalTake-Off and Landing Unmanned Aerial Vehicle(VTOL UAV). The process includes both thedesign of flight hardware and a software packagethat interfaces sensors, flight computer, andoperator. The new Georgia Tech GT-Max designserves as a specific example. A more detaileddescription of this system can be found in [1].The process includes the design and testing offlight hardware and software that interprets sensordata. The paper provides an overview of a specificimplementation of the approach: the GTMaxtestbed developed at the Georgia Institute ofTechnology UAV Research Facility. Its availablepayload and performance allows for a variety ofonboard sensors, supports reconfiguration, and hasthe capability to demonstrate aggressive maneuversunder complex and changing mission scenarios.First, the hardware selection and integrationprocess will be outlined. The design factors includeweight, electromagnetic interference, vibration,flexibility, hardware integration, redundancy,maintainability, and growth potential. Sensor datafrom multiple sources is filtered andintegrated/fused into a navigation solution. Beforeactual flight tests take place, sensor interfaces andnavigation algorithms are verified to ensure properfunctioning. By using software emulated sensordata and a simulation model of the aircraft, thealgorithms are first tested. The same test is thenrepeated on the actual flight computer by feedingsimulated sensor data from a computer that isrunning a simulation model of the vehicle andsensors. The navigation system is then tested on theground in an automobile, and then on the helicopter.Ground and flight-test data showing sensor andnavigation system performance are compared tosimulation results.Design RequirementsSeveral ongoing research programs at GeorgiaTech require a VTOL UAV that has the capabilityto execute aggressive maneuvers as well as toperform during complex and changing missionscenarios. Earlier flight tests and were conducted onan X-Cell radio-controlled helicopter UAV, with abasic avionics system that allowed autonomousflight [2]. Current and future work utilizes a moresophisticated testbed. This new UAV, named theGTMax, is based on a Yamaha R-Max industrialhelicopter, which has six times the avionics payloadcapability of the X-Cell.The most important design criteria for the newtestbed are good performance and maximum systemflexibility, i.e. ability to reconfigure as needed.Good navigation system performance (high rate,high accuracy) allows for higher performancecontrol, which is important for aggressivemaneuvers.While many rotorcraft UAV avionic designshave the system weight as their main designconstraint, it is secondary to the system flexibilityin the GTMax design. With current commercial-offthe-shelf components it is relatively easy to design avery effective system within the payload allowanceof the R-Max aircraft. Hence, efforts were1
concentrated to ease hardware reconfiguration andallow for considerable future system growth. Thisimplies modularity, very good accessibility of allcomponents, and common interface standards.Independent from these software designefforts, the hardware needs to be packaged andinterfaced (hardware wiring) with attention placedon vibration isolation, electromagnetic interference,and accessibility.Design ProcessOnce all these tasks have been completed, thesimulation of the UAV system can be taken to thenext level by integrating hardware components intothe simulation loop (Hardware-In-The-Loop).Autonomous Unmanned Aerial Vehicles(UAVs) require avionics systems that enable themto maintain a stable attitude and follow desiredtrajectories. Such an avionics package is comprisedof sensor, computer, and data link hardware as wellas software to guide, navigate, and control thevehicle. Figure 1 depicts the realization flow for acomplete UAV avionics system.Figure 1. Design Process DiagramHardware selection is a critical design tradeoff in deciding which sensor and supportingelectronics are needed to fulfill the designspecification.Sensor data from multiple sources can befiltered and integrated into a navigation solution.The navigation software will provide thatfunctionality, interfacing with the sensor systems.The other two main tasks are the developmentof the flight control software for the vehicle and theimplementation of a simulation model of theaircraft. This paper will focus on the developmentand testing of the navigation hardware/softwaresystem.The sensor interface software and navigationalgorithms are validated by using software emulatedsensor data and a simulation model of the aircraft(Software-In-The-Loop, SITL).Hardware Selection and IntegrationThe synthesis of the avionics hardware is atrade-off evaluation like any other design process.An optimal design solution is sought, by finding thebest compromise to satisfy the design requirements.The factors considered for hardware selection andintegration include: PerformanceWeightElectromagnetic Interference (EMI)PowerVibrationHardware Integration IssuesFlexibilityRedundancyMaintainabilityGrowth PotentialCostKey issues for the GTMax were the vehicleperformance, flexibility, maintainability and growthpotential.GTMax Hardware SelectionThe Yamaha R-Max is an industrial remotelycontrolled helicopter, which has been developed asan agricultural spraying aircraft for small fields.The most important features for its modification toa UAV are its payload, endurance and powersystem. A 12V DC generator is included in theairframe and powers all systems through a bufferbattery. This gives it the capability to power theavionics as long as fuel is available, as opposed tomany smaller UAVs that are required to carryheavy battery packs to power the avionics. A stockvehicle has been retrofitted with interface ports tothe control system and a taller landing gear. ThreeRS-232 serial ports, which can be accessed on the2
back of the control system box, comprise theinterface to this external hardware.Similar sized Yamaha helicopters (R-50 andR-Max) have been instrumented for autonomousflight before [3], [4], [5]. The GTMax, however,uses multiple sensors to implement an avionicssystem that has an emphasis on capability for laterextensions. Two different bus interfaces are used tointerconnect the components: RS-232 serial bus forsensor data and 100 Mbit Ethernet bus forcommunication between computers. The selectedcomponents are: JUMPTec Adastra VNS-786 embeddedPCDiamond Systems Emerald-MM PC/104serial port extensionInertial Sciences ISIS-IMU, primaryinertial sensor,Yamaha YACS IMU, built-in, secondaryinertial sensor,NovAtel Millenium RT-2 DifferentialGPS receiver,Honeywell HMR-2300 Magnetometer,Custom-built Sonar with Polaroid 6500ranging modules,Roke Manor MRA Mk IV RadarAltimeter,Yamaha Vehicle Telemetry, built-in,Aironet 4800 11Mbps Wireless EthernetLinkFreeWave DGR-115 Wireless SerialData LinkD-Link DSS-5 Ethernet SwitchPlacing attention to modularity is a commonsolution to growth potential and reconfigurationrequirements. System modularity was achieved byusing few different and widely available interfacesystems and by introducing a modular enclosuresystem. The modules themselves are not directlyconnected by a proprietary interface bus, but areinterconnected with patch cables in order topreserve maximum flexibility. By using thisapproach of independent metal enclosures for theavionics components, it also becomes easier toensure sufficient EMI suppression between thecomponents, as the enclosures provide someshielding capability. A commercial-off-the-shelfrack-mountable enclosure system has been selectedto house all avionics components except themagnetometer, sonar, power system, and theantennas. This way, the avionics can be installedinto an airframe-mounted rack, which allows easyremoval in case work needs to be conducted on asingle module.Figure 2 shows the modules in the rack. Theselected hardware has been split up into 5 modulesas follows: Flight Computer Module, GPS Module,Data Link Module, IMU/Radar Module, andAuxiliary/Payload Module. In addition to theserack-mounted devices, a sonar and a magnetometerassembly are mounted on the tail boom. A powerpanel with separate circuit breakers for each devicedistributes on-board or external power (12V DC) tothe consuming modules.An airframe-mounted generator, buffered byan on-board battery, powers all airborne elements.In order to achieve a good system bandwidth thecomputer (i.e. autopilot) is installed on the airframe,also enabling the vehicle to operate independentlyfrom a ground station if required or in case of a datalink loss.Hardware IntegrationFlexibility has been defined to be a key featureof the GT-Max UAV. Hence, one has to focus on anintelligent integration of the system components toachieve that goal.Figure 2. Avionics Module RackEach module has self-contained powerregulation, ventilation, and EMI shielding, whichallows for configuration changes without the needfor redesigning the overall system. The avionics3
rack is installed inside a custom aluminumenclosure that is hard-mounted on the airframebelow the fuselage. The power panel is mounted onthe back of this box.features individual shielding of all signal lines toensure maximum operational safety.Special attention has been placed on theaccessibility of the hardware interfaces, such thatthe planned hardware-in-the-loop simulations andother changes to the setup can be performed withminimum effort. Therefore, the side panels of theavionics box can be removed easily to provideaccess to the front and back panels of the equipmentmodules. The front panels of the modules comprisethe user interface to the system with externalequipment interfaces (monitor, floppy drive,laptop) and status LEDs covered by a transparentLexan side plate, while the back panels host thecommunication and power ports.The UAV system is designed to allow forseveral system setups. The most common setup forground and flight tests is shown in Figure 4. Thewireless data links are setup redundantly, (i.e. thesame data is sent and received by both). If one linkfails the other one continues to exchange messages.A tail boom mount, similar in shape to ahorizontal stabilizer fin, provides installation pointsfor the sonar assembly, the magnetometer, and theGPS receiver antenna. It is attached by using aVelcro strap, providing a firm fit and leaving thestructure of the boom unchanged. Figure 3 showsthe assembled UAV with all avionics installed.Overall System SetupHigher data rates and the use of the TCP/IPprotocol, offer additional benefits to the 802.11bAironet link. The operating system on the flightcomputer has been equipped with an FTP-Serverwhich enables the ground operator to downloadrecorded flight data while the vehicle is still inflight. Also a VxWorks target server connectionbetween the development environment and the onboard computer is run to update and execute theflight code remotely via that TCP/IP connection.Figure 4. System SetupFigure 3. GT-Max UAVAll interfaces are located on the back of eachmodule, where they are interconnected with patchcables. This design allows for easy configurationchanges, if necessary. The flight computer ports canbe directly connected to an off-board computer for ahardware-in-the-loop simulation while the computeris mounted on the airframe.All components are interconnected andpowered by an aviation-quality wiring harness,In order to conduct a flight test, the vehicleavionics are powered by an external power sourceas long as the engine is not running to avoiddraining the on-board battery. Compiled flight codeis uploaded from the ground station onto the flightcomputer and executed remotely. The groundcontrol station (GCS) software connects to thevehicle and displays status. After an IMU warm-upperiod of approximately three minutes, thenavigation filter is initialized by a ground stationoperator command. When everything and allmembers on the test team are prepared for theflight, the engine is started and the avionics powersource is switched from external to on-board power,allowing flight for up to approximately one hour,limited by on-board fuel capacity.4
Computer controlled flight can be enabled bytoggling a switch on the safety pilot transmitter andsetting a register value in the servo controlcommand structure. In this manner, the UAV canonly be switched into automatic control when boththe safety pilot and the GCS operator agree to doso. In case of a safety pilot transmitter failure, thecomputer will switch to computer control when thecomputer is up and ready, otherwise the Yamahacontrol system will activate a failsafe mode.High rate on-board data recording isindependent from data logging on the GCS. It canbe started and stopped by the GCS operator and willgenerate a file in the volatile flight computer RAM.This file has to be copied to the on-board flash driveor, more conveniently, downloaded to the GCS oranother computer in the LAN via FTP. Data is notcurrently written to the flash drive while the flightcode is running because of the additional systemload that would be generated.Navigation Software And SimulationDue to its multiple sensors, the software thatprovides sensor fusion (navigation) for a UAVavionics system has many elements. The sensordrivers and navigation algorithms, that provide thestate estimate to the flight controller, need to beverified and tested thoroughly.Developments in the VTOL UAV field [6]show that the use of simulation promises the bestresults in catching errors early. Therefore, asimulation model of the aircraft and its sensors isused to conduct the necessary tests before actualflight tests. The sensor emulators are designed withan error model with parameters for noise and bias.Models of the aircraft actuators are also included inthe simulation.Once this capability is achieved, severalsimulation configurations are possible, e.g. only insoftware or including elements of the flighthardware such as the flight computer executing itsnavigation functions.Software Architecture and SimulationEnvironmentSoftware for the flight hardware and theground control station are essential modules thatneed to be implemented. As discussed above, thetool of simulation is used to test the system. Thisrequires that the flight code and the ground controlcode should be able to run in the simulationenvironment. The simulation tool ESim is used as abasis for all code developed as a part of this project.ESim has a graphical user interface (GUI) withnumerous visualization functions. All datastructures of the developed project can be viewedand reinitialized in a real-time data browserwindow. A 3-D representation of the simulatedvehicle can be displayed in a computer-generatedscene. Every variable in the simulation can beplotted over time or any other variable and saved asa Matlab data file for further evaluation.Furthermore, ESim has a scripting language tosimplify configuration and operation.ESim can be set up for a piloted simulation ofthe aircraft, a software-in-the-loop or hardware-inthe-loop simulation. ESim features many dataplotting and recording functions for any variablevalues within the simulation.As the graphics output is based on the OpenGLstandard and communication routines areimplemented for Windows NT and POSIX basedsystems, ESim can run on a variety of desktop andlaptop computers. Our team currently operatesESim under Windows 2000 and Linux.Flight CodeNavigation filter algorithms, flight controlroutines, and sensor and actuator drivers comprisethe flight software. Unlike the desktop or laptopcomputers for simulation and ground interface, theflight computer is operated under the WindriverVxWorks real-time operating system. Navigationfilter updates are triggered by new IMU data at 100Hz, while the flight control code and the actuatorsare updated at every other time step (50 Hz).The code can be compiled and executed as astand-alone VxWorks application for the flighthardware or it can be integrated into the ESimsimulation environment.In its current configuration the flight code hasone main loop that is executed at theaforementioned 100 Hz. During every loop, eachsensor port is polled for new data to ensure that the5
latest data is always used in the following filteringalgorithm.Ground Control Station SoftwareThe ground control station software providesthe main user interface for the operator, whichrequires similar visualization capabilities as withina simulation of the system. Therefore ESim can alsobe configured to perform these tasks.The ground station screen (see Figure 5) showsa 3-D representation of the vehicle in computergenerated scenery, that supports a trajectory andactual flight path plotting.An annunciator panel summarizes the systemstatus and warns in case of component failure.Sensor FusionData from the flight sensors is fused into onenavigation solution in a state estimator. AnExtended Kalman Filtering approach is used tointegrate data from the navigation sensorequipment. The GTMax platform adds twoaltimeters with different range and accuracy and amagnetometer to a DGPS-aided Inertial NavigationSystem as shown in Figure 6. Propagated IMU-Data(treated as continuous) is fused with discreteupdates from the other sensors.States utilized in the navigation filter include:position, velocity, attitude (quaternion),accelerometer and gyro biases, and the terrainheight, totaling 17 states. GPS data is converted intoa Cartesian north-east-down coordinate system as aflat earth is assumed. IMU propagation is based onrigid-body dynamics.Figure 6. Navigation FilterA detailed description of the navigation filterdesign can be found in [1] and [7].Figure 5. GCS ScreenshotA command prompt gives the operator theability to execute command scripts to trigger onboard functions including navigation systeminitialization, data recording, and flight maneuvers.An important feature derived from the ESim datastructure management, is the request of datastructures from the aircraft. A “get” commandenables the ground crew to retrieve any datastructure from the helicopter while in flight, displayit in the ESim browser window, modify it if needed,and eventually upload it again with a “send”command.Whenever, new data is available from one ofthe supporting sensors, an optimal discrete update isapplied to the state estimate and the covariancematrix. GPS measurements are compensated forsignal latency. State updates for position andvelocity, triggered by GPS data, are appliedindependently, as the measurements of these valueshave a different latency.Data from the magnetometer is evaluatedalong all three axes and described as a normalizedfield line vector. However, the data is only appliedto correct for heading drift. This is done byprojecting the magnetic field vector on the NorthEast plane, using the last vehicle attitude estimate toeliminate the effects of magnetic dip.The sonar and radar altimeters are used to dodiscrete updates on the vertical position and theterrain height. It is assumed that the sensor hasenough beam width to identify the closest distance6
to the ground, which is ideally straight down.Therefore, no additional corrections are appliedwhen the vehicle is not in level attitude.Software-In-The-Loop (SITL) SimulationThe first test of the algorithms is performedwithin the simulation. Among many possiblesetups, a full simulation of the whole UAV systemwith all components is done in order to testnavigation, flight controls, and sensor and actuatordrivers in one step, without the necessity ofemploying actual flight hardware. Configurationchanges are only performed within the software.Additionally, this configuration enables multipledevelopers, as there is no need to run software testson dedicated hardware that is only accessible byone developer at a time. This of course implies thatit is also possible to test new code at times when theon-board hardware is being disassembled or evennon-existent.The way the sensors are emulated can bedescribed as follows. State data from the dynamicmodel is transformed into measurements of thosevalues each sensor actually measures. Coordinatetransformations and shifts are applied in reverse.Then, noise and biases are added to those pseudomeasurements. Eventually the simulated values areused to fill the binary data structures of the sensorscommunication protocol and can be sent to thesensor drivers in the simulation.The output of the vehicle model is assumed tobe the state of a real helicopter. The goal of thenavigation system is to estimate the vehicle state asaccurately as possible. If the errors in the sensor andactuator models are set to zero, the estimate of thenavigation filter should exactly equal the state ofthe model. When noise and biases are introducedand increased the navigation solution willdeteriorate. A filter should have a reasonabletracking error within the estimated errors for thesensors. When the first flight test data is available,the simulation can be repeated with more accurateinformation about actual sensor performance.Additionally, sensor data playback functionality isbuilt into the simulator, such that prerecordedsensor data from actual flight can be fed into thenavigation filter. This proves to be very useful totest the function of the navigation filter.ESim provides a visualization interface asfollows. Two 3-D visualizations of the helicopterare displayed in the same window using differentcolors, one for the "truth" (the model state), and onefor the navigation estimate. Discrepancies betweenthe two solutions can be easily visualized in thatway. Of course, there is the additional option ofplotting the desired values for comparison.Hardware-In-The-Loop (HITL) SimulationDuring the HITL simulation, the flightsoftware runs on the actual on-board computerwhile all simulations run on a separate desktop orlaptop computer (see Figure 7). Instead of thesensors, I/O ports of the Simulation Computer areplugged into the flight computer (RS-232 Nullmodem cables for the R-Max system). The samegoes for the actuators in this example. The result ofthis setup is that the on-board computer effectively“thinks” it is flying the vehicle, as all of itsconfiguration/data flow is identical to anautonomous flight setup. Most importantly, thissimulation will show if the selected on-boardhardware is capable of executing the flight softwarein real-time, i.e. it shows if all components canactually run fast enough.Figure 7. Hardware-In-The-Loop SetupUsing the software architecture approachdescribed above, the same software as for the SITLsimulation is used. The only difference is that theon-board part of the code is compiled for the flightoperating system and uploaded onto the flightcomputer. The simulation interface with thevisualization and data recording stays totallyidentical. High bandwidth data recording, however,has to be done on the flight computer, controlled bythe GCS software. It is possible to do a completeHITL simulation on three separate computers: the7
flight computer, the simulation computer, and GCScomputer. For practicality reasons, the simulationand GCS code is usually executed on the samemachine. This is possible because the datastructures for these tasks are independentlyorganized under the ESim environment.As the back of the avionics box on thehelicopter is easily accessible, the serialconnections on the flight computer can beunplugged as required and connected to thesimulation computer. A “partial” HITL simulationis also possible. For example, generated GPS datacan be fed into the flight computer for tests in flightconfiguration without GPS availability, e.g. whenthe aircraft is located indoors. This flexibility wasimportant because of the GTMax mission as aresearch vehicle.Alternatively to the direct serial port hookup, acommunication protocol has been implemented thatallows serial data to be sent via Ethernet. This isdone by emulating serial port behavior and thenrerouting the data stream over a TCP/IP socketconnection. Hence, HITL simulations can beconducted while the avionics are wired for flight,which is especially useful for last minute functionchecks before a flight test. However, experiencewith this method showed a bandwidth limitationwhen applied to replace all serial hardware links tothe simulation computer.Test ResultsDuring the initial development of the UAVsystem, it was tested on the ground and in the airbefore autonomous flight was done. This sectiondescribes the order and method that was used toevaluate the system.SimulationThe navigation system was tested within thediscussed simulation architecture (SITL and HITL).Tests included automatic hover, high-speedmaneuvers and pirouettes, as well as remotelypiloted flight (with a human pilot in the simulationloop). Special attention was placed to the systembehavior in case of GPS signal loss, step changes inIMU biases, and in- and out-of-range situations ofthe sonar altimeter. When the simulated system metexpectations, tests with the actual sensor hardwarewould then have to prove the validity of thesimulation.Ground TestsThe GTMax navigation package was firstsuccessfully tested in a basic configuration, whilemounted on a pickup truck. To improve the systemperformance further ground tests of the navigationsystem with enabled differential GPS have beenconducted. As a result of the testing, it was possibleto experimentally identify the latency of the GPSreceiver and update the corresponding values in thenavigation filter settings. When set properly, theGPS corrections should be relatively small during adynamic response.In order to test the EMI shielding of all systemcomponents, the assembled UAV was placed on theflight field. When all systems were powered up onexternal and on-board (with engine running) powereverything worked as expected. No malfunctionswere noted. Special attention was placed on thefunction of the data links, especially as the safetypilot link is essential for safe operation in case ofany system failures during the tests.A first engine run test with the avionicsmounted on the airframe indicated sufficientvibration isolation. All on-board electronics workedproperly while sensor data was recorded at 100 Hz.GPS and magnetometer data was almost identical toengine-off measurements while the IMU raw datashowed significant vibration. However, whenintegrating that data it delivered smooth and stableposition, velocity, and attitude solutions. Thisbasically means, that there is no significant aliasingof high frequency IMU input, (i.e. the unit'sresolution lies above the vibration frequencies ofthe avionics box). Thus, it is possible to propagatethe IMU data and use it for navigation.The ground vibration test is also the firstchance to analyze the raw sensor data for themagnitude of sensor noise, which has to be knownfor optimal navigation filter function. First values,that can be determined in this test, can immediatelyreplace initially assumed navigation filter settingsand can be used to improve the sensor models in thesimulation for more realistic SITL and HITLresults.8
Flight TestSeveral flights were conducted to test theperformance of the navigation system and to recordsensor data in flight. Although the navigationperformance recorded on the first flight test day waspoor, the recorded sensor raw data was used toresolve these problems. By using the data playbackfeature of the simulator, it was possible to rerun thesensor data through a modified navigation filter.Based on that flight data, the process noise of theterrain height was adjusted. Additionally, it wasdiscovered that bias errors in the pitch and roll ofthe magnetometer were causing erroneousaccelerometer bias states. Therefore, themagnetometer data processing was changed from athree-axis attitude update to the present one channelheading correction. Comparing navigation filteroutput before and after the modifications, the databecame more consistent.When the navigation system was optimized tothe point where it would output acceptable statedata, first tests of the flight controller wereconducted. Although the flight controller was notdiscussed in this document, its testing wassupported by the overall development conceptpresented here.The controller was tested by closing only oneloop at a time. While the heading and altitude holdmodes worked right away, the control loops forpitch and roll did not have enough authority tostabilize the helicopter in hover. By using the onboard data recording functionality of the flightsoftware, the flight could be reconstructed and thecontroller behavior analyzed and improved for thenext flight test. Similar to the tuning of thenavigation filter, the data playback in the simulationwas a key feature to improve system behaviorwithout having to have additional flight tests.ConclusionsThe navigation system of the GTMax yieldedvery good performance, close to the predictionsfrom simulation. By using simulation and sensordata playback, expensive flight test time to developthe navigation system was reduced. The utilizationof a software architecture, which is identical forSITL/HITL simulation, flight code and GroundControl Station, also contributed to significant timesavings in the system development.Besides the software benefits, the hardwareintegration appr
Diamond Systems Emerald-MM PC/104 serial port extension Inertial Sciences ISIS-IMU, primary inertial sensor, Yamaha YACS IMU, built-in, secondary inertial sensor, NovAtel Millenium RT-2 Differential GPS receiver, Honeywell HMR-2300 Magnetometer, Custom-built Sonar with Polaroid 6500 ranging modules,
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
ZigBee, Z-Wave, Wi -SUN : . temperature sensor, humidity sensor, rain sensor, water level sensor, bath water level sensor, bath heating status sensor, water leak sensor, water overflow sensor, fire sensor, cigarette smoke sensor, CO2 sensor, gas s
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid
LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .
WM132382 D 93 SENSOR & 2 SCREWS KIT, contains SENSOR 131856 WM132484 B 100 SENSOR & 2 SCREWS KIT, contains SENSOR 131272 WM132736 D 88 SENSOR & HARNESS, contains SENSOR 131779 WM132737 D 100 SENSOR & 2 SCREWS KIT, contains SENSOR 131779 WM132739 D 100 SENSOR & 2 SCREWS KIT, contains SENSOR 132445 WM147BC D 18 RELAY VLV-H.P.-N.C., #WM111526
Navigation Systems 13.1 Introduction 13.2 Coordinate Frames 13.3 Categories of Navigation 13.4 Dead Reckoning 13.5 Radio Navigation 13.6 Celestial Navigation 13.7 Map-Matching Navigation 13.8 Navigation Software 13.9 Design Trade-Offs 13.1 Introduction Navigation is the determination of the position and velocity of the mass center of a moving .
