Revision as of 18:53, 20 February 2019

Organization

The group composition, deliverables, milestones, planning and task division can be found on the organization page.

Brainstorm

To explore possible subjects for this project, a brainstorm session was held. Out of the various ideas, the Follow-Me Drone was chosen to be our subject of focus.

Problem Statement

The ability to navigate around one’s environment is taken for granted by most humans and often not seen as a difficult or complex task. And this does not even necessarily have to concern complex orientation challenges in an unknown environment, but much simpler: Just the ability to read a map and follow a route. Similarly, the skill to remember how to get to one’s favourite cafe. These kind of tasks require complex activities in our brains, which causes the very broad skill of ‘navigation’ to be present in humans in very diverse skill levels. People who’s navigation skills fall on the lower end of the scale, do seem to be slightly troubled in their everyday life - it might take them substantially longer than others to be able to find their way to work just by remembering the route or they might get lost in new environments every now and then. However, it is important to note, that this is a dynamic grey-scale; there is no line between ‘good’ and ‘bad’ navigation.

Navigation skills can be traced back to certain distinct cognitive processes (however, to a limited extent, as the field of neurosciences is still to be developed further [1]), which means that a lesion in specific brain regions can cause a human’s navigational abilities to decrease dramatically. This was found in certain case studies with patients that were subject to brain damage, and labeled “Topographical Disorientation” (TD), which can affect a very broad range of navigation tasks [2]. Within the last decade, cases started to show up, in which people showed similar symptoms to patients with TD, however, they did not suffer any brain damage and were normally functioning in all other aspects. This disorder was termed “Developmental Topographical Disorientation” (DTD) [3], which, as was recently discovered, might affect 1-2% of the world's population (it is important to note that this is an estimate based on studies and surveys) [4].

Many of the affected people can not rely on map-based navigation and even sometimes get lost on everyday routes. To make those people’s everyday life easier, one solution might be to use a drone. The idea of the playfully-named “follow-me drone” is simple: By flying in front of its user, accurately guiding them to a desired location, the drone takes over the majority of a human’s cognitive wayfinding tasks.This makes it easy and safe for people to find their destination with minimized distraction and cognitive workload of navigation tasks.

The first design of the “follow-me drone” will be mainly aimed at severe cases of TD, with the goal of giving those people a little bit of their independence back. This means that the design incorporates features that might make the drone more valuable to its user with repeated use and is not only thought-of as a product for rare or even one-time use as part of a service.

User

Society

The societal aspect of the follow-me drone regards the moral standpoint of society towards cognitively-impaired individuals. Since impairments should not create insuperable barriers in the daily life of affected people, it can be seen as a service to society as a whole to create solutions which make it easier to live—even if that solution only helps a small fraction of the world's population.

Enterprise

Since this solution is unique in its concept and specifically aimed at a certain user group, producing the drone is a worthy investment opportunity. However, the focus should always stay on providing the best possible service to the end-users. User-centered design is a key to this development.

Approach

In order to get to a feasible design solution, we will do research and work out the following topics:

User requirements
- Which daily-life tasks are affected by Topographical Disorientation and should be addressed by our design?
- What limitations does the design have to take into account to meet the requirements of the specified user base?
Human technology interaction
- What design factors influence users’ comfort with these drones?
- Which features does the technology need to incorporate to ensure intuitive and natural guiding experiences?
  - How to maximise salience of the drone in traffic?
  - What velocities, distances and trajectories of the drone will enhance the safety and satisfaction of users while being guided?
- Which kind of interfaces are available in which situations for the user to interact with the drone?
User tracking
- How exact should the location of a user be tracked to be able to fulfill all other requirements of the design?
- How will the tracking be implemented?
Positioning
- How to practically implement findings about optimal positions and trajectories?
Obstacle avoidance
- What kind of obstacle avoidance approaches for the drone seem feasible, given the limited time and resources of the project?
- How to implement a solution for obstacle avoidance?
Special circumstances
- What limitations does the drone have in regards to weather (rain, wind)?
- How well can the drone perform at night (limited visibility)?
Physical design
- What size and weight limitations does the design have to adhere to?
- What sensors are needed?
- Which actuators are needed?
Simulation

Solution

Here we discuss our solution. If it exists of multiple types of sub-problems that we defined in the problem statement section, then use separate sections (placeholders for now).

Human factors

Drones are finding more and more applications around our globe and are becoming increasingly available and used on the mass market. In various applications of drones, an interaction with humans who might or might not be involved in the task that a drone carries out, is inevitable and sometimes even the core of the application. Even though drones are still widely perceived as dangerous or annoying, there is a common belief that they will get more socially accepted over time.[5] However, since the technology and therefore the research on human-drone interaction is still very new, our technology should incorporate as many human factors as deemed necessary, without assuming general social acceptance of drones.

The next sections will focus on different human factors that will influence our drone’s design with different goals. This will include the drone’s physical appearance and its users’ comfort with it, safety with respect to its physical design, as well as functionality-affecting factors which might contribute to a human's ability to follow the drone. Additionally, factors contributing to a satisfying overall experience will be considered.

Physical appearance

Here, the close physical appearance of the drone and its users affect for it will be discussed.

Safety

The safety section will cover topics like the minimum distance it should keep to its user and eventually physical design guidelines to be able for users to handle the drone safely.

Salience in traffic

As our standard use case described, the drone is aimed mostly at application in traffic. It should be able to safely navigate its user to his destination, no matter how many other vehicles, pedestrians or further distractions are around. A user should never get the feeling to be lost while being guided by our drone.

To reach this requirement, the most direct solution is constant visibility of the drone. Since human attention is easily distracted, also conspicuity, which describes the property of getting detected or noticed, is an important factor for users to find the drone quickly and conveniently when lost out of sight for a brief moment. However, the conspicuity of objects is perceived similarly by (almost) every human brain, which introduces the problem of unwillingly distracting other traffic participants with an overly conspicuous drone. We will focus on two factors of salience and conspicuity:

Color

The color characteristics of the drone can be a leading factor in increasing the overall visibility and conspicuity of the drone. The more salient the color scheme of the drone proves to be, the easier it will be for its user to detect it. Since the coloring of the drone alone would not emit any light itself, we assume that this design decision does not highly influence the distraction factor for other traffic participants.

Choosing a color does seem like a difficult step in a traffic environment, where many colors have meanings that many humans take for granted. We would not want the drone to be confused with any traffic lights or street signs, since that would lead to serious hazards. But we would still need to choose a color that is perceived as salient as possible. Stephen S. Solomon conducted a study about the colors of emergency vehicles [6]. And the results of the study were based upon what was found out about the human visual system: It is most sensitive to a specific band of colors, which involves ‘lime-yellow’. Therefore, as the study showed, lime-yellow emergency vehicles were involved in less traffic accidents, which does indeed let us draw conclusions about the conspicuity of the color. This leads us to our consideration for lime-yellow as base color for the drone. Furthermore, color contrasts are going to be discussed here.

Luminosity

The luminosity section will treat the application of reflectors and lights on the drone, maximising visibility but minimising unwilling conspicuity for other road users.

Positioning in the visual field

The positioning of the drone will be as valuable for a user as it will be a challenge to correctly derive. The drone should not deviate too much from its usual height and position within its users attentional field, however, it might have to avoid obstacles, wait and make turns without confusing the user.

User satisfaction and experience design

A user should feel comfortable using this technology. This section will treat how this could be achieved and how a user’s satisfaction with the experience could be increased.

Legal Issues

In this project, a flying drone is designed to move autonomously through urban environments to guide a person to their destination. It is important however to first look at relevant legal issues. In the Netherlands, laws regarding drones are not formulated in a clear way. There are two sets of laws: recreational-use laws and business-use laws. It is not explicitly clear which set of laws applies to this project if any at all. The drone is not entirely intended for recreational use because of its clear necessity to the targeted user group. On the other hand, it does not fall under business use either it is not “used by a company to make money”---this does not include selling it to users. In that case, it is in the users’ ownership and is no longer considered used by the company. If the drone is rented, however, it still might fall under business use. In conclusion, neither set of laws applies to our project. Since drones are not typically employed in society, this is not unexpected and we might expect new laws to adapt to cases such as ours.

According to law, drone users are not allowed to pilot drones above residential areas regardless of their use. Our drone, however, flies through residential areas for its intended purpose, not above them.

Legislation is subject to change that can be in accordance with our project as well as against it. That being said, we can safely design our drone as intended without worrying about legislation. Our design does not explicitly violate any laws.

Technical considerations

Battery life

One thing to take in consideration while developing a drone is the operating duration. Most commercial drones can not fly longer than 30 minutes (link,link). This is not a problem for a walk to the supermarket around the block but if the user would want to go a bit further away, longer battery life would be preferred. This is certainly possible since drones do exist that can fly longer time spans but these are not (yet) commercially available. The world record for longest drone flight time is just over 4 hours (link) but this drone was specifically built for the record attempt and is not ideal for flying through residential areas. Another design for a drone exists that has a battery life of up to 2 hours and an action radius of 75km (link). This drone is designed for more extreme conditions and may be bit pricey at $7000. However these designs show that it should definitely be possible to design a drone that can fly long enough. In order to do this a battery pack should be specifically designed for the drone.

Battery packs consist of several battery cells. The power in the cell comes from redox reactions between the reaction components. Redox reactions supply a standard voltage. For example the nominal voltage of Lithium based battery cells is about 3.6V while for nickel based battery cells this is about 1.2V (link). If a higher voltage is needed several cells can be placed in series and their voltage is combined. If the required voltage is not a multiple of the nominal voltage a voltage regulator is needed. The flight time of the drone mainly depends on the capacity of the battery. The capacity depends on the build and size of the battery. If multiple batteries are placed in parallel, the capacities can be added. The maximum sustainable current goes up as well. However there is a trade of between supplied current and battery operation time. The battery capacity is usually stated in units of mAh. A battery with 1000 mAh can supply a current of 1000mA or 1A for one hour but a current of 10A only for 6 minutes.

Since the different possible redox reactants have different effects it is important to look at the different properties. In drones Lithium based batteries have by far the highest energy density (link) but are not as inexpensive as nickel-based alternatives. However since more battery weight means more power required, the low energy density is probably more important here. Furthermore lithium-based batteries have a lower self discharge rate which is the rate at which energy drains even when not in use. Two lithium types of batteries are available: lithium-ion and lithium-polymer (LiPo). LiPo variants are generally a little bit less expensive and have a longer lifespan. Therefore for this project a LiPo battery is chosen.

For the design of the battery pack a few things should be known. First the required amount of energy is needed. This can be calculated from the following formula:

$[math]\displaystyle{ E_\lt motors\gt = n_{motors} \cdot U_{m} \cdot I_{m} \cdot t_{fly} }[/math]$

With $[math]\displaystyle{ n_{motors} }[/math]$ the amount of motors, $[math]\displaystyle{ U_m }[/math]$ the required motor voltage, $[math]\displaystyle{ I_m }[/math]$ the required motor current and $[math]\displaystyle{ t }[/math]$ the flight time. The amount of energy stored in the battery packs can be calculated with the following formula:

$[math]\displaystyle{ E_\lt supplied\gt =U_{total} \cdot C_{total} = U_c \cdot n_s \cdot C_c \cdot n_p }[/math]$

With $[math]\displaystyle{ U_c }[/math]$ the voltage per cell, $[math]\displaystyle{ C_c }[/math]$ the capacity per cell, $[math]\displaystyle{ n_s }[/math]$ the amount of cells connected in series and $[math]\displaystyle{ n_p }[/math]$ the amount of cells connected in parallel.

Apart from this the required voltage and current for the motors is needed. When this is known first the amount of batteries connected in series should be determined to supply the right voltage. Then a battery cell should be chosen that can deliver the required input current. If none can, multiple cells should be connected in parallel. Lastly the total amount of cells for the required amount of energy should be calculated. All extra cells should be connected in parallel.

User Interface Design

The user interacts with the drone via multiple interfaces. Here we list the specific design elements and dynamics of each of these interfaces. Natural Language User Interface to answer questions, make recommendations on desired destinations and changing route mid flight, and perform actions. A graphical user interface through a web page that provides enter or change the destination and current location, add favorite locations for quick access. Allows user to change the altitude of the drone, stop and start the drone.

Obstacle avoidance

In order for a drone to navigate effectively through an urban environment, it must circumvent various obstacles that such an environment entails. To name some examples: traffic lights, trees and tall vehicles may form an obstruction for the drone to follow its route. To solve this problem, we will apply a computationally simple method utilizing a potential field [7].

The goal of this method is to continuously adjust the drone’s flightpath as it moves towards a target, so that it never runs in to any obstacles. For this subproblem, we assume the position and velocity of the drone, target and obstacles are known.

The potential field is constructed using attractive and repulsive potential equations, which pull the drone towards the target and push it away from obstacles. The attractive and repulsive potential fields can be summed together, to produce a field guides the drone past multiple obstacles and towards the target.

We consider potential forces to work in the x, y and z dimensions. To determine the drone’s velocity based on the attractive and repulsive potentials, we use the following functions:

$[math]\displaystyle{ p_d^{att}(q_d, p_d) = \lambda_1 d(q_d, q_t) + p_t + \lambda_2 v(p_d, p_t)\\ p_d^{rep}(q_d, p_d) = -\eta_1 \dfrac{1}{d^3(q_o, q_d)} - \eta_2 v(p_o, p_d) }[/math]$

where $[math]\displaystyle{ \lambda_1, \lambda_2, \eta_1, \eta_2 }[/math]$ are positive scale factors, $[math]\displaystyle{ d(q_d, q_t) }[/math]$ is the distance between the drone and the target and $[math]\displaystyle{ v(p_d, p_t) }[/math]$ is the relative velocity of the drone and the target. Similarly, distance and velocity of an obstacle $[math]\displaystyle{ o }[/math]$ are used.

There may be multiple obstacles and each one has its own potential field. To determine the velocity of the drone, we sum all attractive and repulsive velocities together:

$[math]\displaystyle{ p_d(q_d, p_d) = p_d^{att} + \sum_o p_d^{rep} }[/math]$

User Tracking

It should be clear that tracking the user is a large part of the software for the Follow-Me drone.We present Python code that can be used with a webcam as well as normal video files, which can use various tracking algorithms.

Tracker Comparisons

Here we give a (short) overview of the different trackers used and their performance with respect to obstacles and visibility. The videos that were used were taken from [8]. The overview will be on a video-basis, that is, we discuss different trackers in terms of each video used.

Initial comparison --- american_pharoah.mp4

This video is from a horse race. For each tracker we selected the horse in the first position at the start of the video as object to be tracked. During the video, the horse racers take a turn, making the perspective change. There are also small obstacles.

BOOSTING tracker: The moment that there is a white pole (obstacle), it completely loses track of its target. This tracker cannot be used to keep track of the target when there are obstacles. It can, however, be used in parallel, sending a signal that the drone is no longer in line of sight with the user.
MIL tracker: Manages to keep track of the box despite the obstacles. It runs at around 4 to 5 FPS in general, so it might be too slow to apply. It is however fairly accurate.
KCF tracker: Similarly to the BOOSTING tracker, the KCF tracker cannot handle obstacles. It is however very fast compared to both BOOSTING and MIL. Hence, for sending a signal that the drone is no longer in line of sight can be done with KCF instead of BOOSTING.
TLD tracker: This tracker, while initially thought to be well-performing, runs extremely slow at 2 to 4 FPS. It is inferior to the MIL tracker in every possible way (for this video). Furthermore, there are many false positives, making this a bad choice.
MEDIANFLOW tracker: This tracker behaved nearly identical to the KCF tracker; The moment when there is a slight obstacle, it fails to detect and continues to fail. It could be used instead of KCF to signal when a user is no longer in line of sight.
MOSSE tracker: Even though it is not formal, sharing our initial notes (slightly edited to avoid cursing) on the MOSSE tracker best describes it: <quote>Whoa are you serious?! Runs at a minimum of 500 FPS (e.g. real-time) and can track the selection perfectly?? This is beautiful. Even the camera-shake is no problem. Changing the perspective is no problem either. This seems like the one to use for now</quote>. Clearly, the MOSSE tracker performs extremely well.
CSRT tracker: The moment that there is an obstacle, it follows the obstacle. During the rest of the video, it tries to recover but fails spectacularly, tracking random parts on top of the video.

At this point it has been decided that only the MIL, TLD and MOSSE trackers can be used for actual tracking purposes. For the next video, only these trackers were compared as a final comparison, even though it should be clear that MOSSE is the best one for our use case.

Final comparison --- dashcam_boston.mp4

This video is taken from a dashcam in a car, in snowy conditions. The car starts off behind a traffic light, then accelerates and takes a turn. The object to track has been selected to be the car in front.

MIL tracker: Starts off tracking correctly. Runs slow (4-5 FPS). Does not care about the fact that there is snow (visual impairment) or the fact that the camera angle is constantly changing in the turn. Can perfectly deal with the minimal obstacles occuring in the video.
TLD tracker: It runs both slower and inferior to MIL. There are many false positives. Even a few snowflakes were sometimes selected as object-to-track.
MOSSE tracker: Unsurprisingly, the MOSSE tracker runs at full speed and can track without problems. It does, however, make the bounding box slightly larger than initially indicated

Tracker conclusion

It's pretty clear that the MOSSE tracker is by far the best one. For the remaining videos, we are simply going to run MOSSE and write down any things that it does weird.

drone.mp4: This is footage from a drone following a car. MOSSE has no problems whatsoever tracking the car.
nascar_01.mp4: Video of a car race at high speed. The bounding box does not stay correct, but it flawlessly tracks the selected car (both one that stays in view as one that leaves the view).
nascar_02.mp4: Identical video to nascar_01. No comments needed.
race.mp4: Video of people running on a track. There are no real tracking problems.

As can be read, the MOSSE tracker performs well. Using a webcam, selecting various objects to be tracker, the MOSSE tracker can track anything without too many problems. As far as tracking where the user is, MOSSE is the way to go. There is, however, one caveat. The MOSSE tracker (and any other tracker) fails to track one of two very similar objects.

Line of Sight

Whereas the experimental evaluation of the trackers was done to find one that can continue to track even with bad visibility or obstacles, there is also a need of some piece of code that can say when the drone is no longer in line of sight of the user. Instead of coming up with a clever computer vision algorithm to do so, we can simply use one of the trackers that performs bad on tracking the user when there are obstacles. Whenever said tracker (which is going to be KCF) says that it can no longer track the object, which is the user, then we can state that the drone is no longer in line of sight. The reason why KCF was chosen over BOOSTING, is because it is the better tracker in general.

User Height Computation

We describe why an implementation would need some information that was not present in dorm-conditions and how to possibly overcome that.

Height estimation and (relative) distance estimation may seem like two separate things, but one is needed for the other as we will show in this part of the wiki. First we will talk about user height estimation.

In order for the (software of the) drone to estimate the height of the user, which is needed in order to find the correct flying place, we need rather many pieces of information. Firstly, there is the type of lens used in the camera on the drone. We are going to assume it is a rectilinear lens, since the majority of lenses made are rectilinear [9]. Note that the following calculations are also possible for other types of lenses, though may vary.

As shown on the diagram, there are various parameters that play a role in height computation:

$[math]\displaystyle{ h_{sensor} }[/math]$ : The height of the sensor.

The height of the sensor is generally unknown. It can, however, be computed rather easily in terms of the sensor’s pixel-size (which should be on the spec sheet of a well documented camera) and the resolution of the image (which can be very easily found using an OpenCV function) [10].

$[math]\displaystyle{ h_{obj} }[/math]$ : The height of the object in pixels as shown in the image (video).

While this piece of information (or parameter) is unknown, we can simply set it equal to the bounding box that is returned by an object tracker.

$[math]\displaystyle{ f }[/math]$ : The distance from the lens to the sensor (focal length).

The focal length should be visible on the spec sheet of a well documented lense-camera system. If not, it can be computed, but it requires item 6, the distance from the lens to the object in order to be computed [11].

$[math]\displaystyle{ \alpha }[/math]$ : The angle of the lense.

While this is not necessarily a parameter, it is helpful to be mentioned. Alpha is the (vertical) angle that the lens makes. This will not be the same for every type of lense, hence our assumption that the lense is rectilinear. Furthermore, it is used to compute the FOV (Field of View) as will be shown later.

$[math]\displaystyle{ \theta }[/math]$ : The angle that the object takes up.

This will be factored out as shown later in the computation.

$[math]\displaystyle{ D }[/math]$ : The distance from the lens to the object (user)

The distance from the lens to the object is unknown. There are broadly speaking two possible ways to get this distance. Firstly, there is computer vision. Using an object marker, one can compute the distance to said marker given two major unknown parameters:

The size of the object marker (it needs to be a known object).
The distance that the camera was when it registered the object marker.

Clearly, this is not feasible, leaving only option two. [12] This means that one should use sonar to estimate the depth [13]. The linked paper explains in great detail how it works, but mentions that it is a slow algorithm. Luckily, it also mentions that is has been implemented in Matlab, and since matlab is very slow when compared to C++ [14] it is fair to assume that, when implementing in C++, the used algorithm as proposed in the paper is fast enough to compute the distance every 5 seconds.

$[math]\displaystyle{ H_{obj} }[/math]$ : The (real-world) height of the object (user).

This is what you want to know.

$[math]\displaystyle{ H_{scene} }[/math]$ : The (real-world) height of the scene (image).

This is irrelevant to the computation, but mentioned for completeness sake.

As for the computation, one starts with rewriting the angles in radians, leading to following equations.:

$[math]\displaystyle{ D \cdot \theta = H_{obj} (1) }[/math]$
$[math]\displaystyle{ f \cdot \theta = h_{obj} (2) }[/math]$

Using (1) and (2) to factor out $[math]\displaystyle{ \theta }[/math]$ gives:

$[math]\displaystyle{ \frac{D}{f} \cdot h_{obj} = H_{obj} (3) }[/math]$

Note that in (3) the unit of $[math]\displaystyle{ h_{obj} }[/math]$ is in pixels, whereas the unit of $[math]\displaystyle{ H_{obj} }[/math]$ is assumed to be in the metric system. Converting pixels to millimeters is done as follows:

$[math]\displaystyle{ h_{obj}(mm) = \frac{h_{obj}(px)}{h_{sensor}(px)} \cdot h_{sensor}(mm) (4) }[/math]$

Rewriting (3) and (4) gives the following (rewriting focal length to mm):

$[math]\displaystyle{ D \cdot \frac{h_{obj}(px)}{h_{sensor}(px)} \cdot \frac{h_{sensor}(mm)}{f(mm)} = H_{obj} (5) }[/math]$

Using (5), depending on which information you have available, you can compute $[math]\displaystyle{ H_{obj} }[/math]$ directly. Otherwise, some more work is needed (especially if $[math]\displaystyle{ f }[/math]$ is unknown):

$[math]\displaystyle{ \frac{h_{sensor}(mm)}{f(mm)} = \alpha(radians) (6) }[/math]$

This is, as can be seen in (6) where $[math]\displaystyle{ \alpha }[/math]$ comes in. Note again that this means the vertical angle that the lense makes, in other words, the vertical Field of View ( $[math]\displaystyle{ \alpha = V_{FOV} }[/math]$ ). Note that you may have to convert between radians and degrees as needed. Finally, rewriting (5) using (6) gives.

$[math]\displaystyle{ H_{obj} = D \cdot \frac{ h_{obj}(px)}{h_{sensor}(px)} \cdot V_{FOV}(radians) (7) }[/math]$

Using (possible parts of) these 7 equations, one can compute the height of an object, thus of a user.

PRE2018 3 Group11: Difference between revisions

Revision as of 18:53, 20 February 2019

Contents

Organization

Brainstorm

Problem Statement

User

Society

Enterprise

Approach

Solution

Human factors

Physical appearance

Safety

Salience in traffic

Positioning in the visual field

User satisfaction and experience design

Legal Issues

Technical considerations

Battery life

User Interface Design

Obstacle avoidance

User Tracking

Tracker Comparisons

Initial comparison --- american_pharoah.mp4

Final comparison --- dashcam_boston.mp4

Tracker conclusion

Line of Sight

User Height Computation

Simulation

Conclusion

Navigation menu

PRE2018 3 Group11: Difference between revisions

Revision as of 18:53, 20 February 2019

Organization

Brainstorm

Problem Statement

User

Society

Enterprise

Approach

Solution

Human factors

Physical appearance

Safety

Salience in traffic

Positioning in the visual field

User satisfaction and experience design

Legal Issues

Technical considerations

Battery life

User Interface Design

Obstacle avoidance

User Tracking

Tracker Comparisons

Initial comparison --- american_pharoah.mp4

Final comparison --- dashcam_boston.mp4

Tracker conclusion

Line of Sight

User Height Computation

Simulation

Conclusion

Navigation menu

Search