chrislane / accudrop Goto Github PK
View Code? Open in Web Editor NEWA proof of concept Android skydiving app
License: GNU Affero General Public License v3.0
A proof of concept Android skydiving app
License: GNU Affero General Public License v3.0
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.
This task is done once the user can change which person is used as the central point for the radar.
When GPS is disabled, a dialogue box should appear, prompting the user to enable GPS.
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.
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.
The task is done once the user can successfully change values listed in the acceptance criteria.
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.
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.
[ ] Home
[ ] Landing pattern planner
[ ] Landing pattern playback
[ ] Add users to track
[ ] Logbook
[ ] Formation planner
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.
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.
The user goes to a jump statistics page and is greeted by useful and interesting information about their jumps.
The user can see correct details listed in the acceptance criteria.
In order to implement other features, we need speed to be calculated during jump tracking.
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
The user should be able to long press on the Google map to set their target landing location.
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.
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.
The task is complete when a sky image displays correctly in the background of the side view, scrolling the correct direction with movement.
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.
The sensor data such as GPS and barometer calculated altitude must be stored in a database with a timestamp for later retrieval and presentation.
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
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.
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.
The app must be able to correctly identify whether the user was in freefall or canopy flight.
The user wants to be able to view data from many different devices for a single skydive, showing different people's positions.
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.
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.
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.
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
As a person testing the altitude detection capabilities of a device, I must be able to see on the screen:
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.
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:
A test must be created to determine the accuracy of smart devices when compared to a normal skydiving altimeter.
I will create an app that I can put onto many Android devices with internal barometers. The app will have the following features:
I will need to borrow some devices for the testing in an attempt to test results from different hardware.
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.
The user should be able to see a landing pattern route that accurately displays how the landing pattern should be for current wind conditions.
This is complete when an appropriate landing pattern is calculated for current wind conditions and displayed on the landing pattern plan view.
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
A user wants to have features that can react based on distance to other users, such as when another canopy is too close.
The app can send and receive location data from other devices running the app.
The user rotates the display while on the replay screen.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.