Merchiston Castle School working with Leonardo
EES 2017: Radar Page 1 of 54
INTERACTIVE RADAR
In conjunction with:
Also with thanks to:
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 2 of 54
ACKNOWLEDGEMENTS
First and foremost, we would like to thank Leonardo, and in particular, Euan Ward and Scott
Smith, for their unwavering support for our project. The idea for this project came from
them, and without Leonardo, we literally would not be able to have done anything.
In addition, we must thank Mr. Nicholls, for always being the herald of common sense, and
keeping us focused on what our project was actually meant to be.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 3 of 54
CONTENTS Acknowledgements .................................................................................................................... 2
Abstract ...................................................................................................................................... 6
Introducton ................................................................................................................................ 7
Meet the team ........................................................................................................................... 8
Brian Ko .................................................................................................................................. 8
Craig Lough ............................................................................................................................. 8
Edward Webster ..................................................................................................................... 8
Rory McKinnon ....................................................................................................................... 8
Sean Tou ................................................................................................................................. 8
Leonardo .................................................................................................................................... 9
As a company ......................................................................................................................... 9
As a partner ............................................................................................................................ 9
Project Launch Day .................................................................................................................. 10
The Launch Event ................................................................................................................. 10
Project Brief .......................................................................................................................... 11
The Journey Home ................................................................................................................ 11
Initial Ideas ............................................................................................................................... 12
Brainstorming Ideas.............................................................................................................. 12
Choosing a SYSTEM .................................................................................................................. 13
Theory ................................................................................................................................... 13
Infrared ............................................................................................................................. 13
Lasers ................................................................................................................................ 13
Ultrasound ........................................................................................................................ 14
Microwaves ....................................................................................................................... 14
Conclusion ............................................................................................................................ 14
Electronics ................................................................................................................................ 15
Making the Electronics ......................................................................................................... 15
Transmitter Module ............................................................................................................. 15
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 4 of 54
Version 1: Schematic ......................................................................................................... 16
Version 2: Schematic ......................................................................................................... 16
Receiver Module .................................................................................................................. 17
Receiver schematic version 1............................................................................................ 17
Receiver Schematic 2: ....................................................................................................... 17
LEDs ...................................................................................................................................... 18
Conclusion ............................................................................................................................ 18
Computing Power .................................................................................................................... 19
Software ............................................................................................................................... 19
Arduino - Sensor ............................................................................................................... 20
Arduino - Hardware .......................................................................................................... 20
Arduino - Communication ................................................................................................. 20
Pi - Processing ................................................................................................................... 21
Pi - Display ......................................................................................................................... 21
Conclusion ............................................................................................................................ 21
Construction and Design .......................................................................................................... 22
Initial Ideas ........................................................................................................................... 22
Meccano ............................................................................................................................ 23
The Antenna Dish ................................................................................................................. 24
Key Maths ......................................................................................................................... 24
First Attempts ................................................................................................................... 25
3D Printed Final Version ................................................................................................... 27
Servo ..................................................................................................................................... 27
Final design ........................................................................................................................... 28
Testing & Conclusion ............................................................................................................ 29
Education Aspect ..................................................................................................................... 30
Initial Ideas ........................................................................................................................... 30
Implementation .................................................................................................................... 31
Conclusion ............................................................................................................................ 31
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 5 of 54
Strathclyde University Workshop ............................................................................................ 32
Project Management ............................................................................................................... 33
Future Delevelopments ........................................................................................................... 34
3D Scanning .......................................................................................................................... 34
Flightpath Analysis................................................................................................................ 34
Synthetic Aperture Radar ..................................................................................................... 34
Electronics ............................................................................................................................ 34
Conclusion ................................................................................................................................ 35
Team Statements ..................................................................................................................... 36
Brian ..................................................................................................................................... 36
Craig ...................................................................................................................................... 36
Edward .................................................................................................................................. 36
Rory....................................................................................................................................... 37
Sean ...................................................................................................................................... 37
References ............................................................................................................................... 38
Glossary .................................................................................................................................... 39
Appendices ............................................................................................................................... 40
Appendix 1 (Leonardo’s Project Brief) ................................................................................. 40
Appendix 2 (Sean’s LED Test): .............................................................................................. 43
Appendix 3 (Brian’s PCB Designs): ........................................................................................ 44
Appendix 4 (Ed’s Code)......................................................................................................... 46
Arduino ............................................................................................................................. 46
Pi........................................................................................................................................ 47
Appendix 5 (Whiteboard Image): ......................................................................................... 52
Appendix 6 (Week 1’s Minutes): .......................................................................................... 53
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 6 of 54
ABSTRACT On the 17th November, the EES Launch Day, our team met our sponsors Leonardo, and more
importantly, our project. The event was quite an intriguing and exciting day for all of our
team, and I expect the other teams as well. We found out that we were meant to make a
working radar model to be used as a display at Leonardo to help educate clients upon the
basic working of a radar. This was initially met with anticipation and apprehension, being
quite the ambitious task for 5 months work, but eagerness only took a few minutes to win
us over into a project that a had a broad range of ideas and outcomes within it.
We then proceeded with the slightly political team position allocations, which was settled
with satisfaction, having found a suitable position for everyone in our group, making full use
of each individual’s strengths. A wild brainstorm session followed, but within an hour, we
were able to tame our ideas down to a realistic yet impressive goal, albeit quite vague at the
time.
Our project came generally into 3 categories, which of course overlapped over the course of
the project; the physical construction, electronics and programming, and educational
aspect. We managed to find members adept in each role and progressed through the
project with these three areas well covered.
As for the radar itself, we made an ultrasound 180° radar in a Perspex frame, with a
parabolic 3D-printed dish mounted at the transmitter/receiver module, and an LED system
integrated into the circuitry.
Much of the prototype was built at Strathclyde University with the assistance of our
Leonardo Sponsors, and managed to get most of the physical construction of the prototype
and the 3D-printing of the dish completed there. In addition, we managed to test our new
dish against a previously made fibreglass one which in the end lost out to the 3D-printed
one.
After that, the next several months progressed well with everyone persevering for several
hours each week in the respective tasks to create components for the radar. As it neared
completion, some more teamwork was required as the 3 categories started to merge into
one product, such as taking the educational resources and making them accessible from a
Kindle Fire, or integrating the LED circuitry into the circuitry in the Perspex frame.
Towards the end of our time, we started to spend more time writing our designated
chapters on the project report, something that not a lot of us expected to be so time
consuming.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 7 of 54
INTRODUCTON We are 5 students currently studying STEM subjects in the Lower Sixth, working in
conjunction with Leonardo, an engineering company based in Edinburgh. We were excited
to get involved in the Engineering Education Scheme because we got the chance to work on
a genuinely relevant project, and to get a feel for the inner workings of a real engineering
company.
The project brief was, very simply, to build a radar. Fundamentally, it was to be an
educational tool, to be used by Leonardo (a company that makes radars) to demonstrate
how their products work. As a result, it needed to be small scale, simple, and easy to
understand. Assisting us with the project we had two Leonardo Engineers, Euan Ward and
Scott Smith, along with Paul Nicholls from Merchiston (Head of Science and Technology).
The whole project lasted approximately 5 months, from the Launch Day on the 17 th of
November to the Celebration and Assessment Day.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 8 of 54
MEET THE TEAM
Brian Ko Brian takes the most subjects in our team: Maths, Further Maths, Physics, Electronics and
Mandarin. Being the only member who is taking Electronics, he is in charge of our radars
circuitry. He manages all the circuits needed for the radar to work, as well as the control for
the frequency and time interval of wave transmissions. Furthermore, having past
experiences with Computer Science, he helps Ed with some of his coding work.
Craig Lough Craig is currently studying Maths, Further Maths, Physics and Chemistry. He is the team’s
project manager, in charge of organising tasks, setting deadlines, writing the non-technical
parts of the project report, and taking minutes during team meetings. Probably the most
inexperienced in any sort of science project, he learnt of Meccano and the ease of
3D-printing for the first time during this project.
Edward Webster Edward (Ed) takes Maths, Further Maths, Physics, Chemistry and Biology. With a background
of coding, he is the person in charge of most of the programming for the team. This involves
all the electronic displays, information processing, and making the virtual template of our
3D printed components such as the parabolic dish.
Rory McKinnon Rory studies Maths, Further Maths, Physics and Chemistry. Being quite a hands-on person,
he takes charge of the design of the mechanisms and structure of the radar, making parts
like the Meccano structure, Perspex box and Lazy Susan bearing. He is also usually the one
at the whiteboard during group meetings, helping to illustrate any vague concepts we
imagine up, having taken Art at GCSE level.
Sean Tou Sean is currently taking Maths, Further Maths, Physics and Economics. He is the creator of
the educational aspect of our radar, an aspect unique to our project that other teams may
not have. He created the slides about the individual components, more detailed documents
on the display board, as well as coming up the LED lighting system that illuminates the
relevant components, having studied Electronics at GCSE.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 9 of 54
An image of the Selex Galileo Factory (Leonardo
since 28 April 2016) in Edinburgh
RAINSCANNER®, a weather radar
system by Leonardo
LEONARDO
As a company Formerly known as Selex, and a subsidiary of the Finmeccanica Group, Leonardo is a UK and
Italy based Defence Company. Formed in
January 2013, it is currently the largest
inward investor in the UK defence sector,
as well as generating exports worth around
£1.3bn to the UK economy annually.
Currently, the company is involved in
developing systems for the Euro-fighter.
Curiously, the models of the aircraft shown
advertising the company each display the
insignia and roundels of one of the partner
nations involved in building and arming its
air force with the Euro-fighter.
As a partner Leonardo being a defence company, which
specialises in early warning systems, are the ones
that gave us the task to build a radar.
This is a very suitable project for them to sponsor,
as the task is not only to build a functional radar,
but to make it educational, by ways of it being a
very simple display and very easy to understand.
Such a display may be useful for Leonardo to
demonstrate the science behind radars to clients
that do not have a full understanding of how they
work.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 10 of 54
PROJECT LAUNCH DAY
The Launch Event Our first day of the EES experience started with a cheerful half hour minibus trip to
University of the West Scotland. Apart from the fact that we were to be assigned a project
that would occupy us for the coming months, we were unaware of what would occur within
the next few hours.
With anticipation comes apprehension, but whatever nerves we were feeling were quickly
expelled with our first activity: making a duck out of Lego pieces. It was a rather simple task,
and we had 30 seconds to do so, but it was rather
humorous to see how many different interpretations of a
duck there could be. Nevertheless, the task served its
purpose, which I assume was to relax everyone, and seem
vaguely scientific at the same time. Our next task also
involved Lego, however this one was a bit more
complicated, as we had to make a moving tow truck out
of robotic pieces. It was still following instructions
however, and none of the teams struggled. Despite its
apparent simplicity, each group was given two boxes of
pieces, and thus there was a sense of competition to see
who could finish first. The real ‘engineering’ aspect was
after all the teams finished; we had to make improvements to the truck however we could.
There were lots of ideas for this, such as using better wheels, and removing some excess
weight, etc. One of our solutions involved simply poaching a second motor from the box at
the front for double the speed.
Once the Lego tasks were concluded, we moved onto some short presentations, about the
EES programme and team management, introducing us to some new concepts such as the
Gantt chart, a vital tool that helped organise our team.
After presentations, we got down to work. We met our sponsors, Leonardo, and our
partners for the next few months, Scott Smith and Euan Ward. They briefed us on what
Leonardo was about, and more importantly, what our project was to be. When they
revealed that not only did we have to make a working radar, but also that it had to be
educational as well, it made us a bit nervous, as it seemed to be a very daunting task.
However, over the next few hours or so, they helped us to comprehend the individual
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 11 of 54
aspects to a radar, like the suitable wave, and how to focus it. With their help, we left the
hall with a sense of purpose that would linger for the upcoming months.
Project Brief Our Final Product had to fulfil several requirements (Refer to Appendix 1.):
Design a system that demonstrates the principles of a radar for visitors to Leonardo
Make a working model of a radar that measures both distance and direction
Have an interactive element for an audience, in order to educate them about how
radars work.
The Journey Home In a way, the car ride back to school was our first team meeting. After a quick trip to the
McLaren Showroom to cool off our heads, we started to discuss. Firstly, we listed down
what skills that were relevant to the project, individually, we had, such as electronics
experience and programming knowledge. From there, we decided pre-emptive group roles,
which went as such:
Brian Ko: Electronics Specialist
Craig Lough: Project Manager
Edward Webster: Programming Specialist
Rory McKinnon: Mechanical Structures Specialist
Sean Tou: Education Manager
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 12 of 54
INITIAL IDEAS During our 1st meeting, we brainstormed a general outline about what we were going to
make in the upcoming months, delegated research tasks on different waves for our next
meeting, and arranged weekly meeting times.
Brainstorming Ideas
5. First thought of our display.
Generic radar display was
popular, and discussed whether
360° was necessary - 180° may
be simpler.
6. Undecided on servo or
stepper, but leaning
towards servo from the
start again due to
familiarity.
4. Two drivers we could use were
the Pi and Arduino. There was an
initial bias towards the Arduino,
due to familiarity with it.
1. Original thoughts on parabolic dish,
mainly given it was the first thing that
came to mind when thinking ‘radar’.
Possibility of using fibreglass.
2. First discussion upon type of
wave to use, listing the pros and
cons without research, just general
knowledge. Main point of discussion
was whether to use EM or
ultrasound waves.
3. Very basic first thoughts of how the radar
would work, involving only the dish,
transmitter and receiver; whether to point
both towards dish, or have one facing in and
one away.
1.
5.
2.
4.
3.
6.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 13 of 54
CHOOSING A SYSTEM Having spent some time keenly discussing initial ideas, we came to a point where we
needed to make a key decision before we could move on: What are we going to use to do
the transmitting? To come to a decision, we took a step back to consider the fundamentals
of remote detection.
Theory The way a radar detects objects is through the interpretation of its transmitted signal. It can
calculate distance based upon the time taken for the signal to go out and return to the
receiver. The carrier of this signal (the medium) is heavily defined by the use of the radar.
Radio is most often used because radio waves can travel large distances, which suits the
environment of most industry-level radars. Proximity sensors, which are a type of radar,
tend to use high frequency sound waves.
We went away and individually researched each of the options available to us, before
discussing them in our second meeting. The results of our research, and our following
discussion, is below.
INFRARED Infrared frequencies are those between 300 GHz and 430 THz, which is just below the
frequency of visible light. IR sensors built in circuits can provide a binary output, and there
are those which can provide an analogue output or a multiple bit output, making them quite
a versatile choice. However, the sensors with a binary output are only good for detecting
the proximity of an obstacle, not the range of it, but this type of infrared sensor is very
cheap. The analogue or digital ones can output the actual distance of the obstacle from the
sensor.
On the other hand, an infrared sensor cannot work accurately outside in the sun since it
may be affected by sunlight. A narrow beam width is needed as well.
LASERS Laser’s proved to be a very good option however they proved not to be possible due to their
cost. Lasers propagate at the speed of light and have a very narrow coherent beam which
would have allowed for massive precision. However in order to time electromagnetic
radiation we were looking at ≈ 5ns for 20m range which was considerably more than the
clock speed on most computers. This posed many problems as a computer could not be
used for any timings. More problems were then faced in that how do we get our minute
time onto the computer. There are many laser range finders available however getting a
module alone was very expensive (£150+). Removing the sensor from an existing cheaper
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 14 of 54
range finder was a possibility however this was still not a cheap solution and nowhere on
the internet could we find a documented case of someone doing it so we decided to play it
safe.
ULTRASOUND Ultrasound was easier to work with than electromagnetic waves. This was due to the fact
that it was sound so only travelled at 340m/s (≈100 million times slower than EM) so small
distances were measured in hundreds of milliseconds rather than nanoseconds. In addition
ultrasound components are extremely cheap and are easy to produce.
The problem with ultrasound however was that there is a much bigger error in distances as
the times can deviate by a lot more and also the speed of sound can vary by up to as much
as 20m/s which introduces a large error. Moreover, the ultrasonic modules all stated a
dispersion of 60º which also introduced a massive inaccuracy in finding direction.
MICROWAVES Microwaves refer to any frequency between 300 MHz and 300 GHz. Advantages include the
fact that they can penetrate haze, light rain and snow, clouds, and smoke. Shorter
microwaves are used in remote sensing. These microwaves are used for radar like the
Doppler radar used in weather forecasts.
Except for very long-distance radars, such as coastal and ship-borne over-the-horizon and
missile early warning radars, all radar systems use frequencies above 300 MHz. This is the
main reason we decided to not use microwaves. In addition, it is absorbed by water, and
thus cannot detect it.
Conclusion Ultrasound was concluded to be the most suitable for our purposes. This was due to it being
cheap and easy to produce and receive. Also because the speed of sound is vastly less than
the speed of light, timing the time it took for the pulse to get to the object and back was
possible as milliseconds are easy to measure whereas nanoseconds are extremely hard,
especially due to the fact that most clocks on computers aren’t even precise enough to time
a pulse that short.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 15 of 54
ELECTRONICS
Making the Electronics There were 3 main electronic components required for our radar:
A. A Transmitter Module
B. A Receiver Module
C. A LED Driver Circuit
Transmitter Module
The transmitter module consists of 3 oscillators which serves different process. The 100ms
astable determines the “no transmitting” time between each pulse, this time is calculated
by the speed of sound and the maximum range of the transmitter. A CD4093BC Quad 2-
Input NAND Schmitt Trigger astable multivibrator is used instead of a NE555 as the NE555 or
other transistor based astable requires additional based components which does not give a
symmetrical square wave output. A CD4093BC ensures that the continuous square wave
output has a 1:1 on/off ratio.
The 2ms monostable is used to determine the pulse time period, this value is obtained by
trial and error to find the smallest possible transmitting time the transmitter can handle, as
the shorter the time period, the higher the sampling rate can be. The CD4011B CMOS NAND
gate is used in this circumstance.
The next stage is the multiplexer, this is essentially a logic “Switch” to allow an external
trigger to the next oscillator. This is to allow the microcontroller Arduino to trigger the
40kHz Oscillator.
The 40kHz oscillator is the frequency our ultrasonic transmitter operates at. A NE555 chip
and 2 external components are used to control the frequency because the NE555 can
provide a suitable output current to drive the US device.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 16 of 54
We have encountered problems with the MOSFET drivers due to the physical design of the
transmitter and therefor have left it out. Smoothing circuitry is also used to ensure noise
from the PSU will not interfere with the circuit.
VERSION 1: SCHEMATIC
VERSION 2: SCHEMATIC
Improvements made in the Version 2 schematic includes a MOSFET driver from the Arduino
input as we encountered problems when triggering via the Arduino because of logic voltage
differences. The version 2 PCB also has less jumper wires to increase reliability, via points
are also added for pins to be soldered on the board.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 17 of 54
Receiver Module
The receiver consists of 3 different stages. The first stage are the amplifiers, the signal from
the receiver is amplified by a factor of 10 for 3 times using TL081 JFET-input operational
amplifier. A capacitor on each stage is also used to filter out all low frequency signals (below
40kHz) to prevent noise from interfering with the circuit.
The comparator circuit is to convert the analogue signal to digital, the threshold is set by a
10k pot on the PCB. A diode is used to eliminate the negative voltage into the comparator as
it can only operate from 0-15v.
The monostable is used to create a time delay until the next pulse to prevent echos from
interfering with the measurements and provide a clean pulse to measure.
As the whole circuit operates at 0-15v, a potential divider is used to lower that voltage to 5v
which is the Arduino logic level voltage.
RECEIVER SCHEMATIC VERSION 1
RECEIVER SCHEMATIC 2:
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 18 of 54
In version 2 of the schematic we have decided add 3 more stages of amplifier to improve
the range of our product. We have also used thicker tracks for higher reliability and easy
soldering. Smoothing capacitors are also added for noise reduction.
LEDs We did a small experiment to test at what voltage the LEDs will work. In the experiment, we
used three LEDs which have the colours of red, green and blue and plotted a current against
voltage graph to illustrate the result. As a result, we know that the LEDs start to perform at
above 2V. After this, we decided to keep the LEDs at around 100mA because under this
situation, the LEDs are bright enough for the demonstration of the radar. As we are going to
use a 5V power supply, we calculated that the resistance for each LEDs which is 20𝞨 to 30𝞨
by simply V=IR.
NPN medium power transistors were used to allow the GPIO pins of the Raspberry Pi to
control the LEDs in response to user inputs.
At last, we chose to use 68𝞨 resistors as we don’t have any 20𝞨 to 30𝞨 for each of the LED.
A 68𝞨 resistor can give us the current around 74mA which is bright enough for
demonstrating to people how radar works.
(Refer to Appendix 2 for Sean’s LED Test)
(Refer to Appendix 3 for Brian’s PCB Designs)
Conclusion The electronics is a very significant part of the project, developments and re-designs are
conducted improve both reliability and performance. To further improve we could use
differential amplifiers to reduce noise and isolated power supply to reduce interference
between circuit boards.
The transmitter and receiver circuit were a real challenge to make work reliably and it was
very gratifying to achieve a fully working electronic system before the end of the project.
The design-test-evaluate-redesign process was definitely in evidence.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 19 of 54
COMPUTING POWER Two main devices were used in the computing for the Radar. An Arduino was used to
control the servos and send out pulses using the ultrasound hardware, however this was
dictated by a main computer which told the Arduino where to point and then asked the
Arduino how far away the object was.
A Raspberry Pi was used on the basis that it was a cheap and compact computer, however
the program will run on any computer which can run python. The program coordinated the
Arduino by telling it where to point. The Arduino then responded with the Time of Flight to
whatever it was pointing at. The two devices communicate over a USB serial connection. By
using two devices good computing power and good input/output controls were obtained,
whereas if only one was used the other quality would have been sacrificed.
Software The aim of the software is threefold:
A. to dictate the movement of the radar
B. to control the transmitter
C. to interpret and display the information coming from the receiver
Two devices handle the software, a Raspberry Pi and an Arduino. The Raspberry Pi is the
computer overseeing the operation, and the Arduino acts as the interface between the
software and the hardware. We can discuss the roles of both devices in the context of the
three aims of the software:
A. Any instruction for movement of the motors comes from the Raspberry Pi, through
the Arduino, to the motors.
B. The Raspberry Pi passes the signal to transmit to the transmitter component through
the Arduino
C. The signal from the ultrasound receiver is passed through the Arduino to the Pi,
which handles the analysis and display
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 20 of 54
The individual programming elements are discussed below
ARDUINO - SENSOR The Arduino was connected to the transducer circuit which created the pulse. The Arduino would send a 10 microsecond pulse and then listen for the echo, which was proportional to
the distance the pulse had travelled.
The echo had to then be timed so that the distance travelled can be calculated.
ARDUINO - HARDWARE
The Arduino also had to point at the correct angles; this was achieved as follows.
ARDUINO - COMMUNICATION Once the raw data was recorded it had to be sent to the Raspberry Pi so it could be
processed and turned into useful data. The Pi and Arduino were connected via a serial
connection (either through USB or Tx and Rx pins). The Pi had to tell the Arduino where to
point (both pitch and heading) and also receive the time from the Arduino. This was done as
follows.
digitalWrite(trigger, HIGH); //Start The Pulse
delayMicrosecond(10); //Wait 10µS
digitalWrite(trigger, LOW); //Stop the Pulse
timeOne = pulseIn(echo, HIGH); //Time Antenna
Reflection
timeTwo = pulseIn(echo, HIGH); //Time of Flight
while (Serial.avaliable()>0){
command = Serial.readString();
if (command == “heading”) {
headingServo.write(serial.readString());
}
if (command == “time”) {
measureTimes();
serial.println(timeOne, timeTwo);
}
}
Servo headingServo; //Create Servo
headingServo.attach(10); //Connect Servo to Pin
10
headingServo.write(angle); //Angle dictated by Pi
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 21 of 54
The code says:
If serial data is available, read it. If the data says “heading”, ask for the angle and set the
servo to that angle. If the data says “time” it runs the function ‘measureTime()’ transmit the
information back to the Pi.
In this was the angle can be set and the times transmitted.
PI - PROCESSING The Pi would receive the data from the Arduino and turn it into distances.
Distance = Speed x time and the speed of sound is constant therefore if we know the time
we can calculate the distance.
The time was halved (because the time of flight is to the object and back) and multiplied by
the speed of sound, so as to obtain a distance.
PI - DISPLAY Once the distance was obtained the results were plotted on the display. In order to find the
coordinates on the display trigonometry was used. Here is the software used to generate
the x and y coordinates of the object.
Where heading is the angle that the radar is pointed at and the distance is how far away the
object is. SF was the scale factor so that the distance measured translated to the screen size.
All the code above is simplified, the full software can be found in Appendix 4 (Ed’s Code):
Conclusion By using the Raspberry Pi and Arduino devices and the code shown above the radar was
capable of measuring distances and certain directions and displaying this visually. The code
was originally tested using stock US devices and miniature servos and then implemented
successfully on our own hardware using our own transmitters and receivers.
x = width - SF*distance*cos(math.radians(heading))
y = height - SF*distance*sin(math.radians(heading))
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 22 of 54
CONSTRUCTION AND DESIGN
Initial Ideas With ultrasound decided on as the means of detection, attention could be turned towards
the design of the product. Initial ideas focused largely on the moving parts, and how to
achieve the smoothest and most precise movement.
We knew we would need at least one motor - stepper or servo - controlling the main
horizontal rotation of the sensors. We assumed these sensors would also come with a
parabolic dish, and so considered how to deal with the potential weight of such a set-up.
The most promising suggestion seemed to be to use a lazy Susan bearing - two plates joined
by a wide circular bearing, ideal for working with large loads. The lazy Susan’s width would
also allow for greater stability, especially if we were to have a top heavy model.
All of the individual parts would need to be housed in a way that made them clearly visible
and appealing – important parts of the teaching / educational aspect. An initial idea for this
housing was to create a box frame welded from steel struts. This would surround all the
components (apart from the dish and sensors) while leaving them clearly visible. Circuit
boards and motors could be secured to platforms further welded onto the frame. As the
modelling advanced it became clear that this idea was unnecessarily complex.
Initial whiteboard-drawn idea of the steel box design
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 23 of 54
We chose ultrasound as a carrier being well aware of the downside that the components
available to us had a very high dispersion, and that we would need to focus the beam with
an antenna (a dish). Initially we spent some time understanding the properties required of
the dish and the maths involved, before thinking about a process to create one. Fibreglass
was decided as the material for a prototype due to its strength and low weight.
MECCANO
To experiment with mechanisms for turning the radar, we built a model from Meccano, a
construction kit consisting of metal strips and plates which can be fastened together with
nuts and bolts. A 15cm lazy Susan bearing was installed, which could be driven on a central
axle by a pulley, connected to a cheap electric motor. A plate was mounted on top to allow
weight to be added. The bearing performed well, spinning with relatively little resistance
with weights up to 5kg. There were, however, issues with responsiveness due to the low
friction between the gears and the pulleys, and the whole system often had to be given a
nudge to get started.
An image of the Lazy Susan bearing with the motor attached
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 24 of 54
Going forward, we planned to incorporate gears into the model to overcome the issues with
pulleys. An option we considered was to use an internal gear around the inside
circumference of the bearing, driven by a motor in the centre. These shapes could be easily
laser cut or 3D printed
The Antenna Dish KEY MATHS In order to narrow the beam in the most efficient way, the dish had to take the shape of a
parabola. Furthermore, we had to know the exact focal point of this parabola, otherwise the
dish would be redundant.
A parabola is defined as having distance from the focal point to a point (x, y) on the parabola
equal to the distance from point (x, y) to a constant line called the DirectX. From this
information we can calculate the focal point of the parabola as follows.
Focal Point Calculation
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 25 of 54
FIRST ATTEMPTS A prototype was made from fibreglass.
We took a large piece of mountboard
and spread epoxy resin onto it in a
wide circle (the size of the dish), then
stuck a sheet of foil on top.
Once dried, we pumped air through a
valve in the middle of the board to
create a dome. The first attempt
failed as the pressure became too
high and burst the seal.
An early attempt inflated ready for the fibreglass
Foil glued to mountboard ready for moulding
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 26 of 54
The valve stopped any air escaping while we layered fibreglass on top to form the dish.
The dish could them be cut from the rest of the material using a Dremel.
While we were initially very pleased with the dish, it had problems. The maximum depth we
could achieve was relatively low, which meant increasing the radius to achieve a sensible
focal distance. This extra size made it heavy and unwieldy, which would reduce our ability to
control the radar’s movement. Another issue lay in the shape of the dish itself. The nature
of using pressure to form the dome meant that the dish we had was spherical (a section of
the surface of a larger sphere) rather than parabolic. This meant less efficient focusing, and
a different equation to find the focal point.
Layers of fibreglass on the final prototype dish
Finished fibreglass dish
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 27 of 54
3D PRINTED FINAL VERSION At the Strathclyde University Workshop we were given the opportunity to 3D print a better
dish, and were excited to do so, given the quality of the 3D printer (a resolution the width of
two red blood cells).
The design was made in Fusion 360, taking into account the flaws of the fibreglass dish. The
CAD model consisted of half a parabola rotated around a central axis with mounting points
attached. Along with these design modifications, we had to consider the restrictions of the
Strathclyde 3D printer: the diameter could not exceed 150mm. With one variable fixed, we
chose a depth that would give a focal distance in a roughly suitable range - 100-150mm.
Using the formula, the focal length came out to be 121.2mm, and the depth 11.6mm.
Both dishes were tested at the Strathclyde Workshop, the details of which can be found
further down in the Strathclyde section.
Servo Having considered using both servo and stepper motors for the rotation of the dish and
sensors, we decided to go forward with servos, mostly given that we had more experience
with them within the team.
A servo motor was incorporated into the Meccano model, attached to a central axle using
plastic gears. The servo was able to drive the model without problems – the gears allowed
for the transfer of large amounts of torque and vastly increased responsiveness. This
increase in torque enabled a 1:1 gear ratio to be used, meaning that the programming didn’t
have to compensate for a change. The 3D printed dish was mounted onto the model and
was relatively stable when turning.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 28 of 54
Final design The final design makes further improvement in all areas. Most fundamentally, a second
servo motor is attached directly to the dish to provide movement in a vertical axis as well as
horizontal. A Perspex plate is attached to the lazy Susan to provide a platform for this
second motor, which is itself secured with a line-bent Perspex mount.
The mechanism which drives the rotation has been simplified. A servo motor is mounted
beneath the lazy Susan, and four bolts extend up from the servo head through the Perspex
plate. This method combines the driven and driver axle into one, rather than connecting
them via gears or pulleys. The weight of the dish and sensors still rests on the lazy Susan
bearing, with the power coming from the servo.
Instead of a box frame surrounding the whole device, each constituent part is mounted onto
a Perspex base. The lazy Susan is raised above the rest by four aluminium tubes, which have
been tapped and bolted through the base. This is to ensure the beam is not obstructed by
anything else on the board.
The Meccano Model without the transmitter/receiver module mounted
Perspex construction showing lazy-susan and servo mounts
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 29 of 54
The sensors have been mounted within a small piece of mount-board, attached to three
wires extending from the dish.
Testing & Conclusion The servo was initially encountering large amounts or resistance when turning, which was
due to a misalignment of the holes drilled in the lazy Susan plate. Given that the
misalignment was small, this could be fixed by widening the holes to provide more ‘give’
when turning.
Overall, the aesthetic is good, if a little cramped. The Perspex platform will eventually be
changed from dark red to transparent to allow the users to clearly see the servo motor
beneath.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 30 of 54
EDUCATION ASPECT
Initial Ideas The idea of interaction was central to our thoughts surrounding the teaching aspect. We
wanted users to be able to engage with the information in the most exciting (yet feasible)
way.
A concept we had all seen in museums was to use buttons to light up different sections of a
model or exhibit, and so we were keen to take this forward. Using buttons secured to the
base of the radar would have been problematic as it would have prompted users to stand
too close to the dish and sensors (the software and analysis becomes unreliable at short
distances). Instead we considered using a touch-screen tablet, which could be given to the
users, to activate the lights on the model.
The way the information was presented was important to consider. The most appealing way
seemed to be to take the user on a ‘journey’ of the process of detecting an object with a
radar. The information was blocked into sections of a flowchart, starting with the generation
of the signal and ending with the analysis and display.
Splitting the information up this way had the added benefit that it could correlate to the
buttons discussed earlier. Each block of the flowchart corresponded to both a brief segment
of information, and a physical part of the radar, which could be lit up.
An image of the flow chart
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 31 of 54
Implementation The power of the Raspberry Pi was once again used. The Raspberry Pi was made to act as a
WiFi hotspot allowing the Kindle to connect wirelessly to the Pi. The Pi was made to run a
basic webserver (based on apache) hosting the pages of information. This had the
advantage that the information could be easily updated. The Pi’s WiFi network was accessed
by IP address by the Kindle as the Kindle seemed incapable of resolving a hostname. The
WiFi network was not broadcast as a public hotspot.
Pressing on-screen buttons on the Kindle prompted the Pi’s webserver to activate logic
levels on the various GPIO pins. These GPIO pins were connected, via transistor drivers, to
the high power LEDs discussed previously.
Conclusion Overall, this resulted in an elegant final solution. A tablet (a kindle fire) displays a
homescreen with 6 buttons - an introductory explanation followed by a 5-step flowchart. As
the user presses a button, the page changes to show the relevant information, and the
corresponding part of the radar lights up in front of them. The information briefly takes
them through a part of the process, before guiding them back to the homescreen for the
next step in the flowchart.
We were pleasantly surprised by how straight-forward this part of the project was to
implement.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 32 of 54
STRATHCLYDE UNIVERSITY WORKSHOP Once we arrived at Strathclyde we immediately began brainstorming as to what we wanted
to complete. With very well equipped electronics workshops and 3D printers we were keen
to create a parabolic dish and begin work on prototype transmitter and receiver circuits. In
addition with Euan and Scott’s expertise to hand we were keen to characterise the beams
and their efficiency.
The beam produced by each dish had to be characterised so that we knew how much it
dispersed by. We did this by mounting a transmitter in the focal point and moving a receiver
around in an arc, measuring the angle as we did so. The amplitude of the signal received
was measured and graphed against the angle, so that we could see how the beam
dispersed. The graphs we obtained are shown below:
We were immensely pleased with the results. Firstly, the fibreglass dish gave a large
improvement on the unaltered transmitter, both narrowing it and increasing its power. The
fibreglass antenna, however, was dwarfed when compared to the 3D printed dish, which
provided the same gain once more over.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 33 of 54
PROJECT MANAGEMENT The main way our team was organised was through something that we were taught at the
Launch Day, a Gantt chart.
It diagrammatically represents our entire schedule that we must adhere to, as well as
showing very clearly where our priorities should lie.
Our team held weekly meetings, 4pm on Thursdays, which were an hour long, with the
priority on every member telling the other what he had achieved that week, any problems
that arose, and also everyone getting briefed on what their tasks for next week were. In
addition, this was the time where any big decisions regarding our product were made, such
as the initial designs and components that needed to be acquired/made. Thus each week
usually had a whiteboard plan to visually illustrate our ideas, and also a set of minutes to
keep tabs on progress. Any leftover time was spent in the workshop to get some extra time
in.
(Refer to appendices 5 and 6, images of a whiteboard and week 1’s minutes as an example)
Communication was an aspect of teamwork that was very easily dealt with, as it took a
minute to set up a WhatsApp chat group that not only was very simple to communicate
with, but had the added bonus of being able to store related media. However, there was an
issue of the images and videos being quite hard to access if we needed to access them on a
computer, so we transferred everything to a shared Google Drive, in which we could easily
sort files into folders, as well as collaboratively work on the Project Report.
Our Gantt chart at a point in time roughly halfway through the project
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 34 of 54
FUTURE DELEVELOPMENTS
3D Scanning By using a pitch servo we could scan in 3D dimensions around the Radar. This could be
displayed as contour lines using trigonometry. Alternatively the distance could be
proportionally translated to a grey between black and white and a photo generated. This
was not incorporated as the maths was very complicated in too little time as the dish was
not revolving perfectly around an axis.
Flightpath Analysis Another development would be to allow the software to look for patterns such as lines and
patterns in moving points which would allow moving objects to be detected and followed.
The software did highlight moving points in a separate colour however it had no capabilities
to “look” for moving objects, however if it could its velocity and direction could be shown
and this data used to calculate things like where the object will be in future of if it will
collide with the radar or potentially another object.
Synthetic Aperture Radar Synthetic Aperture Radar (SAR) uses lots of complex maths to join several scans together
over an accurately known distance to generate a very accurate scan from many low
resolution ones. Because it measures from different points it verifies the whether an object
exists and the shape of the object which is not achievable through a single scan.
Electronics Differential amplifiers could be used to reduce the noise generated from the circuits, an
isolated power supply could also prevent interference from the transmitter board and
receiver board. A power amplifier could also be used to boost the output of the transmitter
from 15V to 30V or more. Increasing the output power of the US transmitter would be a
future priority as this would dramatically increase the range.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 35 of 54
CONCLUSION Having been tasked with a project that we considered extremely ambitious, our team has
managed to produce an educational resource in the form of an interactive radar.
Our device managed to:
Determine the distance and direction of an object through ultrasound beams
Automatically rotate 180° on a clear Perspex box
Use an Arduino to operate the radar’s mechanisms and interpret information
Utilise a Raspberry Pi in order to display information in a diagrammatic fashion
Display information in an intuitive flow chart design on a Kindle Fire
Use an LED system to illuminate the different components of the radar that were
relevant to the screen being shown on the Kindle
The interactive radar has been confirmed to not only operate as a standalone device of
detection, but also uses its clear structure to its advantage in teaching the public of the basic
workings of a radar in an easy to understand manner, which completely satisfies the project
brief we had been given, something that not everyone in our group had thought was
possible upon hearing about it for the first time.
Being this team’s project manager, I was deeply impressed by my team’s ingenuity,
capability, and most important of all, dedication. I am very grateful for their continued faith
and effort in our project, in which every member had contributed their maximum effort to,
to create something that I, for one, am extremely proud of.
Most of all, I hope that this radar, which most important use is to educate, will inspire
younger students to pursue a scientific-related career, and perhaps one day participate in
the EES.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 36 of 54
TEAM STATEMENTS
Brian Throughout this project I have developed circuit design skills for both analogue and digital
circuits. Testing my circuit also allow me to gain experience on using technical equipment
such as frequency generator and oscilloscope. The final circuit is created using PCB Design
software and PCB manufacturing facilities which I find very tricky to use but perfected it by
the time I am on my fourth design of my circuit. I have also learnt to effectively
communicate my circuit operation procedure to ensure that the software developer
(Edward) understood how to make the software communicate with the hardware. I have
also learnt how to use CAD software such as 2D Design to design the servo bracket and the
frame of the product, the CAD file is sent to the laser cutter. Although I have encountered a
lot of problems in 3D printing some of the parts for the product, towards the end of the
project I was able to debug and resolve problems very quickly as I have gained a lot of
experience. During the visit to Leonardo I learnt about their testing facilities and the role of
a working day to day engineer. I have developed my team management and work hard to
manage project deadlines.
Craig The EES has given me insight into the different aspects to how engineering firms operate.
Preconceptions included the notion that 90% of our time would be spent in a workshop
making our final product, but reality showed that planning our project and documenting our
progress takes up a significant and surprising amount of time. Being the Project Manager, I
primarily gained skills involving team communication, organisation and planning. On the
other hand, I picked up knowledge of practical techniques from laser cutting and working
with Perspex, to moulding fibreglass.
Edward In this project I have learnt the importance of teamwork and sticking to a deadline. Several
years ago I made a very similar Radar using off the shelf servos and ultrasonic transceiver
modules which provided a solid foundation on which to base the softwar. Moreover I have
honed in my 3D design skills by designing increasing complex structures such as parabolic
antennas. It was also extremely exciting to get to see and use the 3D printers at the
workshop. Having designed the 3D Printed components, written all the software, the
information website and its functions and working tirelessly to make Brian’s circuits work
with everything it was quite difficult to complete the project on time but the experience has
helped me with my time management.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 37 of 54
Rory Going into this project I had had relatively little experience of bringing an idea fully into
reality. I was excited to see my ideas come together in the construction of the model, and
even more so when the other aspects came together with it to create a working design. I
have enjoyed discussing and refining ideas among the team and with our mentors from
Leonardo, and am genuinely proud of what we have achieved.
Sean In this project, I have learnt the importance of completing tasks to a set deadline and
developed some advance knowledge in electronics. During the trip to Leonardo, I learnt a
lot of in-depth knowledge about radars. It also helped broaden my knowledge about the
uses of radars on a commercial scale, and also brought to my attention different aspects of
radar production as a business, for instance environmental testing. Overall, this project has
given me more confidence heading into the challenging projects set in the engineering
courses at universities which I hope to attend, which I am grateful for.
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 38 of 54
REFERENCES
http://www.sensorsmag.com/components/ultrasonic-transmitters-vs-guided-wave-radar-for-level-measurement
https://en.wikipedia.org/wiki/Radar
http://simplybearings.co.uk
http://www.uk.leonardocompany.com
http://www.pcbcart.com/article/content/PCB-manufacturing-process.html
http://www.electronics-tutorials.ws/opamp/opamp_2.html
https://en.wikipedia.org/wiki/Schmitt_trigger
https://www.uwlax.edu/its/helpdesk/
http://www.radartutorial.eu/20.airborne/ab07.en.html
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 39 of 54
GLOSSARY Capacitor – A passive two-terminal electrical component that stores energy in an electric
field
Dremel – An American Brand of rotary power tools
Function - A snippet of code that can be called upon to perform a task
Lazy Susan Bearing - A bearing that acts like a turntable, using ball bearing to assist in the
rotation of two plates effectively despite significant weight on the bearing iteslf
Medium – The substance through which the wave travels
Monostable - An electronic circuit that generates an
output pulse. When activated, a pulse of a pre-defined
duration is produced.
Oscillator – An electronic circuit that produces a
periodic, oscillating electronic signal, in our case being a
square wave.
Parabola – A two-dimensional, mirror-symmetrical curve, which is approximately U-shaped,
for example following the graph of y = x2
Potential Divider - A linear circuit that produces an output voltage that is a fraction of the
input voltage
Servo – affordable mass-produced servomotors, often
used in small scale robotics. Most, like ours, act as rotary
actuators.
Stepper Motor - A DC electric motor that divides a full
rotation into a number of equal steps.
String - A variable, something the program “remembers”
2 4
3
A servo
Mechanism of a
stepper motor
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 40 of 54
APPENDICES
Appendix 1 (Leonardo’s Project Brief)
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 41 of 54
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 42 of 54
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 43 of 54
Appendix 2 (Sean’s LED Test):
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 44 of 54
Appendix 3 (Brian’s PCB Designs):
Transmitter Version 1:
Transmitter Version 2:
Receiver Version 1: Receiver Version 2:
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 45 of 54
Receiver version 3:
LED Driver Version 1:
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 46 of 54
Appendix 4 (Ed’s Code)
ARDUINO #include <Servo.h>
#define ultrasonicEcho 9
#define ultrasonicTrigger 8
long timeOne;
long timeTwo;
String serialHeadingAngle = "";
String serialPitchAngle = "";
String command;
Servo headingServo;
Servo pitchServo;
void setup(){
headingServo.attach(10);
pitchServo.attach(11);
pinMode(ultrasonicTrigger, OUTPUT);
pinMode(ultrasonicEcho, INPUT);
Serial.begin(9600);
Serial.setTimeout(0);
while (!Serial) {
headingServo.write(0);
pitchServo.write(90);
}
Serial.println("Connected");
}
void loop(){
while (Serial.available() > 0) {
command = Serial.readString();
if (command == "heading") {
Serial.print("Input Heading: ");
while (Serial.available() == 0) {
}
serialHeadingAngle = Serial.readString();
headingServo.write(serialHeadingAngle.toInt());
Serial.println(headingServo.read());
}
if (command == "pitch") {
Serial.print("Input Pitch: ");
while (Serial.available() == 0) {
}
serialPitchAngle = Serial.readString();
pitchServo.write(serialPitchAngle.toInt());
Serial.println(pitchServo.read());
}
if (command == "time") {
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 47 of 54
Serial.println("Measuring Times");
measure();
}
}
}
void measure() {
ping();
timeOne = pulseIn(ultrasonicEcho, HIGH, 60000); //400microseconds
for 12cm
timeTwo = pulseIn(ultrasonicEcho, HIGH, 400); //60000microseconds
for 20m
Serial.print("Time One: ");
Serial.println(timeOne);
Serial.print("Time Two: ");
Serial.println(timeTwo);
}
void ping() {
digitalWrite(ultrasonicTrigger, LOW);
delayMicroseconds(2);
digitalWrite(ultrasonicTrigger, HIGH);
delayMicroseconds(10);
digitalWrite(ultrasonicTrigger, LOW);
}
PI
import Tkinter, math, time, serial, atexit
from Tkinter import *
from math import *
backgroundColour = "Black"
foregroundColor = "Green"
sweeperRange = 500
heading = -1
pitch = 90
UISweeper = 0
trackedObjects =
{0:0,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:0,10:0,11:0,12:0,13:0,14:0,15
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 48 of 54
:0,16:0,17:0,18:0,19:0,20:0,21:0,22:0,23:0,24:0,25:0,26:0,27:0,28:0,
29:0,30:0,31:0,32:0,33:0,34:0,35:0,36:0,37:0,38:0,39:0,40:0,41:0,42:
0,43:0,44:0,45:0,46:0,47:0,48:0,49:0,50:0,51:0,52:0,53:0,54:0,55:0,5
6:0,57:0,58:0,59:0,60:0,61:0,62:0,63:0,64:0,65:0,66:0,67:0,68:0,69:0
,70:0,71:0,72:0,73:0,74:0,75:0,76:0,77:0,78:0,79:0,80:0,81:0,82:0,83
:0,84:0,85:0,86:0,87:0,88:0,89:0,90:0,91:0,92:0,93:0,94:0,95:0,96:0,
97:0,98:0,99:0,100:0,101:0,102:0,103:0,104:0,105:0,106:0,107:0,108:0
,109:0,110:0,111:0,112:0,113:0,114:0,115:0,116:0,117:0,118:0,119:0,1
20:0,121:0,122:0,123:0,124:0,125:0,126:0,127:0,128:0,129:0,130:0,131
:0,132:0,133:0,134:0,135:0,136:0,137:0,138:0,139:0,140:0,141:0,142:0
,143:0,144:0,145:0,146:0,147:0,148:0,149:0,150:0,151:0,152:0,153:0,1
54:0,155:0,156:0,157:0,158:0,159:0,160:0,161:0,162:0,163:0,164:0,165
:0,166:0,167:0,168:0,169:0,170:0,171:0,172:0,173:0,174:0,175:0,176:0
,177:0,178:0,179:0,180:0}
trailColour = {5:"#ff4000", 10:"#ff4000", 15:"#ff4000",
20:"#ff4000", 25:"#ff4000", 30:"#ff4000", 35:"#ff4000",
40:"#ff4000", 45:"#ff4000", 50:"#ff4000", 55:"#ff4000",
60:"#ff4000", 65:"#ff4000", 70:"#ff4000", 75:"#ff4000",
80:"#ff4000", 85:"#ff4000", 90:"#ff4000", 95:"#ff4000",
100:"#ff4000", 105:"#ff4000", 110:"#ff4000", 115:"#ff4000",
120:"#ff4000", 125:"#ff4000", 130:"#ff4000", 135:"#ff4000",
140:"#ff4000", 145:"#ff4000", 150:"#ff4000", 155:"#ff4000",
160:"#ff4000", 165:"#ff4000", 170:"#ff4000", 175:"#ff4000"}
preX = 500
preY = 500
Window = Tkinter.Tk()
Window.geometry("1400x500")
Window.title("Radar Display")
Window.configure(background=backgroundColour)
Display = Canvas(Window, width=1000, height=500,
bg=backgroundColour, highlightthickness=0) ##262a32
Display.pack()
Display.place(x=0, y=0)
Display.create_oval(0,0,2*sweeperRange,2*sweeperRange,
outline=foregroundColor)
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 49 of 54
Screen = Canvas(Window, width=400, height=500, bg=backgroundColour,
highlightthickness=0) ##262a32
Screen.pack()
Screen.place(x=1000, y=0)
USB = serial.Serial("/dev/cu.usbmodem1411", 9600)
print USB.readline().replace('\r\n', '')
def update():
global heading, pitch, UISweeper, preX, preY
Display.delete(UISweeper)
if heading == 180:
if pitch == 115:
setPitch(45)
pitch = 45
pitch = pitch + 5
setPitch(pitch)
setHeading(0)
heading = 0
time.sleep(1)
heading = heading + 1
scan(heading, pitch)
xSweeperCoordinate = sweeperRange -
500*cos(math.radians(heading))
ySweeperCoordinate = sweeperRange -
500*sin(math.radians(heading))
UISweeper = Display.create_line(500, 500, xSweeperCoordinate,
ySweeperCoordinate, fill=foregroundColor)
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 50 of 54
x = 500 -
50*distance*cos(math.radians(heading))*sin(math.radians(pitch))
y = 500 -
50*distance*sin(math.radians(heading))*sin(math.radians(pitch))
Display.create_line(x,y,preX,preY, fill=trailColour[pitch])
preX, preY = x,y
Display.delete(trackedObjects[int(heading)])
trackedObjects[int(heading)] = Display.create_oval(x-1,y-
1,x+1,y+1, fill="Green", width=0)
altitude = 250*sin(math.radians(pitch-90))
xDistance = 200*cos(math.radians(heading))
x2 = 200-xDistance
y2 = altitude + 250
colour = 190 - 190*distance*sin(math.radians(heading))
if colour < 0:
colour = 0
depth = "#%02x%02x%02x" % (colour, colour, colour)
Screen.create_rectangle(x2-1.1,y2+7.35,x2+1.1,y2-7.35,fill=depth,
outline=depth)
Window.after(50, update)
def setHeading(heading):
USB.write("heading")
time.sleep(0.001)
USB.write(str(heading))
print USB.readline().replace('\r\n', '')
def setPitch(value):
USB.write("pitch")
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 51 of 54
time.sleep(0.001)
USB.write(str(value))
print USB.readline().replace('\r\n', '')
def getTimes():
global distance
USB.write("time")
print USB.readline().replace('\r\n', '')
timeOne = int(USB.readline().replace('\r\n', '').replace("Time
One: ", ""))
timeTwo = int(USB.readline().replace('\r\n', '').replace("Time
Two: ", ""))
distance = 0.00024085 * timeOne #timeTwo not timeOne
def scan(heading, pitch):
setHeading(heading)
setPitch(pitch)
getTimes()
update()
Window.mainloop()
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 52 of 54
Appendix 5 (Whiteboard Image):
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 53 of 54
Appendix 6 (Week 1’s Minutes):
Merchiston Castle School working with Leonardo
EES 2017: Radar Page 54 of 54
“Engineers like to solve problems. If there are no problems handily available, they
will create their own problems.”
Scott Adams