README.md

Latest commit

History

History
49 lines (32 loc) · 3.78 KB

README.md

File metadata and controls

49 lines (32 loc) · 3.78 KB
Raw

AirSim with Akka Streams

This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control

There are 5 models that use the same algorithm to simulate evader/pursuer chase. The algorithm is very simple - because the evader is slower but can make agile turns, whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn. As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.

Model01 - Sequential model with simulator paused between turns

This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.

Model02 - Sequential model with simulator running

This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.

Model03 - Partially parallelized model

This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.

Model04 - Fully parallelized model using Akka Streams

In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.

Model05 - Fully parallelized model with Kafka

This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka. They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka. The actions are picked up by the Model05 and pushed to AirSim. This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.

Config

AirSim

You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU. The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.

Postgresql

The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:

psql your_db < src/main/resources/sql/*

and set the connection details in the application.conf file.

Running

sbt run
# then select the Model to run

You can also run the models directly, e.g.:

sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
README.md
Latest commit
History
History
49 lines (32 loc) · 3.78 KB
README.md
File metadata and controls
49 lines (32 loc) · 3.78 KB
Raw
AirSim with Akka Streams
This app was used to generate the test data for Use of AKKA Streams to Inform Forward Simulation in Robot Control
There are 5 models that use the same algorithm to simulate evader/pursuer chase.
The algorithm is very simple - because the evader is slower but can make agile turns,
whenever the pursuer is close it will start a turn. The pursuer follows, but because it has larger turning radius, it will take longer to turn.
As such, under ideal situation, the drones will end up orbiting. Each models provides a different level of parallelization.
Model01 - Sequential model with simulator paused between turns
This represents the ground truth as the paused simulator serves as a synchronization layer that shields the algorithm from both stale data and delays in actions. The simulator starts paused. The measurements are taken, and the actions calculated and sent to the agents. After that, the simulator is run for 100ms. Then the process repeats. Because the communication with the simulator happens in the paused state it can be done in a blocking manner and the calculations start only once all the requests have finished.
Model02 - Sequential model with simulator running
This is the same as the previous model, but without the paused simulator acting as the synchronization layer. Because all commands run in sequence, the next request can only be sent once the previous one completes and the calculations can only start once all the requests finished. This creates a varying level of staleness among the received data that enter the calculations. It also increases the time lag between actions being sent to the agents. With the pursuer moving at 10m/s, even relatively small delay of 500ms translates to a location difference of 5m.
Model03 - Partially parallelized model
This model represents a simple (if short-sighted) solution to the concurrency issue. Since each agent is treated as a separate entity, at each timestamp, they are wrapped in their individual future. This means that while all communication and calculations for a single agent runs sequentially, the code blocks for both agents are run in parallel.
Model04 - Fully parallelized model using Akka Streams
In this model, not only the agents move in parallel, but each operation within each agent is parallelized as well. There are no inter-process dependencies: the location is updated independently, the calculations use whatever latest data available and once the new action is calculated, it is sent to the agent. The whole process moves in the interleaved manner.
Model05 - Fully parallelized model with Kafka
This model builds on the previous one and adds on a message broker to allow for out of process and out of machine communication. Instead of running the calculation, this model persists the location readings to Kafka.
They are picked up by KafkaSolver, which runs the calculations and pushes the resulting actions back to Kafka.
The actions are picked up by the Model05 and pushed to AirSim.
This requires Kafka running somewhere (preferably on another machine) and KafkaSolver running yet on another machine.
Config
AirSim
You will need AirSim running somewhere, preferably on another network - the whole experiment is to show effects of latency when using a cloud GPU.
The config file for AirSim is under src/main/resources/settings.json. The IP of the AirSim needs to be set under Constants.
Postgresql
The steering decisions are persisted in Postgresql. Run all the migrations under src/main/resources/sql/:
psql your_db < src/main/resources/sql/* 
and set the connection details in the application.conf file.
Running
sbt run
# then select the Model to run 
You can also run the models directly, e.g.:
sbt "runMain net.nextlogic.airsim.paper.solvers.KafkaSolver"