American University of SharjahELE 397 – Professional Training in Electrical EngineeringFractal Systems FZ LLC, Warehouse C49, Dubai Production City (IMPZ), UAEWisaam Farhat | 56550Summer I 2018May 27th 2018 – July 7th 2018 (6 weeks)AcknowledgementsI would like to acknowledge the efforts of and thank the several interns that helped me in completing the tasks assigned to us during the internship. I would also like to thank Mr. Yasir, Mr. Till, and the administrators for their support and kindness.
Finally, many thanks go out to my parents for their undying belief in me throughout my studies and this final hurdle, and all thanks in the end are to God.Abstract The purpose of this internship was to apply some of the knowledge and develop some of the skills that were obtained during my years of study at AUS. The internship training could mostly be divided into two complementary parts: designing and implementing. In the designing part, I was tasked with designing electrical systems for several projects, or with inspecting and correcting flaws or potentially faulty aspects of existing designs. The implementing aspects consisted of me constructing the electrical systems or programming and tuning the controllers that I and another electrical engineering intern designed. Most of the design aspects were related to control and electronics, while the implementation consisted of a range of tasks such as soldering & wiring, microcontroller programming, as well as interfacing of different sensors & systems. The major tasks that I worked on during this internship were (named by Fractal) an Aerosphere drone and a Laser-Sound System; a few of the other minor tasks (mostly research or programming) I worked on included a drone swarm project, a 3D printer-like sand dispenser, and a camera gimbal. My major achievement during the internship was the completion of the major tasks to the utmost of my ability given the time, and the results were satisfactory for the company and myself.
List of AbbreviationsUAV: Unmanned Aerial VehicleRPY: Roll-Pitch-Yaw; 3-axis flight coordinatesESC: Electronic Speed ControllerPDB: Power Distribution BoardMP: Mission PlannerArduino IDE: GPS:PPM:RC:IMU:PMU:List of tables and list of figuresThe symbols used in any formulas, figures, and the report text should be listed here with relevantunits.Table of contentsIt should list the contents of the report (chapters, sections, etc.) with the corresponding pagenumber.1. IntroductionHaving started out as an UAV (unmanned aerial vehicle) company, a significant portion of the electronics and parts that the Fractal Systems warehouse contains are relevant to the field of flying vehicles. Now, most of the work the company’s engineers do is not concerned with UAVs, but rather a vast array of technologies with the major purpose of delivering engineering solutions for interactive technology showcases/entertainment events.
As a result, Fractal’s main industry is that which is concerned with robotics and electronics, unmanned vehicles, and screens/lights. Upon entering the company, one would notice outright that there are several large robotic arms, giant moving displays/LEDs, drones, and other small projects surrounding the lobby.During the internship period, the chief engineer tasked me mostly with assisting other engineers in existing projects or conceptual projects which had not yet begun due to the short duration in which I would be working. As such, rather than working on a single, well-defined project, I worked on several. My duties and responsibilities were therefore numerous too; I worked in projects that were concerned with basic component level electronics, as well as projects with system level mechanisms and parts. Soldering and electronic circuit design/implementation, microcontroller programming, and UAV design/construction were probably the most time-consuming and thus major tasks that I was concerned with. I was primarily responsible for two major projects, the Laser-Sound system and the Aerosphere drone (upon joining due to my experience in the field of UAVs over the other interns), while for the rest of the projects I was merely a cog in the greater machine. The Fractal Systems Code of Ethics is in line with the standards set by Dubai’s FAHR Government Code of Ethics and Professional Conduct 1.
It upholds many of the same core values that should be applied in any workforce:• Excellence: To use every rational opportunity to improve one’s knowledge and skills• Diligence: To show interest and commitment to the continued pursuit of high standards• Integrity: To put the interest of Fractal Systems before personal interest• Honesty: To be honest and open; to develop an atmosphere of trust with colleagues• Objectivity: To uphold the truth and make decisions based on analysis of the evidence• Efficiency: To commit to performing to the utmost of one’s ability by appropriately utilizing available resourcesThis Code of Ethics was upheld from my end by the contract I made with Fractal Systems (included in the appendix), which states: “The intern agrees to abide by ethical and professional guidelines set down by agency, especially respecting confidential agency and clientele information.”The Code of Ethics and the expectations placed upon me by Fractal Systems were upheld to the best of my ability: I utilized my time and the resources available within the company to perform my tasks with the commitment and purpose of bettering myself and providing a service to the company that graciously hosted me for 6 weeks.2. ProjectsWhen project work was slow or we were awaiting approvals/materials, we sometimes voluntarily assisted the engineers who were setting up the warehouse and entrance, as Fractal had just moved to IMPZ Dubai when I joined.
The work that I did in that sense mostly involved electronics testing, soldering, and wiring. However, Fractal Systems’ actual workload in the engineering department is centered around several projects. This chapter outlines the work I did on some of the projects that were underway or had just begun. 2.1 Aerosphere Drone The first project was a concept drone (like those in Figure 1) that I was required to oversee the electrical design and autonomous control of.
It is essentially a 1.5m radius sphere with 8 propellers on it (planar through the center); 4 propellers are used to perform a typical quadcopter drone’s standard 3-axis motion of yaw-pitch-roll, and the other 4 are used for an aesthetic unidirectional spinning effect, as demonstrated in Figure 2. Figure 1: FESTO eMotionSphere Drones 2 Figure 2: Top-Down View – Drone Propellers Motion When I first joined, the project had a poor (technically nonexistent) electrical design due to a lack of practical electrical engineers on the team, and no autonomous control scheme (this can be further read about in the journals). I redesigned the electrical skeleton of the drone and developed a basic test algorithm using Python to autonomously fly in an enclosed gymnasium-like setting, as per the instruction of the overseeing manager. Since the plastic sphere was to be filled with a helium balloon to counteract most of the gravitational forces, the drone doesn’t require much thrust from the propellers to generate lift. However, this meant that the electronics would have to be housed on the exterior of the drone, in a small compartment at the bottom, which I didn’t recommend since the flight controller should be relatively leveled with the RPY propellers, as demonstrated in Figure 3. Figure 3: Side View – Drone Electronics Compartment I designed the system as follows: the commercial flight controller is the heart of the drone, and it must be able to communicate with an RC controller as well as with a secondary microcontroller.
The flight controller is powered through a regulator by a LiPo battery, which also powers the microcontroller and the electronic speed controllers (ESCs) through a power distribution board (PDB). The RPY and throttle commands are coupled to 4 separate RC channels by using the flight controller’s software, which only control the first 4 motors (as was depicted in Figure 2 previously). A fifth channel is used to merely send a constant signal upon command (using a program developed on the microcontroller) to motors 5 – 8; note that a single channel is used (throttle) because motors 5-8 are only required to provide a steady thrust that will cause the sphere to spin. This way, the flight controller does not need to control the output signal going to these specific motors’ ESCs, but rather merely pass-through a predefined signal. Based on the thrust-weight ratio after discounting the lift generated by the helium, I selected the motors (2600 kv) and propellers (8×5 in.
), with a 3S 5.3 Ah battery. Rather than a simple microcontroller I selected a minicomputer, the Raspberry Pi 3B, and this was for quite a few reasons, primarily its wi-fi ability which would make programming it over the air much more convenient, as well as its easy interface of several sensors and lightweight cameras. The flight controller was the Pixhawk, which I found amongst the scrap in the company’s warehouse, yet this selection was what I wanted since I am familiar with its firmware and interfacing as well as the software Mission Planner (MP); also the Pixhawk has 2 telemetry ports (which we needed), while the one the team initially randomly selected only had 1. Finally, the Raspberry Pi and Pixhawk can communicate effectively using an opensource protocol called MAVLink, which I intended to use.
Figure 4 and 5 below show respectively the block diagram of the drone’s electrical system and the schematic diagram. Figure 4: Drone Electrical System Block Diagram Figure 5: Drone Schematic Diagram 3 I used my laptop as the ground station with the MP software installed to perform the communication over a paired telemetry unit with the Pixhawk. A separate monitor and interfacing hardware were used with the Raspberry Pi to make the programming and configuration of the two main computers on the drone easier. To test the MAVLink connection, I soldered my own connectors to establish a serial connection between the two devices; I also soldered and connected two test motors powered by a battery, one to represent the 4 control motors, and one to represent the “spinner” motors (designated so in the program since they will cause the drone to spin), so that I could more easily observe what the code was doing. I then configured some necessary parameters in MP, and began the process of coding. Figure 6 below shows the setup. The Pixhawk has 8 pins that can be used to generate PWM signals for motors; using MP, I set the function of the last 4 pins to be a simple ‘pass-thru’ on a specific channel (channel 7), i.
e. the Pixhawk will take the value that it receives from the controller and pass it through to the spinner motors connected to those pins. It must be defined as pass-thru, otherwise the Pixhawk will think that these pins/motors should support the overall position/throttle control, which would be disastrous.
By mapping this channel on the RC controller to a knob/toggle, I could control when the motors are turned on and off and their speed while actively controlling the standard quadcopter controls too. We successfully verified this configuration by temporarily connecting the above setup to an empty drone chassis (this time with all control motors intact), and test-flew it in the warehouse. The performance was monitored over the telemetry unit on MP.
On the Raspberry, I developed two programs using Python for autonomous motion which could be a guide for the interns who would continue working in Fractal after I left, if the drone was built in the future. The first program was developed as a test, and it aims to connect to the vehicle and ensure that basic control operations would perform as expected. The second program was developed for simple flight in a GPS denied zone, most likely a gymnasium or large hall.
The spinners could optionally be activated through a GPIO pin on the Raspberry after toggling a switch that is serially linked with it to the Pixhawk. We also verified the performance of this program with the test drone, though significant tweaks to parameters will obviously have to be done for the sphere in the future. The main flight program active_test.
py is shown below.Active_test.pyimport time from dronekit import connect, VehicleMode, LocationGlobal, LocationGlobalRelative from pymavlink import mavutil import sys import RPi.GPIO as GPIO #map GPIO to PH relay AUX port GPIO.
setwarnings(False) GPIO.setmode(GPIO.BCM) GPIO.setup(17,GPIO.IN,pull_up_down=GPIO.PUD_DOWN) def action(self): print (‘activating spinners’) vehicle.channels.overrides’7′ = 1216 GPIO.
add_event_detect(17, GPIO.BOTH, callback=action, bouncetime = 500) #mavlink connect to vehicle vehicle =connect(‘/dev/ttyS0’,baud=57600, wait_ready=True) print(‘Arming motors’) vehicle.mode= VehicleMode(‘STABILIZE’) vehicle.armed=True while not vehicle.
armed: print(‘waiting for arming…’) time.sleep(1) thr_reduc = 1 spin_const = 20 full_loop_param = 0 #perform closed loop flight while full_loop_param ; 4: forward_param = 0 yaw_inc = 1 spin_inc = 1 thr_inc = 1 pitch_inc = 1 #throttle while thr_inc ; 10: #steady increase throttle vehicle.
channels.overrides'3'=1000+(50*thr_inc) time.sleep(0.1) thr_inc = thr_inc + 1 #midthrottle for hover vehicle.channels.overrides'3'=1505 print('throttle pwm = %d' %(vehicle.
channels'3')) time.sleep(0.1) #pitch while pitch_inc ; 10: #steady increase pitch vehicle.channels.overrides'2'=1000+(25*pitch_inc) time.
sleep(0.1) pitch_inc = pitch_inc + 1 #25% pitch vehicle.channels.overrides'2'=1250 print('pitch pwm = %d' %(vehicle.channels'2')) time.
sleep(0.1) #hold forward 10 seconds while forward_param ; 10: vehicle.channels.overrides'3'=1505 vehicle.channels.overrides'2'=1250 forward_param = forward_param+1 time.sleep(1) #reduce then unride pitch vehicle.channels.
overrides'2' = 984 vehicle.channels.overrides'2'= None time.sleep(0.
1) print('pitch pwm = %d' %(vehicle.channels'2')) #yaw 90 degrees while yaw_inc ; 10: #steady increase yaw vehicle.channels.overrides'4'=1000+(10*yaw_inc) time.sleep(0.
1) yaw_inc = yaw_inc + 1 #10% yaw vehicle.channels.overrides'4'=1100 time.sleep(0.1) print('yaw pwm = %d' %(vehicle.channels'4')) time.
sleep(0.1) #hold throttle vehicle.channels.overrides'3'=1505 #reduce then unride vehicle.channels.overrides'4' = 984 vehicle.channels.
overrides'4'= None time.sleep(0.1) print('yaw pwm = %d' %(vehicle.channels'4')) time.sleep(0.1) #spinners (# spin_const determined by #check channel 6 on MP print('Overriding Channel 7') while spin_inc ; 10: #steady increase spin speed vehicle.
channels.overrides'7' = 1000+(spin_const*spin_inc) time.sleep(0.1) spin_inc = spin_inc + 1 #hold spin at spin_const percent thrust vehicle.
channels.overrides'7' = 1216 time.sleep(0.1) #hold throttle vehicle.channels.overrides'3'=1505 print('spinners pwm = %d' %(vehicle.channels'7')) time.
sleep(0.1) print('Unriding Channel 7') #unride spinners vehicle.channels.overrides'7' = 982 vehicle.channels.overrides'7' = None time.sleep(0.
1) print('spinners pwm = %d' %(vehicle.channels'7')) time.sleep(0.
1) full_loop_param = full_loop_param+1 #slowly land then unride while thr_reduc ; 50: vehicle.channels.overrides'3' = 1505 – (thr_reduc*10) thr_reduc = thr_reduc+1 time.sleep(0.
1) vehicle.channels.overrides'3' = 984 vehicle.channels.overrides'3'= None print('throttle pwm = %d' %(vehicle.channels'3')) time.sleep(1) sys.
exit() 2.2 Laser-Sound System The second project that I worked on was a laser sound system. The idea was to use a stepper motor with a mirror attached perpendicularly to its shaft and a laser to generate different ‘strings’ which, when strung, would play a different sound on each from a speaker attached to a controller. The central controller and timer we used was an Arduino, which we programmed and connected to operate the stepper motor driver to control the speed and number of steps of the motor as well as the laser switching times. The major work involved in this project was the programming/optimization of the codes, but we also spent a significant amount of time on the setup. Figures 7 below shows the basic schematic diagram of the system. Figure 7: Laser-Sound System Fritzing Schematic Diagram 4Our idea was to make the stepper motor rotate back and forth through 10 discrete steps, with the laser flashing on at each step and off during the transition (at the mirror as demonstrated in Figure 8). Done fast enough, this would make a human observer witness 10 beams simultaneously rather than 1 beam switching between different positions (this had to be done with smoke/water vapor/dust in a dark room to observe the phenomenon).
The initial concept was to have a MIDI jack to connect to a computer, which would then play the instrumental sounds from a software (such as FL Studio) or even short voice clips, but we opted for a regular 5mm jack instead after experimenting, which meant that the sounds would have to be recognizable by the Arduino IDE and coded within. An LDR was used as the sensor to detect if a note should be played. Initially, we had wanted to keep the LDR on the ground with the rest of the electronics. With the laser beams aimed upwards, and if the threshold at which the LDR triggers was programmed in accordance with the ambient light, then by placing one’s hand in front of one of the beams, the LDR would read an increase in the reflected lighting and signal the code to read the position at which the stepper motor was when the LDR triggered. Each stepper motor position was mapped to a musical note and would play when the corresponding beam was ‘strung’.
This concept worked quite well, but the problems we encountered were the brightness of the beams, which we realized were affected by the power of the laser as well as the code itself (the laser on-off timings), as well as the ambient lighting that would have to be matched at each startup of the code to the LDR threshold (most of these issues are detailed in the journals). Therefore, instead we suggested having a glove with the LDR implanted within it that the ‘musician’ would fit on their hand, with the wires travelling back through the glove to the controlling Arduino on the ground. While this was more cumbersome, it worked significantly better as we only had to match the threshold for a high enough value as when the beam directly hit the LDR. The setup (created on a foam block and plywood) and the observation of the beams are shown in Figure 9 below. The Arduino program we developed is on the next page.Laser_stepper.ino#include #include "pitches.h"//laser pin int laser = 7; //delays for laser & motor in msint laser_delay=6; int stepper_delay=4; int ldr=0;//notes to be played upon striking chord int melody = { NOTE_C4, NOTE_G3, NOTE_B0, NOTE_A3, NOTE_C1,NOTE_D1 , NOTE_B3, NOTE_C3,NOTE_C2,NOTE_G3 }; //ldr threshold from 0-1024 int threshold = 800; int noteDurations = { 4, 8, 8, 4, 4, 4, 4, 4,4,4 }; const int stepPin = 6; const int dirPin = 5; const int stepsPerRevolution = 200; // change this to fit the number of steps per revolution for your motor Stepper myStepper(stepsPerRevolution, 6,5); int a=0; void setup(){ //Sets the two pins as outputs pinMode(laser,OUTPUT); myStepper.setSpeed(1200); pinMode(stepPin,OUTPUT); pinMode(dirPin,OUTPUT); Serial.begin(9600); } void loop() { digitalWrite(dirPin,HIGH); // Enables the motor to move CW // Makes 200 pulses for making one full cycle rotation for(int x = 0; x < 9; x++) { //stepper high then delay digitalWrite(stepPin,HIGH); delay(stepper_delay); //stepper low then laser high digitalWrite(stepPin,LOW); digitalWrite(laser,HIGH); delay(laser_delay); //read ldr value a=analogRead(0); //play notes while(a
