Control System Architecture

Requirements

The RAMA system is intended as a cheap (less than 3000eur components price), reasonably lightweight (approx. 1.5kg) and compact (330x160x65mm) universal control system, which could be fitted to any kind of UAV (either a rotorcraft or a fixed-wing aircraft). As an academic project, it is designed for research applications and it is not meant as an “out-of-the-shelf product for everybody”. This implies many of its assets and limitations.

It was foreseen that RAMA will have to be easily modifiable, both hardware and software wise, and should be able to accommodate relatively sophisticated algorithms and broad telemetry bandwidth. Therefore, it is designed as a modular system with high degree of independence between the nodes, so that each of them could be modified without affecting the rest of the system very much. This also contributes to its safety (see section Control System Safety for details), but on the other hand makes it more complicated and increases it’s power consumption, size and mass.

RAMA’s on-board computers are very much over-designed in the sense of computing power, for the reasons mentioned above. This allows for previously unforeseeable extensions of its control algorithms, but increases the power demand. This is not regarded as a problem for an experimental system with limited mission duration (it is still able to run up to 4 hours on internal power).

The wireless telemetry link is very simple and offers up to 54Mbps bit rate, but is not reliable enough for critical tasks and works only on a short range and within direct line of sight. Hence, it is no problem to transmit very large data streams and to extend the telemetry as needed. The disadvantages are not limiting for an experimental system. Naturally, the telemetry could only be used for non-critical data transfers.

RAMA could possibly operate fully autonomously, however, it lacks the necessary redundancy and some mandatory avionic equipment (such as a radar transponder and TCAS), required by UAV regulations for autonomous UAVs in most countries. It is not suitable nor intended for autonomous long-range missions. This is due to the strict budget, weight, size and power consumption design constraints. Nevertheless, it perfectly fulfills all the requirements for a semi-autonomous experimental small-UAV autopilot and can be safely operated under the direct supervision of a human pilot.

Once fully functional, RAMA could provide a fully stabilized flying platform for any kind of payload. This has many advantages over the wholly manually controlled vehicle, as it was proven many times that a properly designed autopilot is superior to a trained human pilot when it comes to fine stabilization or precise trajectory tracking. An autopilot also significantly reduces the workload of the human pilot and reduces the possibility of human error.

Overview

control_system_block_diagram.jpg

RAMA consists of the Airborne Part (AP) and the Ground Station (GS), comprised of a laptop computer and a RC (Radio Control) transmitter. The laptop is used only to visualize and record the on-line telemetry of the vehicle, while a model RC set is used to issue commands to the airborne control system, and also allows one to re-take full manual control of the drone in case of a control system failure. The airborne part of the system is designed as a networked hierarchical distributed system. It consists of several basically independent functional blocks, interconnected via the Vehicle Bus (VB), as can be seen from the block diagram. Those blocks are the Navigation Unit (NU) (comprised of sensors and their management), Main Control Computer (MCC), Wireless Data Communication Unit (WDCU), two Wireless Control Units (WCU) (for redundancy) and the Servo Control Unit (SCU).

This structure allows a separate design and testing of each component, also simplifying any possible future extensions of the system. The nodes may be added or exchanged without affecting the rest of the system very much, as all nodes are interconnected only via a single interface and a single medium, the Vehicle Bus. Of course, integration work and testing must follow any modification, but it is simplified by a great deal due to the modular structure of the system.

The core member of the RAMA system is the Main Control Computer (MCC), where the control and communication algorithms run. The Main Control Computer is connected to the Ground Station via the Wireless Data Communication Unit (WDCU), which is currently an IEEE 802.11g WiFi module. The WiFi communication is non-critical, as it is used only for the telemetry. The commands for the autopilot are issued via the Wireless Control Units (WCU) (currently a model RC set), which is much more reliable and has a lot wider range than WiFi. RAMA is able to operate without the data communication with the Ground Station (GS), as it serves only for the on-line system monitoring and telemetry recording.

The sensor data are acquired and pre-processed by the Navigation Unit (NU). This unit includes the Inertial Measurement Unit (IMU), Three-Axis Magnetometer (TAM), Global Positioning System Receiver (GPS) and the Data Acquisition Module (DAM). All sensors are connected to the DAM, the purpose of which is to synchronously sample all the data, pre-process it (filtering, unit conversion, etc.) and send it to other control system nodes. DAM also provides the Time Synchronization Message (TSM) for the rest of the system, the purpose of which is to synchronize all system nodes.

The actuators (the servomotors driving the control surfaces of the vehicle) are controlled by the Servo Control Unit (SCU). All actuators and both Wireless Control Units are connected to this node. Its purpose is to control the actuators, sample their positions and also to sample the control sticks’ movement on the RC transmitter (provided by the signals from the Wireless Control Units).

The Controller Area Network (CAN) 2.0b, running at 1Mbps, is used as the Vehicle Bus. Its utilization is approx. 10%, so there are no problems with extensive data packet delays. Proper real-time behavior is also ensured by the packet priorities and non-destructive arbitration. The overall performance of the bus and mean/extreme data latencies were evaluated statistically.

The Wireless Data Communication Unit (WDCU) is a standard embedded WiFi device, configured as an access point. The Ground Station laptop is the client - multiple Ground Stations are allowed, the RAMA system has an telemetry server and is able to broadcast data to multiple clients simultaneously. The communication data rate is 54Mbps, which is more than enough for the telemetry, as the data packets are only some 500 bytes long and are sent 32 times per second. This results in approximately 2% of bus utilization, so there are no concerns with the real-time issues; the telemetry is a soft real-time task anyway. The communication is encrypted, using the standard 128-bit WEP algorithm.

Two separate batteries are used to power the system during flight. The first battery, called the Avionics Battery (AVB), serves as a power supply for on-board avionics. It is of Lithium-Polymer chemistry, capacity 4Ah, configuration 3 cells serial (nominal voltage is therefore 11.1V). The other battery is called the Actuator Battery (ACB) and serves as a power supply for the actuators. It is of Nickel-Cadmium chemistry, capacity 2.4Ah, 4 cells serial (4.8V nominal voltage). These two batteries form the Internal Power Supply (IPS) of the RAMA system. On the ground, RAMA can be supplied by a stabilized power source. Both batteries can be charged in-system using a service connector, without the need to disconnect and remove them.

The use of separate power sources for the actuators and the rest of the system is necessary because of electromagnetic interference, mainly affecting the sensors. This solution also allows one to incorporate a power supply redundancy for emergency scenarios in the future (see section Power Failure Modes for details). Obvious setback of this solution is the additional mass it represents.

Main Control Computer

mcc.jpg

BOA 5200 embedded computing platform, from the Analogue & Micro company, is serving as the Main Control Computer (MCC). It utilizes the Linux Operating System with 2.6.xx core (it does not make much sense to mention exact kernel revision, because it is being updated as the time goes).

BOA 5200 is based on the MPC 5200B microprocessor, running at 300MHz. It is a decent computing platform, featuring 64MB of SDRAM, up to 32MB of internal NAND FLASH memory and a lot of peripherals (2x CAN controller, 10/100 Ethernet, USB, RS-232 and others). With a small PCB footprint (62x62mm) and relatively low-power consumption (approx. 3W), it forms an ideal computing platform for the RAMA system, able to execute complex control algorithms in real-time. A custom-made motherboard, hosting a stabilized power supply, bus drivers and connectors, was developed by our contractor Mr. Miloslav Žižka to support the BOA 5200 module.

Wireless Data Communication Unit

wdcu.jpgwifi_antenna.jpg

Wireless Data Communication Unit (WDCU) provides the data connection between the Main Control Computer (MCC) and the Ground Station (GS). To reduce development time, off-the-shelf IEEE 802.11g (WiFi) device is used for this purpose. This solution proved to be feasible, as the WiFi link works very well within the ranges we use to fly, especially because there is a clear line of sight between the stations.

AirLive WL-5470AP Access Point is used as the WDCU, but any other IEEE 802.11g device could be used instead. It was only slightly adapted according our needs; Original housing was dismantled, the PCB was mechanically reinforced using protective lacquer coat and a polyethylene glue (see the section Mechanical Outfit and Housing for more details), and the antenna and the power supply connectors were changed. The reverse-SMA antenna connector is now attached to a 300mm long coaxial cable, to allow for external antenna mounting between the tail boom support rods. The power supply connector was replaced by RAMA’s standard power connectors.

Wireless Control Unit

wcu.jpg

The Wireless Control Unit (WCU) is a standard model RC equipment. In the Manual Control Mode (MCM), it allows the human pilot to control the UAV in the same manner as an ordinary RC model; when Automatic Control Mode (ACM) is engaged, the WCU is used to transmit commands to the Airborne Part (AP) of the RAMA control system. In the current state of development, the positions of the control sticks of the RC transmitter set reference for the rate controllers in the ACM.

Spektrum DX-7 RC set is currently used, working in the 2.4GHz range. A 35MHz system was used earlier, but was abandoned and upgraded in order to increase reliability. The DX-7 system is redundant (two separate receivers are used, working on different frequency channels and set to orthogonal antenna polarization) and utilizes a digital encoding of the transmitted signal, secured by CRC (Cyclic Redundancy Check). It is much less prone to undesired electromagnetic interferences than the previous “traditional” RC system was.

Navigation Unit

Introduction

The Navigation Unit (NU) consists of four parts - the Data Acquisition Module (DAM), the Inertial Measurement Unit (IMU), the Global Positioning System (GPS) receiver an the Three-Axis Magnetometer (TAM).

Data Acquisition Module

dam.jpg

The Data Acquisition Module (DAM) is a simple embedded computer, built around the Philips LPC 2119 MCU (local copy of the datasheet can be found here), utilizing the ARM7DTMI core. It was designed by a friend of mine and my most honorable work-mate Marek Peca for his own project, dealing with construction of a two-leg humanoid (well, maybe half-humanoid, heh… =) follow the link and see this technical marvel yourself, its definitely worth… 8-O:-)) walking robot named SPEJBL. When milling around his worktable once, I realized that his SPEJBL-ARM module, originally designed as a servo controller for SPEJBL, would fit nicely into my RAMA system in the role of the DAM. And so we made a deal (I took one of his SPEJBL-ARM modules and gave him a little coconut lolly in reward =) - it was a bargain, I say… ;-)), and the DAM was born.

Main assets of the SPEJBL-ARM board are its simplicity, low power consumption (approx. 10mA@12V), compact size (37x28x6,5mm) and negligible weight. Aside from the MCU, there are only the CAN-driver and power regulator installed (and some LEDs). The MCU is driven at 60MHz - there is a 10MHz crystal installed on the board, and the internal PLL of the MCU is set to 6x. The LE50CD power regulator provides 5V for the Philips PCA82C250T CAN driver, and the 3.3V and 1.8V voltages for the MCU are provided by the TPS73HD318 multi-purpose circuit. It also serves as a voltage watchdog. Aside from that, only the obvious blocking capacitors and pull-up resistors are present. The IO pins of the MCU operate at 3.3V levels, but are 5V tolerant. The JTAG interface is not used; the software can be programmed either to the internal RAM or FLASH using ISP (In-System Programming) via the UART0 line.

The SPEJBL-ARM circuitry scheme, assembly diagram, manufacturing data for the PCB (Printed Circuit Board) and PCB design files can be downloaded here (registration required).

Connector pinout

connector/pad number meaning note
K1 Power in ground connected to the outer pad, + to inner pad
K2 CAN CAN_L connected to the outer pad, CAN_H to inner pad
K3/1 RESET
K3/2 ISPSEL
K41/1 PWM2/SSEL0/EINT2/P0.7
K41/2 PWM4/TxD1/P0.8
K41/3 PWM6/RxD1/EINT3/P0.9
K41/4 AIN0/CAP0.1/MAT0.1/P0.27
K41/5 AIN2/CAP0.3/MAT0.3/P0.29
K42/1 PWM1/TxD0/P0.0
K42/2 PWM3/RxD0/EINT0/P0.1
K42/3 PWM5/CAP1.3/P0.21
K42/4 AIN1/CAP0.2/MAT0.2/P0.28
K42/5 AIN3/CAP0.0/EINT3/P0.30
K8 power out connected with K1
K9/1 analog ground inner pad
K9/2 analog branch of 3.3V outer pad

List of materials

part number type/value package note
C1, C2 capacitor 56p SMD 0805 ceramic
C99 capacitor SMD 0805 not used
C101, C102, C103 capacitor 4u7 SMD A tantal
C104 capacitor 2u2 (1u) SMD 1206 ceramic
C501, C502, C503, C504, C505, C506, C507 capacitor 100n SMD 0805 ceramic
R1, R7, R8 resistor 10k SMD 0805
R2 resistor 0R SMD 0805
R3, R4, R5, R6 resistor 470R SMD 0805
R9 resistor SMD 0805 not used
D1, D2, D3, D4 diode LED R,Y,G,B SMD 0805
X1 crystal 10MHz HCX-6FA Hosonic (Spezial)
U1 LPC2119FBD64 LQFP64 Philips (Spoerle)
U2 PCA82C250T SO8
U3 TPS73HD318 TSSOP28 TI (Spoerle)
U4 LE50CD SO8
K1, K2 connector PS 25/2G
K3, K41, K42, K8, K9 connector soldering pads K41/2,3 PSH02-02WG; K42/1,2 PSH02-02PG

Inertial Measurement Unit

imu.jpg

The Inertial Measurement Unit (IMU) is connected to the UART0 (pins K42/1,2) of the DAM. MICRO-ISU BP-3010 unit is used. It is a handy little unit, measuring just 35x22x12mm and weighing tiny 30g, with 0.5W power consumption, containing 3 accelerometers an 3 gyroscopes, providing accelerations and angular rates in all 3 vehicle axes. Measurement ranges are +-10g / +-300°/s @ 64Hz sampling rate. The data are provided via a serial link in TTL levels, so the IMU can be connected directly to the DAM.

The IMU is soldered to a simple PCB containing the 78M05 power regulator and a power filter (a set of capacitors with a self-induction coil). Besides, only some pull-ups, a power blocking capacitor and a RESET protective circuitry (two anti-parallel diodes to dissipate voltage pulses and a small filtration capacitor) are employed. Circuitry scheme, PCB manufacturing data, assembly diagram and design project files of the IMU board may be obtained here (registration required).

This device proved to be barely sufficient; the 64Hz sampling rate is very much “at the edge”, especially for the yaw control of a rotorcraft. Relatively low sampling rate caused many headaches with low-level stabilizers (see section Yaw Rate Control) and moreover, the device also turned out to be very much vibration-sensitive, exhibiting some rather odd behavior under flight conditions (see section Inertial Measurement Issues for details). It will be replaced by Analog Devices’ ADIS 16350 in the future, which promises better results.

Connector pinout

connector/pad number meaning note
J1/1 IMU data Tx (out) pull-up
J1/2 IMU data Rx (in) pull-up
J1/3 IMU reset (GND active) pull-up
J1/4 Power filtered +12V out LC filter
J1/5 Power +5V out LC filter
J1/6 GND
J2/1 GND
J2/2 Power in +12V

List of materials

part number type/value package note
C1 capacitor 330n SMD 1206 ceramic
C2 capacitor 10n SMD 0805 ceramic
C3 capacitor 1n SMD 0805 ceramic
C4 capacitor 470p SMD 0805 ceramic
C5 capacitor 2u2 (1u) SMD 1206 ceramic
C6 capacitor 4n7 SMD 0805 ceramic
R1 resistor 4k7 SMD 0805
R2, R3 resistor 10k SMD 0805
L1 self-induction coil 68nH SMD 0805
D1 diode BYD17D SOD87
D2 2x anti-parallel diode BAV99 SOT23
U1 MICRO-ISU BP-3010 DIP24 Bec-nav (http://www.becnav.co.uk)
U2 78M05 DPAK
J1 connector PSH02-06WG pin 1 rectangular
J2 connector round 2mm power-in cables

Global Positioning System Receiver

gps.jpg

The Global Positioning System (GPS) receiver is connected to the UART1 (pins K41/2,3) of the DAM. Garmin GPS 18-LVC receiver is used. It is an OEM GPS module with integrated antenna and WAAS (Wide Area Augmentation System) capability. The GPS provides current geographical position (latitude and longitude), as well as other data – such as height above sea level, velocity, estimated position error, etc. The data are sampled at 1Hz rate and sent to the DAM using a serial link.

The GPS UART data-out line is decoupled optically, using the PC817 photocoupler. To better form the output signal coming from the photocoupler, the 74LS04 TTL negator is being used. This module is not ideal for this application, as it proved to be rather sensitive to the rotor blades, and consequently had to be positioned far at the tail boom, causing mechanical problems with the UAV. It should be also replaced by some better device in the future.

Because of EMC problems (see section EMC Issues), the GPS receiver had to be galvanically separated from the rest of the system. This is done by the Decoupling Unit (DU).

The power lines are decoupled using the FDD03-12S1 DC-DC converter. The output power lines are filtered, using a bifilar self-induction coil (purpose-made, 17 coils on the Amidon FT37-43 ferrite toroid), a capacitor set and a self-induction coil again.

The circuitry scheme of the DU is available here (registration required), but the PCB was not yet designed; at this moment, only one prototype was built using the universal PCB.

Original connector, which was provided with the GPS 18-LVC, was cut off and was substituted by PFH02-04 connector for practical reasons. The pinout of this new connector is noted in the table below. Some of the cables leading out of the GPS receiver are left unconnected, as they are not used. The GPS 18-LVC is supposed to be connected to the J2 connector of the DU.

GPS 18-LVC connector pinout

connector/pad number meaning note
J/1 GND + remote power on/off + shielding black + yellow + shielding cables
J/2 Port 1 data in blue cable
J/3 Port 1 data out white cable
J/4 Power in +12V red cable

DU connector pinout

connector/pad number meaning note
J1/1 Power in +12V from IMU module
J1/2 GND
J1/3 Not Connected
J1/4 Data Out to DAM (decoupled)
J1/5 Power in +5V from IMU module
J2/1 GPS power out (GND) decoupled
J2/2 Not Connected
J2/3 GPS RS-232 Tx
J2/4 GPS power out (+12V) decoupled

List of materials

part number type/value package note
C1 capacitor 4u7/100V tantal
C2 capacitor 10u/16V tantal
C3, C10 capacitor 100n ceramic
C4 capacitor 1n ceramic
C5 capacitor 560p ceramic
C6 capacitor 470p ceramic
C7 capacitor 63p ceramic
C8 capacitor 56p ceramic
C9 capacitor 22p ceramic
R1 resistor 100R
R2 resistor 1k
L1 bifilar coil ferrite toroid FT37-47 17 coils
L2 self-induction ferrite toroid coil 22uH
U1 FDD03-12S1
U2 PC817
U3 74LS04
J1 connector PSH02-05PG
J2 connector PSH02-04PG

Three-Axis Magnetometer

tam.jpg

Honeywell HMC 2003 Three-Axis Magnetometer is measuring the magnetic field intensity components in each vehicle axis. The sampling rate is 512Hz. A motherboard had to be designed for this sensor, accommodating the power filtration and the degaussing and amplifying circuitry. The degaussing circuitry is designed according manufacturer’s reference solution, published in the datasheet. Delon voltage multiplier is used to obtain required 20V from the 12.6-10V, provided by the Avionics Battery (AVB). Linear operational amplifiers are used to provide additive offset and amplification of the output signals (y=k.x+q). First-order low-pass filters are accommodated as a simple anti-aliasing measure to suppress the high-frequency noise.

Circuitry scheme, PCB manufacturing data, assembly diagram and design project files of the TAM motherboard may be obtained here (registration required).

Local copies of the IRF7105 MOSFET transistor and the TLC272 operational amplifier datasheets are also available.

Servo Control Unit

scu.jpg

The Servo Control Unit (SCU) serves to control the actuators (i.e. servomotors) and, conveniently enough, it also measures both battery voltages. It is a simple, purpose-developed embedded computer, built around the Renesas H8S/2638F MCU. The SCU was designed by Ota Herm, my former graduate student, as his master project. It is the most crucial element of the RAMA system, as its failure would result in one or more actuators being out of control, with obvious grave consequences.

The SCU is connected to the Wireless Control Unit (WCU) (the RC receiver), the servomotors, and the Vehicle Bus (VB). Also, both internal power sources (Avionics Battery - AVB, as well as Actuator Battery - ACB) are connected to the SCU. Basically, the SCU can operate in two modes; either in the Automatic or in the Manual Control Mode. In the Automatic Control Mode (ACM), the signals from the WCU are read and sent to the MCC (Main Control Computer), and the signals for the servomotors are generated by the SCU, according the commands from the MCC. In the Manual Control Mode (MCM), the signals from the RC receiver are read and sent to the MCC, and also sent directly to the actuators. Therefore, should the rest of the RAMA system fail and only the SCU would prevail, it is still possible to maintain manual control.

The mode switching is controlled by one of the input RC channels (channel 7), connected to the WCU. Therefore, it is completely independent on the rest of the RAMA. Hence, it is always possible to switch back to the MCM, even if the rest of the system would be dead. The mode switching cannot be affected by the MCC, or any other node, in any way. When the mode switch occurs, the MCC is informed by a message sent by the SCU.

The SCU was designed as simple as possible. It has 7 input channels, compatible with standard RC signals, and 6 servo outputs. The input channel no. 7 is reserved for mode switching, while the other channels may be associated arbitrarily. In our case, the channel 1 is used for the carburetor servo, channel 2 for the roll cyclic servo, channel 3 for the pitch cyclic servo, channel 4 for the tail rotor servo and channel 5 for the collective servo. Channel 6 is not being used. Except that, the SCU has 3 UART channels (channel 1 serves as a diagnostic terminal, channel 2 is used for the firmware downloading, and channel 3 is unused), 2 CAN channels (channel 1 is connected to the Vehicle Bus, channel 2 is unused), an external watchdog (voltage & time), (optional) EEPROM memory, and a power regulator & filter.

The actuators are operated and their respective positions are sampled at 50Hz, which proved barely enough, especially for the yaw control (see section Yaw Rate Control).

Let us now briefly describe the SCU circuitry. The Renesas H8S/2638F MCU is running at 20MHz (10MHz crystal is used, but an internal PLL multiplies that by a factor of 2). The RESET signal is controlled by the MAX1232ESA circuit, which serves as a combined time & voltage watchdog. Philips PCA82C250T CAN drivers are used to provide the CAN bus connection. Because the MCU is not equipped with internal EEPROM, an external 93C46 serial EEPROM can be (optionally) connected to it. Currently, it is not being used by the software, and therefore may be omitted. All I/O pins of the SCU are protected against high-voltage spikes by a pair of diodes.

The 78M05 power regulator is used to provide the 5V supply. The AVB input is filtered by a set of capacitors and a self-induction coil. The ACB is also filtered in a similar way, but a self-induction bifilar toroid coil is being used, despite its greater dimensions and weight, instead of a simple SMD self-induction coil. The AVB and ACB grounds are connected by the R43 (0Ω) resistor, which serves as a bridge. A self-induction coil might be used instead; in our case, it did not help very much to dissipate the noise induced into the power lines. Also, small (approx. 10Ω) resistor might be tried out. Both AVB and ACB positive lines are connected (via resistance voltage dividers) to the A/D converter of the MCU (to allow for battery voltage measurements).

The SCU circuitry scheme, PCB manufacturing data, assembly diagram and design project files may be downloaded here (registration required).

servosignal.jpg

Standard RC servos are controlled by variable width pulses, varying from 1ms to 2ms, with 20ms period. The meaning of the signal is shown in the picture above. Digital Servos may use much shorter period, up to 4ms.

Connector pinout

connector/pad number meaning note
J1,J4,J6,J8,J10,J12,J13/1 RC signal in to RC receiver
J1,J4,J6,J8,J10,J12,J13/2 APS power out (+) to RC receiver
J1,J4,J6,J8,J10,J12,J13/3 APS power out (GND) to RC receiver
J3,J5,J7,J9,J11,J14/1 RC signal out to servomotors
J3,J5,J7,J9,J11,J14/2 APS power out (+) to servomotors
J3,J5,J7,J9,J11,J14/3 APS power out (GND) to servomotors
J15/1 not connected
J15/2 APS power in (+) to APS battery
J15/3 APS power in (GND) to APS battery
J2/1 EPS power GND
J2/2,3,4,5,6,7 I/O unused
J2/8 EPS power +
J18,J20,J21,J22 jumpers see the table below for jumper description
J19,J23,J24/1 EPS power + UART 1, 2, 3
J19,J23,J24/2 RxD UART 1, 2, 3
J19,J23,J24/3 TxD UART 1, 2, 3
J19,J23,J24/4 EPS power GND UART 1, 2, 3
J25,J26/1 CANH CAN 1, 2
J25,J26/2 CANL CAN 1, 2
J27/1 EPS power in (+) to EPS battery
J27/2 EPS power in (GND) to EPS battery

Jumper description

Jumper number meaning note
J18 watchdog RESET signal Should be shortened in normal operation; open when loading firmware (to prevent watchdog from causing MCU reset).
J20 watchdog refresh signal Should be shortened in normal operation; open to force the MCU reset.
J21 FWE (Flash Write Enable) Should be shortened in normal operation; open when loading firmware. After reset, the bootloader would be started when J21 is opened.
J22 MD2 (Mode 2) Should be opened in normal operation; short when loading new bootloader (into a brand new MCU for example). For more information, see the Servo control unit software section.

List of materials

part number type/value package note
C1, C2, C3, C4, C5, C6, C7, C11, C12, C17, C21, C22, C23, C24, C25, C26 capacitor 100n SMD 1206 ceramic
C8, C9 capacitor 15p SMD 1206 ceramic
C10 capacitor 470p SMD 1206 ceramic
C13 capacitor 330n SMD 1206 ceramic
C14 capacitor 47n SMD 1206 ceramic
C15, C27 capacitor 10n SMD 1206 ceramic
C16, C28 capacitor 1n SMD 1206 ceramic
C18, C19, C20 capacitor 47u/10V SMD D tantal
C29 capacitor 560p SMD 1206 ceramic
C30 capacitor 68p SMD 1206 ceramic
C31 capacitor 22p SMD 1206 ceramic
R1, R21, R40, R41, R42 resistor 820R SMD 1206
R2, R3, R4, R5, R6, R7, R10, R11, R12, R13, R14, R15, R20, R22, R26, R27 resistor 6k8 SMD 1206
R16, R17, R18, R19 resistor 8k2 SMD 1206
R23, R24, R28, R29, R30, R31, R32, R33, R36, R37, R46, R48 resistor 10k SMD 1206
R25 resistor 3k3 SMD 1206
R34, R35 resistor 120R SMD 1206 optional; CAN terminators
R38, R39, R43 resistor 0R SMD 1206
R44 resistor 4k7 SMD 1206
R45,R47,R49,R51 resistor ? SMD 1206 not used; voltage dividers for currently unused A/D inputs
R50 resistor 5k1 SMD 1206
L1 self-induction coil 68nH SMD 0805
T1 self-induction bifilar coil FT37-43 / 7 coils toroid FT37-43
D1, D12 diode LED red SMD 1206
D2 diode LED green SMD 1206
D3, D4, D5, D6, D7, D13, D14, D15, D16, D17, D18, D19, D20, D21, D22, D23, D24, D25, D26, D30, D31, D32, D33 diode BAV99 SOT23 anti-parallel diode pair
D10, D9 diode LED orange SMD 1206
D11 diode BYD17D SOD87
Y1 crystal 10MHz HC49U/S
U1 HD64F2638F FP-128B
U2 93C46 SO8 optional; currently unused
U3 MAX1232ESA SO8
U4, U5 PCA82C250T SO8
U7 78M05 DPAK
J1, J4, J6, J8, J10, J12, J13 connector soldering pads servo cables 600mm female end
J2 connector soldering pads currently unused
J3, J5, J7, J9, J11, J14 connector soldering pads servo cables 600mm male end
J15 connector soldering pads ACB power in - power cables with 2mm round power connectors (+ female, - male)
J18, J20, J21, J22 connector jumper
J19, J23, J24 connector PSH02-04WG
J25, J26 connector PSH02-02WG
J27 connector soldering pads AVB power in - power cables with 2mm round power connectors (+ female, - male)

Mechanical Outfit and Housing

This section describes the mechanical construction of the Printed Circuit Boards (PCBs), wiring harnesses, housing and mating of the RAMA system to the carrier vehicle. The most important consideration, which has to be taken into account when designing the UAV avionics (from a mechanical point of view), are airframe vibrations. Another aspects include operating temperature ranges, moisture, possible FOD (Foreign Object Debris) hazards and crash resistance. The last one is especially important quality for experimental systems =).

stack_1_level.jpgstack_2_level.jpg

Mechanical vibrations could seriously compromise reliability of improperly designed or installed hardware. The weakest points, most prone to mechanical wear, are usually connectors and wire harnesses. The connectors must be small and light, yet robust enough to withstand the strain experienced under the flight conditions. It is important to use connectors with multiple points of contact and wide contact area, which are the most contributing factors to the connector’s longevity and reliability. It is necessary to safe the connectors against accidental disconnection; in our case, it is done by application of a polyethylene glue.

It is better to use connectors with crimped pins if possible; if the leads must be soldered to the connector pins, it is important to not allow any bends in the vicinity of the soldered joint, as the wire tends to loose its elasticity due to the soldering, and might develop a crack over the time. Any exposed joints must be treated properly, usually with a heat shrinking tube.

Wire harnesses must be fastened properly but not too tightly, in order to prevent excessive strain on the wires. It is important to use sleeves, especially at attachment points or points of contact between the harness and the vehicle body. This prevents excessive wear of the wire insulation.

In the RAMA system, the backbone power wiring is made of special silicone-coated heavy duty cables and the power switches are redundant (two parallel switches are used). This renders a total power failure very improbable.

The PCBs must be mechanically robust, resistant to humidity and FODs, and also fulfill desired operating temperature range. It is wise to use at least industry-grade parts (temperature ranges from -40 to +85°C) to satisfy the last requirement. Generally speaking, semiconductors are more prone to higher temperatures and better tolerate the low ones. Resistors are usually sturdy and do not represent a problem, whereas capacitors (especially electrolytes) do not tolerate high temperatures for a prolonged time and too low temperatures either. It is wise not to use electrolytes at all if possible. Meaning of the “too high” and “too low” depends on the part’s grade, but generally speaking (for common main-stream capacitors), “too low” can be interpreted as below -10°C and “too high” as above +70°C.

foam1.jpgfoam2.jpg

In RAMA, all PCBs were protected with a lacquer coat initially. This coat serves as a mechanical and moisture protection and also protects the PCB from conductive FODs floating around, which could possibly cause a short circuit. Heavy parts (such as heat sinks or large coils) must be either screwed down or glued, using a polyethylene glue. It is important to secure bolted joints either by some appropriate sealant, or to use self-sealing screws, to prevent them from becoming loose due to the vibrations. The PCBs are mounted to its housing either using rubber shock-absorbers or secured using a thick double-adhesive foam tape, which also serves as a damper.

The PCB protection described above proved to work well enough under normal flight conditions, but was rather insufficient in case of a crash. Since several electronic boards were lost due to the accidents, the crash protection was gradually improved and the final version evolved into the PCBs being completely coated with a thick polyethylene coating and the housing filled with multiple layers of foam rubber, as can be seen in the pictures around. The least expensive parts (such as the WDCU) are deemed “expendable” and form a sort of a “crash zone”, in order to improve protection of the more expensive parts. This “ultimate” solution proved to be particularly sturdy, and no piece of electronics was lost in a crash ever since its introduction. The Electronic Container internals can be seen in the photographs above.

The housing and mating to the vehicle depends heavily on specific UAV type. In our case, the bulk of the RAMA system is located in an aluminum case, called the Electronic Container (EC). It is a simple box, made of 0.6mm thick aluminum plate, mounted between the landing gear skids of the carrier helicopter and mated to the vehicle using cable ties. Rubber dampers are used between the EC and the airframe, in order to suppress vibration transfer and to de-tune possible resonance.

The mechanical drawing of the EC can be downloaded here (registration required).

ec.jpg

The GPS receiver is located far at the tailboom in order to clear the main rotor blades, which would otherwise obscure its signal reception. This is not ideal from the mechanical point of view, because the mass of the GPS receiver, located at the end of the tailboom, forms a mechanical resonator and could easily work as a resonance amplifier. It is important to mount the GPS receiver using some dampers and also to properly tune the tail boom support rods to mitigate this problem.

Both batteries are located at the very front of the helicopter, to compensate for the Centre of Gravity (CG) shift, caused by the mass of the GPS receiver so far back. The CG position is of vital importance and must be maintained. The sensors, both IMU and TAM, are located as close to the CG as practically possible, because any offset of the sensors from the CG position would cause discrepancy in the navigation algorithms and would have to be compensated. If the offset is small enough, it can be neglected in the navigation algorithms.

Both IMU and TAM are fastened using a double-adhesive foam tape, serving as a vibration damper. The shape and thickness of the tape is not arbitrary, but has to be determined experimentally, in order to provide the best possible damping. Improperly designed mounting of those parts could lead to a serious measurement deterioration. The TAM has to be statically compensated to account for magnetic parts of the airframe, affecting its measurements.

Problems and Solutions

Couple of long-term hardware-related problems, worth mentioning, were encountered among many others during the hardware design and development process. The first of them was caused by mechanical vibrations affecting the IMU measurements, the second was related to Electromagnetic Compatibility (EMC), and the third plagued the Three-Axis Magnetometer (TAM).

Inertial Measurement Issues

This problem was related to mechanical vibrations of the UAV airframe, strongly affecting the IMU measurements and leading to a rather odd IMU behavior. Let us at first briefly describe the origin and character of these vibrations. The level and frequency spectrum of airframe vibrations are dependent on many things; mainly on the UAV type (fixed-wing aircraft or rotorcraft) and the propulsion system (combustion or electric).

The rotorcraft tend to vibrate more and in much broader frequency spectrum than fixed-wing aircraft. They are also much more prone to catching resonance. The character of the vibrations is mainly related to the construction of the rotor head, tail rotor drive, tail boom construction and payload assembly. There are many rotating parts and any disbalance, however slight, could cause a lot of problems. It is therefore very important to precisely balance the main and tail rotor blades (both their weight and the Center of Gravity (CG) location) and the flybar paddles. This is not sufficient though - the rest of the airframe had to be mechanically de-tuned to avoid any unwanted resonance around the normal working point. This working point (and also the frequency spectrum of the vibrations) is determined by the main rotor speed, which is directly proportional to the engine rpm. This speed is kept constant during the flight, as explained in section Effects of the Rotor Speed.

The highest frequency and also the most “hard” vibrations are induced by a combustion engine. The frequency of these vibrations can be higher than the Nyquist frequency of the sampling and have the most adverse effects, especially on the inertial sensors (gyroscopes and accelerometers). Their measurements must be filtered mechanically or electrically (still in the analog part of the sensor), to avoid their leakage into the lower frequency parts of the spectrum, due to the aliasing. These problems can be mostly avoided when using electrical propulsion.

weird.jpg

In our case, the main rotor speed is around 1800 Revolutions Per Minute (RPM), which is approx. 30Hz. This is uncomfortably close to the Nyquist frequency of the sampling (the sampling rate is 64Hz) and therefore forms an aliasing hazard. Moreover, the engine revs 18000RPM, which is 300Hz and therefore much higher than half of the sampling rate too. The datasheet of the BP3010 IMU device does not explicitly state whether the device has any internal anti-aliasing filters, but even in the case it does, they do not seem to work very well. The leakage of the high-frequency noise into the lower-frequency portions of the spectrum was experienced, but not only that. At particular vibration amplitudes, the device experienced a sudden and very significant change in the sensor offsets, meaning that - for example - a gyroscope reading would suddenly go off by one radian per second, or an accelerometer reading by one g. The affected sensor would still be operational, but its measurement would be significantly shifted (as shown in the figure). This problem affected the accelerometers and gyroscopes alike, and it was discovered that this is an amplitude-related, rather than frequency-related, issue.

This was a very serious problem, affecting mainly the roll gyroscope under the flight conditions, and lead to several in-flight emergencies when a roll gyroscope measurement suddenly shifted and caused the control system to compensate, falsely believing that the vehicle was rolling - and putting it itself into an undesired roll. To make the things even worse, this error condition was undetectable by the control system, because the offset would not change suddenly in one sample, but would rather grow over several samples. Hence, it could not be distinguished from a proper measurement in any way, as it was well within the measurement limits, and did not violate the gradient rule either. This condition is extremely unpleasant for the human pilot - the helicopter would happily fly around, and all of sudden it would start rolling violently, without any previous warning. The only way out was to disengage the ACM (Automatic Control Mode) immediately, enter the MCM (Manual Control Mode), and recover the vehicle flying manually (if there was enough time for that).

This condition was reproduced and thoroughly investigated at a vibration table and was extensively consulted with the BP3010 manufacturer. It was determined that an internal analog integrator, used in the device for analog averaging of the measurements between the sampling points, was most likely to blame. It was also found why the roll measurement was affected in flight; it was because the IMU housing is not symmetrical and have the smallest moment of inertia in the roll, making it prone to vibrate more in this particular direction. However, there was no way how to solve this issue “internally”, within the device itself. Because this was unacceptable, as well as the aliasing problem described above, a solution had to be found for both. The only way would be to mechanically isolate the device from excessive vibrations, both amplitude and frequency wise. A mass damper was developed as a solution to both problems. The IMU is mounted to a 200g lead plate (the seismic mass), which significantly increases (and equalizes) its inertia in all directions, and this plate is mounted to the airframe using a double-adhesive foam tape, serving as the flexible part of the damper. It involved a lot of experiments to fine-tune the damper to work properly, but a feasible solution was ultimately found. The mass damper is visible in the photo of the IMU in section Inertial Measurement Unit.

EMC Issues

du.jpg

The second most notable hardware development problem was indirectly related to the GPS receiver, the root cause being the EMC (Electromagnetic Compatibility). In its early incarnation, RAMA had no GPS and the whole control system was contained inside the EC (Electronic Container). The then-used WCU (Wireless Control Unit), i.e. a 35MHz RC receiver, was located outside and far from the EC, in the nose of the helicopter. As later experience showed, this was a very fortunate situation, for the EC shielded the lurking EMC horrors within. Once the GPS receiver was added, it was discovered that it has to be mounted on the very tip of the tailboom, in order to clear the main rotor blades, which were causing signal blurring. Naturally, a signal and power cable had to be routed to the receiver, and that (relatively long) cable was, as was discovered later, serving as a perfect antenna for the electromagnetic noise, emitted by the on-board computers through the power lines. The genie was released out of the bottle (or the EC, in our case) and caused a mayhem in the WCU, obstructing the 35MHz communication badly. This was fortunately discovered in the course of the Flight Readiness Test prior to a flight test, but no simple solution was found immediately.

Somewhat semi-permanent cure was devised through a complete galvanic decoupling of the GPS receiver. This was not as easy as it might seem, for the receiver has to be supplied from the same power source as the rest of the system (a separate battery, serving solely for the GPS receiver, was rejected as impractical). After some research and a lot of experiments, the Decoupling Unit (DU) was designed (it was described in section Global Positioning System Receiver). Its purpose is to completely decouple the GPS signal lines as well as the power lines.

This solution helped, but proved to be only semi-permanent, just until the point where other system parts began to migrate from the overcrowded EC to other parts of the airframe. The DAM (Data Acquisition Module), along with the IMU, had to be moved out of the EC once the TAM (Three-Axis Magnetometer) was added, because it would not work inside the box and it was desirable to have the IMU and TAM as close as possible (because any non-negligible offset would make the navigation algorithms more complicated). It is also practical to have the DAM in the direct vicinity of both sensors, in order to keep the analog signal lines from the TAM as short as possible. This revived the same problem again, as the non-decoupled power wiring popped again out of the EC. Because it was impractical to decouple the whole Navigation Unit (NU), and because the 2.4GHz model RC systems were becoming available at the time (which are much more technologically advanced in other aspects too - they offer the redundancy the original Wireless Control System lacked), it was decided to replace the RC system and get rid of this problem for good. The Spektrum DX-7 system is not affected by the on-board computers any more, because it works well out of the frequency spectrum of the electromagnetic noise generated by them.

Three-Axis Magnetometer Issues

The Three-Axis Magnetometer also didn’t work properly for a long time for unknown reasons; it was discovered later that two problems were actually present. The first and most severe issue was caused by an undocumented bug in the Philips LPC-2119 MCU, affecting the Sample-and-Hold circuit of its A/D converter under certain conditions, when the A/D channels were multiplexed. This bug causes interferences between the multiplexed A/D channels. The bug was fixed using a work-around and was later confirmed by the manufacturer in actualized errata document.

The other problem was caused by the sensor degaussing circuitry, which did not work properly. It was discovered later that there was a bug in the circuitry scheme, which was presented in the datasheet of the HMC2003 as a default solution.

 
control_system_architecture.txt · Last modified: 11/12/2009 11:31 by ondra
 
Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki