Forge - DevCon 2016: Building a Drone Imagery Service
3 likes533 views
Jia Huang, a software engineer at 3D Robotics, presents a drone imagery service built using Autodesk Forge, highlighting the site's workflow for geotagging and photo management. The 3DR Cloud architecture utilizes Scala and Akka for flexible and efficient handling of large image data, while also managing user services and errors with an actor-based system. Key challenges include managing image size and processing multiple images across job flights, alongside considerations for integration types and data management.
![Actor Scheduling Pattern
▪ Actors can schedule themselves for future actions
class RecapActor(…) extends Actor with …{
implicit val system = context.system
private var scheduledTask: Option[Cancellable] = None
def receive = {
case PollScene(…) =>
scheduledTask = scheduledTask match {
case None => Some(
context.system.scheduler.schedule(10 minutes,
10 minutes, self,
PollScene(…) ))
case Some(cancellable) => scheduledTask
}
}
}](https://image.slidesharecdn.com/buildingadroneimageryservice-160722215742/85/Forge-DevCon-2016-Building-a-Drone-Imagery-Service-18-320.jpg)
Forge - DevCon 2016: Building a Drone Imagery Service
- 1. Jia Huang Software Engineer @ 3DRobotics Building a Drone Imagery Service
- 3. see the world from above
- 4. Site Scan
- 5. Site Scan Survey Scan Inspect
- 6. Scan Results 5 minute flights 84 Photos 90 minute processing time
- 8. Site Scan Video • https://www.youtube.com/watch? v=6BTC1Zjo8Ic
- 10. Site Scan workflow • geotagging • user controls • prepare job • user validation • saves results • render mesh • take photos
- 11. Challenges for the 3DR Cloud • each image is ~10MB • up to 250 images per job • soon <= 2000 images across multiple flights in one job • Mesh / ortho / point cloud results are ~100MB to ~200MB
- 13. 3DR Cloud API ▪ All written in Scala with the Akka libraries ▪ Why Akka? ▪ Lightweight ▪ Flexible ▪ Everything is a stream ▪ Why Couchbase? ▪ Blob data ▪ Add more boxes as needed ▪ NoSQL with SQL interface (n1ql)
- 14. User Service ▪ User Service keeps track of ▪ users ▪ groups ▪ permissioning ▪ Why Postgres? ▪ highly relational data ▪ use the right db for the job
- 15. Recap Service ▪ Actors encapsulate state and behavior ▪ Communicate exclusively through messages ▪ Uses Akka’s Actor system ▪ Supervisor & children ▪ Each child Recap actor keeps its own state ▪ Supervisor gets passed errors
- 16. Creating a Photoscene with Autodesk Recap
- 17. Actor Supervisor Pattern ▪ Children can crash without damaging the system ▪ Supervisors handle errors import akka.actor.OneForOneStrategy import akka.actor.SupervisorStrategy._ import scala.concurrent.duration._ override val supervisorStrategy = OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1 minute) { case _: ArithmeticException => Resume case _: NullPointerException => Restart case _: IllegalArgumentException => Stop case _: Exception => Escalate }
- 18. Actor Scheduling Pattern ▪ Actors can schedule themselves for future actions class RecapActor(…) extends Actor with …{ implicit val system = context.system private var scheduledTask: Option[Cancellable] = None def receive = { case PollScene(…) => scheduledTask = scheduledTask match { case None => Some( context.system.scheduler.schedule(10 minutes, 10 minutes, self, PollScene(…) )) case Some(cancellable) => scheduledTask } } }
- 19. Interfacing with Autodesk Recap ▪ Handles authentication, sending & receiving to Recap ▪ Returns a Scala PhotoSceneEntity ▪ Formats, photolist, photoscene status, processing time, and any errors ▪ Reuploads photos during error states ▪ Built on top of Akka-requests-lib ▪ https://github.com/3drobotics/cloud-akka-request
- 20. • Depends on the integration type • State machine? Akka Finite State Machine Mixin • Relational? Another Postgres backed service • Blob data? • Keep things decoupled Architecting future integrations