> But to the best of my knowledge this hasn't been implemented anywhere, and today's drones simply fall out of the sky if one motor fails or its propellers are destroyed.
I'm a former Skydio[1] employee and our motion-planning & state-estimation teams implemented this on all our drones years ago. It wasn't completely fool-proof, but in many non-high-speed scenarios a loss of a motor was not catastrophic and the drone could 'emergency land' within a few meters of where it was flying. I wish I had proof for you but unfortunately no longer have access to any internal videos :)
It's fairly straightforward to write a websocket endpoint in whatever backend you have that issues a SUBSCRIBE query on connect and then continuously forwards the updates to the client. The complicated parts you'd need to build are on the frontend -- handling updates and merging them into whatever state you render from.
Disclaimer -- I work at Materialize -- but it does seem like the perfect fit for what you need (efficiently updated real-time materialized views).
This sounds very similar to Ovio, which matches open-source projects with contributors that have relevant skills. There isn't a rating system but there are tools to browse and find good projects & issues to contribute to for aspiring OSS devs
This is great! I've had this exact idea for a specific robotics use-case but never got around to implementing it: a fleet of robots that each expose an HTTP service for debugging purposes. These robots connect to the internet through cellular or hop around among a set of wifi access points, such that long-lived connections are often interrupted and each robot IP address intermittently changes.
Many other reverse proxy / tunneling solutions use TCP-based protocols or require the target hosts to be accessible by the proxy server, but in this case QUIC connection migration avoids the reconnection handshakes needed for dropped TCP connections, and your client->server model allows the robots to register themselves from restrictive networks.
The only missing feature would be to allow some sort of auth plugin - perhaps as a sub-request made to an external auth service that contains the identifier of the client the request will be routed to, similar to nginx's auth_request (https://nginx.org/en/docs/http/ngx_http_auth_request_module....)
> Of course it's possible to solve. But I think the solutions (and the cons of those solutions) are often pretty arduous or unreasonable.
> worst of all, you don't have any transactional consistency across those joins, it's possible to join when you've only consumed one half of the streaming data (e.g. one of two topics).
This is exactly right! Most streaming solutions out there overly simplify real use-cases where you have multiple upstream tables and need strongly consistent joins in the streamed data, such that transactional guarantees are propagated downstream. It's very hard to achieve this with classic CDC + Kafka style systems.
It's often something that folks overlook when choosing a streaming system and then get bitten when they realize they can't easily join across the tables ingested from their upstream db and get correct results.
Another open-source SFU I've had great experience with is Livekit[0]. Great docs, modern, easy to deploy (it's a golang binary), and supports a number of egress options too if you want to record the media during a stream to an external system. With their cloud product they've also built a really cool 'mesh-based' SFU-CDN that allows peers to connect to an SFU closest to them and have their media broadcast to other SFUs internal to their network, which allows for easy scaling during broadcast-style use-cases.
Thank you for writing sish! We’ve been using sish as a self-hosted alternative to ngrok because of how easy and flexible it is to configure and because it allows us to tunnel to devices without installing any extra device-side software (since it uses ssh).
I highly recommend it among all the other great projects on the awesome-tunneling list
We've been building a live-streaming & remote operation system for drones using LiveKit. I've been extremely impressed at the speed they've delivered improvements and grateful of how supportive DZ & the LiveKit team have been of us. It's definitely the right choice if you're looking for a modern SFU system to run. Congrats on reaching 1.0!
Check out https://ovio.org/ -- they target matching developers with Open Source projects, and many of them are for non-profit causes (several COVID-19 related projects right now: https://explore.ovio.org/covid-19)
Skydio | Redwood City, CA | Full-Time | Platform / Backend / Web / Infrastructure / DevOps Software Engineers | ONSITE (wfh for now)
We are hiring (3 yrs min experience) engineers for the Platform Software team I lead at Skydio (we build self-flying camera drones, our second product, Skydio 2, sold out in a few hours last October: https://www.youtube.com/watch?v=imt2qZ7uw1s )
Our team owns a wide variety of systems, including cloud and web software (APIs for flight and telemetry data, complex SPAs, data pipelines, CI clusters, viz tools, etc), on-vehicle systems software (process management, logging, analytics, media management, messaging APIs, etc), and developer tooling (e.g. analysis tools for flight log data). Most code is written in Python, C++ and Typescript.
Our founders met as MIT grad students building autonomous fixed wing drones before co-founding Google X's Project Wing. We have an incredibly strong team across many disciplines.
Check out our press to see why we consider ourselves the world-leader in autonomous flying devices: https://www.skydio.com/press/
Job descriptions below. Feel free to reach out to me at roshan [at] skydio.com
I've heard great things about Ovio https://ovio.org/ - they help coordinate open-source project development for social-impact organizations using volunteers like yourself
edit: I work at Skydio -- all the footage you are seeing is real and filmed entirely on Skydio 2. In our launch video each clip is labeled with "Flying Itself - No Pilot" where it is totally autonomous and "Piloted with AI Assist" when a pilot is using Skydio Controller combined with on-board obstacle avoidance: https://www.youtube.com/watch?v=imt2qZ7uw1s
Skydio | Redwood City, CA | Full-Time | ONSITE
Infrastructure / Platform / Backend / Web / DevOps Software Engineers
We are hiring engineers for the Software Infrastructure team I lead at Skydio (we build self-flying camera drones: https://youtu.be/p1c-H8NdiEA )
Our team owns a wide variety of projects in our stack, including backend APIs which power our mobile apps, infrastructure to run 3rd-party code inside vehicle simulators on EC2, on-vehicle real-time process management, Linux system config, large-scale structured log data processing and analysis, devops and deployment challenges, complex front-end web apps, etc. Most code is written in python, C++ or javascript/typescript.
Our founders met as MIT grad students building autonomous fixed wing drones before co-founding Google X's Project Wing. We have an incredibly strong team across many disciplines.
Check out our press to see why we consider ourselves the world-leader in autonomous flying devices: https://www.skydio.com/press/
Job descriptions below however you can feel free to reach out to me at roshan [at] skydio.com
The problem also occurs if your CI Build + Test steps take a while to run, even on a small team pushing dozens of commits per day.
Two code-conflict-free changes may pass a pre-merge build+test cycle independently but may logically break one another if both changes are merged into master. Using a submit/merge queue guarantees that each change has passed tests with the exact ordering of commits it would be merged onto.
The example described here is a better explanation: https://github.com/bors-ng/bors-ng#but-dont-githubs-protecte...
Web / Platform / Backend / DevOps Software Engineers
We are hiring engineers for the Software Infrastructure team I lead at Skydio (we build self-flying camera drones: https://youtu.be/p1c-H8NdiEA )
Our team owns a wide variety of projects in our stack, including backend APIs which power our mobile apps, infrastructure to run 3rd-party code inside vehicle simulators on EC2, on-vehicle real-time process management, Linux system config, large-scale structured log data processing and analysis, devops and deployment challenges, complex front-end web apps, etc. We're a fairly small team so you'd have the opportunity to own one or several of these systems. Most code is written in python, C++ or javascript/typescript.
Our founders met as MIT grad students building autonomous fixed wing drones before co-founding Google X's Project Wing. We have an incredibly strong team across many disciplines.
Check out our press to see why we consider ourselves the world-leader in autonomous flying devices: https://www.skydio.com/press/
Job descriptions below however you can feel free to reach out to me here or at roshan [at] skydio.com
Awesome work Vincent! Glad to see more automation using drones in pilot-less commercial scenarios.
If a customer had a structure without a preexisting 3d model how would you create the flight plan to operate close enough for your defect detector to work? Do you have issues with moving structures/obstacles (e.g. a wind turbine rotor offset from its orientation in the model)?
Full Disclosure: I work on the SDK Platform for Skydio R1 (a fully autonomous drone doing real-time visual SLAM and motion planning). If you're interested in chatting more I'm at roshan [at] skydio.com
Correct, our constellation uses several different types of orbits to achieve global coverage. The satellites don't communicate directly with one another but rather through a globally distributed network of groundstations. When a satellite passes within view of one of our groundstations we are able to downlink the AIS data which then gets processed and delivered to customers.
Ah yes! I think the term "nanosatellites" is a bit confusing--it refers to satellites between 1 and 10 kg (https://en.wikipedia.org/wiki/Miniaturized_satellite#Nanosat...). Ours are 3U cubesats so they are about 30cm long. Much bigger than a hundred nanometers!
They have solar panels which are used to charge batteries, and since they are in low-earth-orbit they will eventually de-orbit and burn up on reentry after several years. The FCC actually requires that cubesats re-enter the atmosphere within 25 years.
Yep, terrestrial AIS receivers can only receive messages from ships that are less than ~50 nautical miles off the coast. Further out than that and you need satellite-based AIS data.
(I'm an engineer at Spire, we've launched a constellation of nanosatellites that does exactly that: https://spire.com/products/sense/ )
I'm a former Skydio[1] employee and our motion-planning & state-estimation teams implemented this on all our drones years ago. It wasn't completely fool-proof, but in many non-high-speed scenarios a loss of a motor was not catastrophic and the drone could 'emergency land' within a few meters of where it was flying. I wish I had proof for you but unfortunately no longer have access to any internal videos :)
[1] https://skydio.com