chrislane / accudrop Goto Github PK

User Story

As a user, I would like to be able to switch between different people on the radar screen to view everyone else on the jump relative to the selected person.

Acceptance Criteria

• Can select users
• Radar recalculates with the selected user as the subject

Definition of Done

This task is done once the user can change which person is used as the central point for the radar.

User Story

When GPS is disabled, a dialogue box should appear, prompting the user to enable GPS.

Acceptance Criteria

• Dialog box opens informing the user of GPS being disabled.
• Button to guide the user to the "Location settings" page in Android.

Currently, we have a lot of AsyncTasks and it's all getting out of hand and rather messy. Since the majority of these are all for the Android Room queries, we should instead be using observers, especially since these will keep up-to-date with the data and react accordingly to lifecycle events.

User Story

A user can go to the preferences/settings screen to change values such as canopy airspeed/glide ratio, unit of measurement and landing pattern turn heights to better suit their needs.

Acceptance Criteria

• Canopy airspeed can be changed
• Canopy glide ratio can be changed
• Unit of measurement can be changed
• Landing pattern turn heights can be changed
• Current settings values are shown to the user

Definition of Done

The task is done once the user can successfully change values listed in the acceptance criteria.

User Story

The user should be able to go to a screen that will allow them to view their landing pattern from a jump. This will be displayed in several different views, one being a top-down view as an overlay on a map, others being views from different sides of the pattern. The user will be able to see what heights they were at from indicators shown on the patterns or by clicking different sections of the pattern.

Acceptance Criteria

• User is able to see their pattern in bird's eye view
• User can see what altitude each point in the route was at
• User is able to see their pattern from the side

Definition of Done

The user is able to view their landing pattern and use it for reflection on how to improve their landing pattern.

App interfaces must be designed as well as the interactions between them and their different states.

Interfaces

[ ] Home
[ ] Landing pattern planner
[ ] Landing pattern playback
[ ] Add users to track
[ ] Logbook
[ ] Formation planner

User Story

The user should be able to delete a jump in the middle of their entries. For example, if jumps 1,2,3,4,5 exist, the user should be able to delete jump 3 without breaking any features.

Acceptance Criteria

• Individual jumps can be deleted
• Deletion of a jump will reduce the jump numbers of jumps that followed by one
• Deletion of a jump does not cause any errors

Definition of Done

This task is done when a user can successfully delete a jump from their logs.

Currently, the app will hang with certain tasks being run such as generating a new jump, this is because much of the process is currently done on the main UI thread.

Code that runs for a long time needs to be moved from the main thread.

User Story

The user goes to a jump statistics page and is greeted by useful and interesting information about their jumps.

Acceptance Criteria

• Displays max vertical speed
• Displays max horizontal speed
• Displays max canopy horizontal speed
• Displays max canopy vertical speed
• Displays freefall time

Definition of Done

The user can see correct details listed in the acceptance criteria.

Description

In order to implement other features, we need speed to be calculated during jump tracking.

Acceptance Criteria

• Vertical speed is calculated from altitude readings
• Horizontal speed is calculated from GNSS readings

Definition of Done

The task is done when correct vertical and horizontal speeds are being calculated and logged.

Positions on the radar screen are currently slightly wrong.

Currently, the radar positions just scale to the shrinkage of a circle in the Y direction. Coordinates in a circle that is transformed into an ellipse should also move slightly in the X direction. Apparently, this can be done by using a 2x2 matrix.

Info on how to transform the coordinates here: https://math.stackexchange.com/questions/2638515/how-to-convert-points-in-a-circle-to-points-in-an-ellipse

User Story

The user should be able to long press on the Google map to set their target landing location.

Acceptance Criteria

• The user can long press to set a target location to where they pressed.
• Setting the target location will recalculate the route
• Setting the target location will update the map with an updated route

Definition of Done

Target location can be set by using a long press action, this updates all route calculations/drawings correctly in relation to the new location.

The listeners should not be in the view models, instead, we should call methods in the view models to update values.
This will also allow us to make these new classes for the listeners run as services on the device.

Much of the radar view data is currently being kept in the radar presenter, this is WRONG CHRISLANE!
Software engineering concepts and all that. Keep code clean, keep it keen?

The app should be able to calculate a landing pattern based on static inputs as a starting point.
The target location, turn heights, canopy speed and canopy glide ratio will be constants defined in code.

• Able to store GPS coordinates in a path
• Able to draw GPS coordinates on the map as path points
• Able to draw lines between path points

User Story

A user should see in the background of the side view, a sideways scrolling image of the sky when rotation is changed. This is to make it clearer what is happening when the view changes with rotation.

Acceptance Criteria

• A sky image is displayed in the background of the sky view
• The sky image scrolls to the right when the map is rotated clockwise
• The sky image scrolls to the left when the map is rotated anti-clockwise

Definition of Done

The task is complete when a sky image displays correctly in the background of the side view, scrolling the correct direction with movement.

• What is real-time processing
• How can we ensure that our app runs its processes first?
• Can we set the app to a higher process priority? What does this mean?

A general template for the app.

Currently, the app shows all positions in a route in the replay view, the replay view should instead be only for landing pattern replaying.

Historical jump coordinates must be drawn on top of a Google map in a line to create a view of the landing pattern that was recorded.

User Story

The sensor data such as GPS and barometer calculated altitude must be stored in a database with a timestamp for later retrieval and presentation.

Acceptance Criteria

• GPS coordinates and barometric altitude can be stored with a corresponding timestamp.
• GPS coordinates and altitude can be retrieved from storage.

Definition of Done

• Data can be stored and retrieved from the app.

Currently, the app crashes when changing the orientation of the device.

Crash log:
https://gist.github.com/ChrisLane/1f7d59feb32587b7fecd952ee798fe3f

The current implementation uses methods like getActivity to get the fragment owner activity, this could be set using onAttach instead.

Many methods created in a default Fragment from Android Studio should probably be used instead.

More info here: https://developer.android.com/training/basics/fragments/communicating.html

• Canopy shape
• Canopy size
• Canopy material
• User weight
• User height
• Temperature
• Wind speed

Currently, the UI is updated only once a final, finished result is produced e.g. when replaying a jump, all lines are drawn at the same time.
The app should instead update the UI of its progress in long tasks, e.g. adding a line to the replay map each time one has been calculated.

This should make the app seem more responsive.

Description

To accomplish this we must calculate the vertical speed of the user to determine whether they are likely in freefall or canopy flight, since the initial speed of the freefall may register as low, we must also take into account whether freefall has already occurred.

The speed of the user will be kept in the database with the positional data. Speed could be calculated in real-time however to reduce the load on the phone during a skydive and any delays that might be added to processing, calculating speeds at the end of a jump would be more ideal.

Acceptance Criteria

• Store vertical speed at all positions for a jump
• Store horizontal speed at all positions for a jump
• Infer whether the user is in freefall

Definition of Done

The app must be able to correctly identify whether the user was in freefall or canopy flight.

User Story

The user wants to be able to view data from many different devices for a single skydive, showing different people's positions.

Acceptance Criteria

The app must be able to synchronise time between the devices in some way so that data can be presented relative to each other or a single time source.

Definition of Done

The app can accurately display data that was collected at the same time on multiple devices that had differences in their internal clocks.

At first, I wanted to have one LocationListener implementing class that would be responsible for all location activities within the app.
Having realised that to do this, and have other classes listening on my location class would be re-inventing the wheel, I've decided to find another way to separate the concerns here.

Instead, I will have a location class that handles the addition/removal of LocationListeners and location requests, making the class in control overall but having all other classes requiring location handle their own code on location changes.

The replay screen must be able to show a side view of the landing pattern, with the top of the view being the start of the landing pattern and the bottom being the ground.

Lines should be drawn to show the user's position across longitude and latitude.

User Story

A user presses the 'Start Jump' button while on the ground, puts the device in their pocket and completes their skydive. When back on the ground, the user clicks 'Stop Jump' The user expects the app to not log useless data such as movement while on the ground or the plane journey up to the jump altitude, only their journey from the plane exit to the ground.

Acceptance Criteria

• App can detect the user exiting the plane
• The app begins jump logging features once the user exiting the plane has been detected
• The app finishes jump logging features once the user reaches ground level

Definition of Done

The app is able to successfully log jump data and not log data in any other situation.

• Communication

• Mesh network (Supported in Bluetooth 5.0)

• Parachuting

• Altitude

• Trajectory

• Increasing accuracy of vertical and horizontal position data

• Obstacle avoidance

User Story

As a person testing the altitude detection capabilities of a device, I must be able to see on the screen:

• A button to set the ground level calibration
• Barometer pressure readings
• Altitude from pressure readings
• Altitude from GPS

From these readings, I will be able to create a table showing variation in readings from different devices.

If possible, I would like all these features to work for an Android smartwatch, even if that is just to feed information from a watch back to a smartphone.

Acceptance Criteria

• All features display correctly on the screen
• Calibration button correctly sets the current pressure reading/GPS reading as the zero level
• Altitude correctly recalculates to 0ft when the calibration button is pressed

Definition of Done

The app is done when all features work and the app can be used for testing.

See lecture video's given to me by Alan.

The system must be able to:

• Store altitude, longitude and latitude as points in a route.
• Give accessibility to points that make up a route

User Story

Acceptance Criteria

Definition of Done

A test must be created to determine the accuracy of smart devices when compared to a normal skydiving altimeter.

Prerequisites

I will create an app that I can put onto many Android devices with internal barometers. The app will have the following features:

• Able to set ground level (zero the readings for the altitude algorithm) with a button
• Display the raw barometer pressure reading
• Display the altitude from both barometer and GPS readings

I will need to borrow some devices for the testing in an attempt to test results from different hardware.

Test Steps

1. Set ground level for all devices at bottom floor of tall building
2. Log pressure readings and heights from barometer and GPS for smart devices
3. Move up a couple of floors
4. Repeat steps 2 and 3 four more times if possible
5. Move to the top floor
6. Repeat step 2

Acceptance Criteria

• Title
• Project description
• Supervisor name
• Tools and Frameworks

Currently there is no tracking or logging if the app is put into the background or if the phone is locked.
To get the app working in the background for jump data tracking, the listeners must be started from an Android Service. To ensure that the OS doesn't close the service to improve performance etc., a Foreground Service will be used, which has a requirement of having a notification displayed while running so that the user is aware that it is running.

User Story

The user should be able to see a landing pattern route that accurately displays how the landing pattern should be for current wind conditions.

Acceptance Criteria

• The app can acquire wind direction and speed for the current landing target.
• The landing pattern calculated adjusts the ground speed value based on wind data and movement direction

Definition of Done

This is complete when an appropriate landing pattern is calculated for current wind conditions and displayed on the landing pattern plan view.

User Story

When the user goes to review their jump, if the app detected that another user was too close, the user should be notified of this potentially dangerous behaviour.

• Altitude Hardware (Barometer)

• Frequency (182 Hz)

• Accuracy (± 0.12 hPa equiv to ± 1m)
  Bluetooth pressure sensors on the market: https://www.blueflyvario.com/

• Horizontal/Altitude? Location Hardware (GPS)

• Frequency (19 Mhz? Couldn't find much info except maybe https://developer.qualcomm.com/qfile/28877/lm80-p0598-8_a_apq8064_gps_quality_minispec.pdf)

• Accuracy (Galileo 1-4m)

• Behaviour at altitude (No info)

• Communication Hardware (WiFi Direct, Bluetooth, Radio)

• Range

• Transfer rate

• Reliability

User Story

A user wants to have features that can react based on distance to other users, such as when another canopy is too close.

Acceptance Criteria

• The app can communicate with other devices to share location data
• The app cycles communication through nearby users collecting data

Definition of Done

The app can send and receive location data from other devices running the app.

User Story

The user rotates the display while on the replay screen.

Acceptance Criteria

• Rotate replay elements in-place when device changes to landscape