usd-wall

This is not your Daddy’s “drone” company.  USDrobotics is new technology company that is developing hardware (not software) control and power systems for industrial class autonomous air, land, and sea vehicles which utilize pre-planned and approved flight paths and operate safely without human intervention.  Our innovative technology will make commercial drones exponentially safer, more controllable, and more economical than piloted versions.  In effect, our systems are autonomous flying robots, which inspired us to combine drone with robotics to coin the term Drobotics.

Our patent portfolio covers the following areas:

  • Autonomous Land, Sea, and Air vehicles.
  • Navigation and Piloting Supercomputers.
  • Autonomous Vehicle Path Planning.
  • Jet Turbine / Liquid Fuel Generator and Power Systems
  • High Efficiency Ducted Fan Motors
  • Autonomous Passenger Vehicles
  • Counter to Counter Drobotic Delivery Systems
  • Automated Warehousing Systems
  • Drobotic Carriers
  • Long Range Troop Close Air Support
  • Multi-Platform Smart Weapons
  • Specialized Surveillance Platforms
  • Automated Mail Delivery
  • Use of National Cellular Infrastructure for Drone / ATC Command and Control
  • Use of Drones in Entertainment Venues
  • Land Use Management, Search and Rescue, Disaster Recovery and Support

USDrobotics is an “Intel Inside” style IP company building an alternative IP portfolio for vehicles that enables creation of safe cooperative vehicle paths with 4D Autorouting, mitigates the risk of using autonomous platforms for destructive purposes, and provide high speed custom hardware supercomputers for the compute intensive tasks or piloting, navigation, and sense/avoid systems.The simplicity and natural multitasking capabilities of hardware will allow us to leapfrog ahead of traditional software solutions. High efficiency power systems will finally enable industrial class autonomous systems while application programmability in the platforms enables a new class of Application Specific Autonomous Vehicles or (ASAVs).  These are the features of the vehicles of the future.

 

Drobotic Technology

USDrobotics started with a simple question: “How can we create an Unmanned Aerial Vehicle (UAV) that is truly safe for almost any application?” Our inescapable conclusion: Take the human pilot out of the equation. With that realization, our research has taken us down a fundamentally different R&D path from other companies, resulting in a completely new class of unmanned / autonomous vehicles. These systems have flight autonomy, yet are under complete system control and monitoring: the drobotDrobotics technology is a major paradigm shift in how we think about UAVs.

The second realization was a little different:  We need to take the Computer out as well. In a word, what makes drobots unique is Architecture.  Almost every other attempt at autonomy is being pursued as a software solution. The problem is that general purpose computers are designed to everything poorly. They will do anything, but the inevitable consequence of that flexibility is the fact that they do not do any one thing particularly well.  Hardware accelerators, by contrast, are specially architected supercomputers built to do one thing very, very well.  In our case, these hardware accelerators form the basis of our pilot, navigator, and obstacle avoidance / scene analysis systems. What we strive for is safety. Safety implies accuracy, and accuracy demands high speed supercomputer power.  The challenge is how to get that inside a small, mobile, platform.

Trackpath Network v1 (3)

Our breakthrough came from analyzing the different requirements of an autonomous system as layers, not as multiple tasks within the same processor.  In most software-based systems the software becomes easily overwhelmed by all of the simultaneous tasks it is required to perform – but standard computers can really only do one thing at a time.  In hardware, this multi-tasking is natural and greatly simplified. With today’s electronics, a supercomputer that used to fill an entire rack of hardware is now the size of a deck of playing cards.

For example, consider the task of navigating a platform from Point A to Point B: The platform needs to take into account all of the possible structures, paths, obstacles, and other vehicles that could possibly occur.  It would take mountains of data space and processing within the platform just to hold and continuously update all of this information, and this is just the first step – we haven’t even gotten around to actually piloting the vehicle or controlling it.

Instead, we layer the architecture so that the first step, calculating the path to take, is performed in advance when all of the computing power and data in the world is readily available.  All that is needed is a 3-D map of the area and a large server farm – both of which Google, for example, already has. At the same time this map is being used to find the optimal route – a tried and true software technique called “autorouting” and used to design complex printed circuit boards but with a new twist – routes are now 4-Dimensional instead of 3.  With an autorouter the air traffic control system can take into account all of the other known platforms in the area. This solves all of the major problems – structures, paths, obstacles, and other vehicles – all in one stroke with a database as large as the Internet and computing power as large and distributed as necessary.  This presents a very different computing problem than trying to fit it all into the vehicle.  We call this pre-computed route a “trackpath.”

Once the trackpath is defined, it is loaded into the vehicle. This greatly simplifies the definition and design of the next layer of the architecture, a hardware supercomputer that forms the on-board navigator.  In simplistic terms, the navigator – dubbed STeVIE (Safe Temporal Vector Integration Engine) – simply calculates the difference between where the platform is now, and where the trackpath says it’s supposed to be.  In an existing UAV system, this difference might be calculated one or two hundred times per second, which can be an error of feet at flight speed.  This can hardly be considered either safe or accurate. Because STeVIE is a hardware supercomputer, it’s calculating this difference every thousandth of an inch. This changes everything about how the system is designed and operated. This is what makes it accurate, repeatable, and safe.  The navigation supercomputer’s task is reduced to computing a single vector of where the platform should go in the next one millionth of a second, and hardware systems cannot be hacked.

Stevie

In the final level of the architecture, another supercomputer is tasked as being the pilot of the vehicle. It doesn’t need to know the destination, or the path, or anything else except what is the current state of the platform, and what has to be changed in the platform to execute the vector passed down from STeVIE?

Because of the speed of the platform and the layered hierarchy, each level is greatly simplified by the computation of the layer above it. This is of great importance because it significantly reduces the amount of design effort required at each layer, and the interactions between the tasks – a nightmare in software based systems – is also controlled and simplified.  This makes Drobots simpler to design, simpler to simulate and test, and simpler to build than software-based solutions. This will allow us to catch up and even leap ahead of companies that have trudged on for years refining their software models.

The drobotic concept, however, does not stop there. The trackpath excels at designing a path over any distance taking all other structure and vehicles into account, but it can’t know everything.  A fourth supercomputer is tasked with obstacle avoidance and scene analysis.  Both of these are critical to drobotic function.  Obstacle avoidance is a simple concept, but not always easy to realize.  This hardware accelerator is again simplified by the fact that most things are taken into account by the trackpath.  Of equal import is a significant shift in thinking about how to protect people from misuse of drones.  All existing “drones” use the concept of a GeoFence.  This fence defines a polygon on a map where the drone is not allowed to go. This is fundamentally flawed on a number of levels:

  • A GeoFence doesn’t always work if the drone starts out inside the fence, such as the 3-mile exclusion zone near an airport.
  • It takes a sophisticated piece of equipment – a couple of square inches of aluminum foil or a gum wrapper, for example – to defeat the geofencing system and fly wherever you want.
  • If the number of GeoFence constructs grows, for example if legislation allows a homeowner to request that drones not fly over their property like the “don’t call” list for telemarketers, the CPU handling the flight control will be quickly overcome by the real-time processing requirements of too many fences.
  • The GeoFencing structures must be continuously updated to every platform as they change.
  • GeoFences, in essence, are 2-Dimensional structures when they really need to be 3D or even 4D (space and time).

The Inverse-Geofence is also known as a Free Flight Corridor.  Instead of defining the multitude of places the drones cannot go, we define a single 4D structure (In Space and Time) that defines the area where it is allowed to go.  This again changes everything about how the vehicles are designed, programmed, and operated to greatly simplify their design while simultaneously making them safe and mitigating the ability of a terrorist to misuse a drone platform to cause harm.  Drobots simply cannot go where they’re not approved to go. If the GPS receiver is blocked or disabled, it simply doesn’t fly. Only one fence structure is ever needed within the platform.

FIG 6

Of greater import is the scene analysis system – drobots can not only detect conditions and objects in their vicinity, but they can be programmed to act upon that knowledge.  This is one of the most important breakthroughs that defines a drobotic vehicle.  Instead of thinking of a drobot as a “drone” that someone is out there piloting remotely, we now think of it as a computer that moves things.  This shift in fundamental computing has not been seen since the advent of the microprocessor in the 1980s, and in a similar manner we foresee that drobots – as programmable to a specific task as a computer application – will be just as ubiquitous.

As an example, consider drobotic technology applied to package delivery. Although Amazon and Google have been very public in the pursuit of this space, and FedEx and UPS are running hard to catch up, there are a lot of unanswered questions.  There is a very interesting article that outlines “The 37 Critical Problems that need to be Solved for Drone Delivery to become Viable.”

http://www.futuristspeaker.com/2015/01/37-critical-problems-that-need-to-be-solved-for-drone-delivery-to-become-viable/

Amazon’s patent describes the basic requirements of getting a drone to drop a package at a given address, but is pretty vague as to the details.  In contrast, consider the diagram below:

FIG 1
Figure 1

In the above image (FIG 1), the simple concept of a basic drobotic vehicle is replicated over a number of different platforms that we refer to as Application Specific Autonomous Vehicles (ASAV):

  • Boxtrolls or small box transfer vehicles (115) are guided to simply move boxes place to place.
  • Intelligent shelving units reconfigure automatically and are tied to the overall package movement planning by autorouter software and the boxtrolls (125)
  • Intelligent warehouses, shipping trucks, and containers using boxtrolls and autonomous shelving units to maximize loading while providing for automated loading and unloading at source and destination (130)
  • Drobotic carriers (120) – it’s inefficient to fly 10 packages 5 miles in individual drones when you can put 10 packages in one carrier, and fly it and 2 smaller delivery drones across town to do drop-offs. The carrier can be an air or land vehicle, the principle (and the patent) still applies.
  • Drobotic kiosks for pickup and delivery of packages (105, 140, 155).
  • And yes, drobot package delivery vehicles (150).

The same drobot platform is used to implement all of these different vehicles, and route planning – whether within a single warehouse or across town – is automatically handled by the autorouting systems.

With this one simple architecture, we can implement a package delivery system that is untouched by human hands from the moment the package is dropped at the station to the moment it is picked up by the recipient.