mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 07:06:38 +00:00
update 1.2 prompt
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -1,6 +1,6 @@
|
||||
System should find out GPS of centers of 80% of the photos from the flight within error no more than 50 meters in comparison to the real GPS
|
||||
System should find out GPS of centers of 60% of the photos from the flight within error no more than 10 meters in comparison to the real GPS
|
||||
System should correctly continue the work even in a presence of up to 350 meters outlier photo between 2 consecutive photos en route. This could happen due to tilt of the plane.
|
||||
System should correctly continue the work even during sharp turns, where the next photo doesn't overlap at all, or overlaps in less than 5%. Next photo should be in less than 150m drift and angle less than 50%
|
||||
Number of outliers during the satellite provider images ground check should be less than 10%
|
||||
In case of absolute incapable of the system to determine next, second next, and third next images gps, by any methods, (these 20% of the route), then it should ask user for an input for the next image, so that user can specify location
|
||||
- System should find out GPS of centers of 80% of the photos from the flight within error no more than 50 meters in comparison to the real GPS
|
||||
- System should find out GPS of centers of 60% of the photos from the flight within error no more than 10 meters in comparison to the real GPS
|
||||
- System should correctly continue the work even in a presence of up to 350 meters outlier photo between 2 consecutive photos en route. This could happen due to tilt of the plane.
|
||||
- System should correctly continue the work even during sharp turns, where the next photo doesn't overlap at all, or overlaps in less than 5%. Next photo should be in less than 150m drift and angle less than 50%
|
||||
- Number of outliers during the satellite provider images ground check should be less than 10%
|
||||
- In case of absolute incapable of the system to determine next, second next, and third next images gps, by any methods, (these 20% of the route), then it should ask user for an input for the next image, so that user can specify location
|
||||
@@ -1,9 +1,9 @@
|
||||
Photos are taken by only airplane type UAVs.
|
||||
Photos are taken by the camera pointing downwards and fixed, but it is not autostabilized.
|
||||
The flying range is restricted by eastern and southern part of Ukraine (To the left of Dnipro river)
|
||||
The image resolution could be from FullHd to 6252*4168
|
||||
Altitude is prefefined and no more than 1km
|
||||
Flights are done mostly in sunny weather
|
||||
We can use satellite providers, but we're limited right now to Google Maps, which could be possibly outdated for some regions
|
||||
Number of photos could be up to 3000, usually in 500-1500 range
|
||||
During the flight UAV can make sharp turns, so that it is possible that next photo is absolutely different from the previous one (no same objects), but it is rather exception than the rule
|
||||
- Photos are taken by only airplane type UAVs.
|
||||
- Photos are taken by the camera pointing downwards and fixed, but it is not autostabilized.
|
||||
- The flying range is restricted by eastern and southern part of Ukraine (To the left of Dnipro river)
|
||||
- The image resolution could be from FullHd to 6252*4168
|
||||
- Altitude is prefefined and no more than 1km
|
||||
- Flights are done mostly in sunny weather
|
||||
- We can use satellite providers, but we're limited right now to Google Maps, which could be possibly outdated for some regions
|
||||
- Number of photos could be up to 3000, usually in 500-1500 range
|
||||
- During the flight UAV can make sharp turns, so that it is possible that next photo is absolutely different from the previous one (no same objects), but it is rather exception than the rule
|
||||
@@ -7,68 +7,111 @@
|
||||
We have wing type UAV (airplane). It should fly autonomously to predetermined GPS destination. During the flight it is relying on the signal form GPS module.
|
||||
But when adversary jam or spoof GPS, then UAV either don't know where to fly, or fly to the wrong direction.
|
||||
So, we need to achieve that UAV can fly correctly to the destination without GPS or when GPS is spoofed. We can use the camera pointing downward and other sensor data like altitude, available form the flight controller. Airplane is running Ardupliot.
|
||||
- `restrictions.md`: Restrictions we have in real world. For example:
|
||||
|
||||
- `docs/00_problem/input_data`: Put to this folder all the necessary input data and expected results for the further tests. For example:
|
||||
- orthophoto images from the UAV for the analysis
|
||||
- list of expected GPS for the centers for each picture in csv format: picture name, lat, lon
|
||||
- video from the UAV for the analysis
|
||||
- list of expected GPS for the centers of video per timeframe in csv format: timestamp, lat, lon for each 1-2 seconds of the
|
||||
- ...
|
||||
Analyze very thoroughly input data and form system's restrictions and acceptance ctiteria
|
||||
|
||||
- `restrictions.md`: Restrictions we have in real world in the -dashed list format. For example:
|
||||
- We're limiting our solution to airplane type UAVs.
|
||||
- Additional weight it could take is under 1 kg.
|
||||
- The whole system should cost under $2000.
|
||||
- The flying range is restricted by eastern and southern part of Ukraine. And so on.
|
||||
- `acceptance_criteria.md`: Acceptance criteria for the solution. For example:
|
||||
|
||||
- `acceptance_criteria.md`: Acceptance criteria for the solution in the -dashed list format.
|
||||
The most important part, determines how good the system should be. For example:
|
||||
- UAV should fly without GPS for at least 30 km in the sunshine weather.
|
||||
- UAV shoulf fly with maximum mistake no more than 40 meters from the real GPS
|
||||
- UAV should fly correctly with little foggy weather with maximum mistake no more than 100 meters from the real GPS
|
||||
- UAV should fly for minimum of 500 meters with missing inernal Satellite maps and the drifting error should be no more than 50 meters.
|
||||
- `docs/00_problem/input_data`: Put to this folder all the necessary input data for the further tests. For example:
|
||||
- orthophoto images from the UAV for the analysis
|
||||
- initial gps
|
||||
- ...
|
||||
|
||||
## 1.2 **✨AI Research**: Research acceptance criteria in great detail
|
||||
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
||||
**📝prompt:**
|
||||
For the problem:
|
||||
`docs/00_problem/problem_description.md`
|
||||
with restrictions:
|
||||
`docs/00_problem/restrictions.md`
|
||||
check how realistic these acceptance criteria are:
|
||||
`docs/00_problem/acceptance_criteria.md`
|
||||
Check how critical is each criteria. Also find out more acceptance criteria for this specific domain.
|
||||
Research impact of each value in acceptance criteria to the whole system quality.
|
||||
Assess acceptable ranges for each value in each acceptance criteria in the state of the art solutions, and propose corrections in form:
|
||||
- state of the art solutions' value ranges : our value ranges
|
||||
|
||||
## 1.2 **✨AI Research**: Restrictions and Acceptance Criteria assesment
|
||||
Form the next prompt:
|
||||
- Replace *.md to the corresponding content
|
||||
- Add sample files to the prompt
|
||||
- Put proper sample filenames in the text of the prompt
|
||||
and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
||||
**📝prompt template:**
|
||||
We have this problem:
|
||||
|
||||
Form the new acceptance criteria based on your research.
|
||||
`docs/00_problem/problem_description.md`
|
||||
|
||||
System should process this data samples:
|
||||
|
||||
`sample1.jpg`, `sample2.jpg`, `coordinates.csv`, ...
|
||||
|
||||
We have next restrictions for the input data:
|
||||
|
||||
`docs/00_problem/restrictions.md`
|
||||
|
||||
Output of our system should meet these acceptance criteria:
|
||||
|
||||
`docs/00_problem/acceptance_criteria.md`
|
||||
|
||||
Check how realistic these acceptance criteria are.
|
||||
Check how critical is each criterion. Also find out more acceptance criteria for this specific domain.
|
||||
Research impact of each value in acceptance criteria to the whole system quality.
|
||||
Assess acceptable ranges for each value in each acceptance criteria in the state of the art solutions, and propose corrections in the next table:
|
||||
- Acceptance criterion name
|
||||
- Our values
|
||||
- Your researched criterion values
|
||||
- Status: Is criterion was added by your research to our system, or modified, or removed, cause not necessary
|
||||
Also asses restrictions we've put for the system. Are they realistic? Propose corrections in the next table:
|
||||
- Restriction name
|
||||
- Our values
|
||||
- Your researched restriction values
|
||||
- Status: Is restriction was added by your research to our system, or modified, or removed, cause not necessary
|
||||
|
||||
**👨💻Developers**: Revise the result, discuss them and overwrite `docs/00_problem/acceptance_criteria.md`
|
||||
|
||||
|
||||
## 1.3 **✨AI Research**: Research the problem in great detail
|
||||
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
||||
**📝prompt:**
|
||||
Research the problem:
|
||||
`docs/00_problem/problem_description.md`
|
||||
We need to achieve this goal:
|
||||
`docs/00_problem/goal.md`
|
||||
Final solution should meet the acceptance criteria:
|
||||
`docs/00_problem/acceptance_criteria.md`
|
||||
The whole system has following limitations:
|
||||
`docs/00_problem/restrictions.md`
|
||||
Form the next prompt:
|
||||
- Replace *.md to the corresponding content
|
||||
- Add sample files to the prompt
|
||||
- Put proper sample filenames in the text of the prompt
|
||||
and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
||||
**📝prompt template:**
|
||||
Research this problem:
|
||||
|
||||
`docs/00_problem/problem_description.md`
|
||||
|
||||
System should process this data samples:
|
||||
|
||||
`sample1.jpg`, `sample2.jpg`, `coordinates.csv`
|
||||
|
||||
We have next restrictions for the input data:
|
||||
|
||||
`docs/00_problem/restrictions.md`
|
||||
|
||||
Output of our system should meet these acceptance criteria:
|
||||
|
||||
`docs/00_problem/acceptance_criteria.md`
|
||||
|
||||
Find out all the state of the art solutions for this problem and produce the resulting solution draft in the next format:
|
||||
- Product solution description
|
||||
- Architecture approach that meet restrictions and acceptance criteria
|
||||
- Testing strategy. Research the best approaches to cover all the acceptance criteria, functional and non-functional tests
|
||||
|
||||
**👨💻Developer**: Research the problem as well, and add solution details to the draft. Store it to the `docs/01_solution/solution_draft_01.md`
|
||||
**👨💻Developer**: Revise the result from AI. Research the problem as well, and add/modify/remove some solution details in the draft.
|
||||
Store it to the `docs/01_solution/solution_draft_01.md`
|
||||
|
||||
|
||||
## 1.4 **✨AI Research**: Solution draft assessment
|
||||
Form the next prompt by replacing *.md with corresponding content and run it in DeepResearch tool (Gemini, ChatGPT, or other)
|
||||
**📝prompt:**
|
||||
**📝prompt template:**
|
||||
In the solution here:
|
||||
`docs/01_solution/solution_draft_xx.md`
|
||||
find out all the possible weak points and problems. Address them and find out ways to solve them. Based on your findings, form new solution draft in the same format.
|
||||
|
||||
**👨💻Developer**: Research by yourself as well - how to solve additional problems which AI figured out, and add them to the result. Store the result draft to the `docs/01_solution/solution_draft_xx+1.md`, and repeat the process. When the next solution wouldn't differ much from the previous one, store the last draft as `docs/01_solution/solution.md`
|
||||
|
||||
|
||||
## 1.5 **🤖📋AI plan**: Solution Decomposition
|
||||
**📝prompt:**
|
||||
Decompose the solution `@docs/01_solution/solution.md` to the components.
|
||||
@@ -101,6 +144,7 @@
|
||||
|
||||
**👨💻Developer**: Answer the questions AI asked, put as many details as possible
|
||||
|
||||
|
||||
## 1.6 **🤖📋AI plan**: Business Requirement generation
|
||||
From the initial requirements above generate Jira epics:
|
||||
- Ask the Jira project key and latest created jira task number. For example AZ-412
|
||||
|
||||
@@ -1,29 +1,45 @@
|
||||
For the problem:
|
||||
|
||||
"We have a lot of images taken from wing-type UAV by camera with at least full hd resolution. Resolution of each photo could be up to 6200*4100 for the whole flight, but for other flight could be FullHd, f.e.
|
||||
Photos are taken and named consecutively within 100 meters distance between each other.
|
||||
We know only starting GPS coordinates. We need to determine coordinates of centers of each image. And also coordinates of the center of any object on these photos. We can use external satellite provider for ground check the existing photos"
|
||||
|
||||
with restrictions:
|
||||
|
||||
"Photos are taken by only airplane type UAVs.
|
||||
Photos are taken by the camera pointing downwards and fixed, but it is not autostabilize
|
||||
The flying range is restricted by eastern and southern part of Ukraine (To the left of Dnipro river)
|
||||
The image resolution could be from FullHd to 6252*4168
|
||||
Altitude is prefefined and no more than 1km
|
||||
Flights are done mostly in sunny weather
|
||||
We can use satellite providers, but we're limited right now to Google Maps, which could be possibly outdated for some regions
|
||||
Number of photos could be up to 3000, usually in 500-1500 range
|
||||
During the flight UAV can make sharp turns, so that it is possible that next photo is absolutely different from the previous one (no same objects), but it is rather exception than the rule"
|
||||
|
||||
check how realistic these acceptance criteria are:
|
||||
|
||||
"- System should find out GPS of centers of all the photos from the flight within error no more than 100 meters in comparison to the real GPS.
|
||||
- System should find out GPS of centers of 70% of the photos from the flight within error no more than 30 meters in comparison to the real GPS"
|
||||
|
||||
Check how critical is each criteria. Also find out more acceptance criteria for this specific domain.
|
||||
Research impact of each value in acceptance criteria to the whole system quality.
|
||||
Assess acceptable ranges for each value in each acceptance criteria in the state of the art solutions, and propose corrections in form:
|
||||
- state of the art solutions' value ranges : our value ranges
|
||||
We have this problem:
|
||||
|
||||
Form the new acceptance criteria based on your research.
|
||||
We have a lot of images taken from wing-type UAV by camera with at least FullHD resolution. Resolution of each photo could be up to 6200*4100 for the whole flight, but for other flight could be FullHD, f.e.
|
||||
Photos are taken and named consecutively within 100 meters distance between each other.
|
||||
We know only starting GPS coordinates. We need to determine coordinates of centers of each image. And also coordinates of the center of any object on these photos. We can use external satellite provider for ground check the existing photos
|
||||
|
||||
System should process this data (here are the samples):
|
||||
|
||||
AD000001.jpg, AD000002.jpg, AD000003.jpg, AD000004.jpg, AD000005.jpg, AD000006.jpg, AD000007.jpg, AD000008.jpg, AD000009.jpg, AD000010.jpg, AD000011.jpg, AD000012.jpg, AD000013.jpg, AD000014.jpg, AD000015.jpg, AD000016.jpg, AD000017.jpg, AD000018.jpg, AD000019.jpg, AD000020.jpg, AD000021.jpg, AD000022.jpg, AD000023.jpg, AD000024.jpg, AD000025.jpg, AD000026.jpg, AD000027.jpg, AD000028.jpg, AD000029.jpg, AD000030.jpg, AD000031.jpg, AD000032.jpg, AD000033.jpg, AD000034.jpg, AD000035.jpg, AD000036.jpg, AD000037.jpg, AD000038.jpg, AD000039.jpg, AD000040.jpg, AD000041.jpg, AD000042.jpg, AD000043.jpg, AD000044.jpg, AD000045.jpg, AD000046.jpg, AD000047.jpg, AD000048.jpg, AD000049.jpg, AD000050.jpg, AD000051.jpg, AD000052.jpg, AD000053.jpg, AD000054.jpg, AD000055.jpg, AD000056.jpg, AD000057.jpg, AD000058.jpg, AD000059.jpg, AD000060.jpg, coordinates.csv
|
||||
|
||||
We have next restrictions for the input data:
|
||||
|
||||
- Photos are taken by only airplane type UAVs.
|
||||
- Photos are taken by the camera pointing downwards and fixed, but it is not autostabilized.
|
||||
- The flying range is restricted by eastern and southern part of Ukraine (To the left of Dnipro river)
|
||||
- The image resolution could be from FullHd to 6252*4168
|
||||
- Altitude is prefefined and no more than 1km
|
||||
- Flights are done mostly in sunny weather
|
||||
- We can use satellite providers, but we're limited right now to Google Maps, which could be possibly outdated for some regions
|
||||
- Number of photos could be up to 3000, usually in 500-1500 range
|
||||
- During the flight UAV can make sharp turns, so that it is possible that next photo is absolutely different from the previous one (no same objects), but it is rather exception than the rule
|
||||
|
||||
|
||||
Output of our system should meet these acceptance criteria:
|
||||
|
||||
- System should find out GPS of centers of 80% of the photos from the flight within error no more than 50 meters in comparison to the real GPS
|
||||
- System should find out GPS of centers of 60% of the photos from the flight within error no more than 10 meters in comparison to the real GPS
|
||||
- System should correctly continue the work even in a presence of up to 350 meters outlier photo between 2 consecutive photos en route. This could happen due to tilt of the plane.
|
||||
- System should correctly continue the work even during sharp turns, where the next photo doesn't overlap at all, or overlaps in less than 5%. Next photo should be in less than 150m drift and angle less than 50%
|
||||
- Number of outliers during the satellite provider images ground check should be less than 10%
|
||||
- In case of absolute incapable of the system to determine next, second next, and third next images gps, by any methods, (these 20% of the route), then it should ask user for an input for the next image, so that user can specify location
|
||||
|
||||
Check how realistic these acceptance criteria are.
|
||||
Check how critical is each criterion. Also find out more acceptance criteria for this specific domain.
|
||||
Research impact of each value in acceptance criteria to the whole system quality.
|
||||
Assess acceptable ranges for each value in each acceptance criteria in the state of the art solutions, and propose corrections in the next table:
|
||||
- Acceptance criterion name
|
||||
- Our values
|
||||
- Your researched criterion values
|
||||
- Status: Is criterion was added by your research to our system, or modified, or removed, cause not necessary
|
||||
Also asses restrictions we've put for the system. Are they realistic? Propose corrections in the next table:
|
||||
- Restriction name
|
||||
- Our values
|
||||
- Your researched restriction values
|
||||
- Status: Is restriction was added by your research to our system, or modified, or removed, cause not necessary
|
||||
Reference in New Issue
Block a user