Challenges using Industrial UAV systems for indoor navigation

 

As you know, my company develops software and hardware for UAVs, but not the kind you usually read about.

While developing our indoor drone and the software for it, we faced and had to handle a lot of challenges, like these:

  1. The drone doesn’t know where it is because there are no GPS signals in places like steel tanks, tubes, or certain kinds of rooms and that makes standard drone navigation impossible.  Even when the drone has all the sensors needed to navigate obstacles, it’s still fairly useless unless it can place itself within the enclosure, whatever it may be.
  1. Frequently UAVs cannot be controlled over ordinary radio channels, because of surface reflection, which makes the need for “autonomous and unmanned” even more important. However, when dealing with various surfaces one size does not fit all, because each surface requires different custom features. And that’s why indoor drones stay indoors.
  1. Today’s cameras create amazing images, but they all have one thing in common: they require light to create images. The lack of sufficient light in tanks, tubes, etc., makes producing good images extremely challenging.
  1. UAVs are reliant on magnetometers when operating in places where GPS doesn’t work. However, magnetometers don’t always operate correctly; for example, electric motors generate strong magnetic fields and large chunks of ferrous metals can also affect the field.
  1. While drones are highly maneuverable they require space in which to do it. While they have no problem outside, it is much more difficult to fly in a tight, enclosed space, such as a tank or tube.
  1. Flying a UAV in the open air, or an empty room with plain surfaces, is very different from flying an environment full of edges and obstacles. Indoor navigation demands precise positioning to handle working goals, such as inspections, etc., as previously discussed. Edges and obstacles demand special technologies, such as SLAM, but they require substantial, additional hardware that adds weight. Because indoor drones are required to fly and maneuver in tight spaces can be neither large nor heavy.

Please join me next week to learn about the various approaches that address these challenges.

Also, if you know of other challenges, please share them in Comments and I’ll do my best to address them, too.

The drone vs everyday life

 

For many of us drones, AKA, UAV (unmanned autonomous vehicle), are something that fly like little helicopters and are used for surveillance. It’s something from movies about robots and cars that capture people’s imagination.

In fact, drones are tools that facilitate the work of people in everyday life, keeping them safe in difficult conditions. Like forklifts or tractors, drones are just another tool to help people.

I believe drones are friends. Take a look how many applications there are for UAV indoor flights.

  •  Indoor technical inspections

Drone can be used in such environments as ships, oil tanks, incinerators, mines, pipes, and planes.

1

  • Guides

MIT’s SENSEable City Lab developed a UAV system to guide students and visitors around the MIT campus.

2

  • Delivery

Drone delivery often requires entering and moving about an indoor environment

3

  • Landing on a car

Landing a drone on a car, especially a moving one, requires the same level of computer vision as flying indoors. Ford is considering using UAVs to guide autonomous vehicles.

4

  • Real Estate sales

For remote buyers online FPV images from a drone inside the property.

5

  • Image recording

For indoor sports and other activities.

6

  • Rescue operations

Our technology allows drones to navigate inside buildings destroyed by earthquakes, etc., and deliver supplies to survivors caught in the rubble until rescue teams dig them out.

A swarm of drones capable of navigating indoors can rescue people from buildings on fire and similar emergencies.

7

Please add your comments and options to help drones become more human friendly!

Distributed team: making hardware happen

 

As I mentioned last week, NTR has a new department dedicated to developing hardware for several clients around the world.

Yes, I said hardware. For years software was everything; even some of my friends were surprised when I mentioned we are supplying distributed teams to build hardware. They said, “What are you building? Why do startups (our main clients) need new hardware?”

I said, “Think UAV, AKA, drones.”

Xt_41xdB_Y8

Our hardware department was originally formed to do a major UAV project, along with some IoT and robotics projects. The department consists of Sasha, the team lead and lead engineer/developer and AI/computer vision specialist, Andrey, lead engineer and embedder, another Andrey, a hardware engineer and 3D printing and modeling specialist, Ruslan, engineer and embedder, and Lesha, a junior engineer, who is learning machine learning.

It all started when a long-time Dutch client came up with a new startup idea and came to NTR to make an MVP of it. The idea was to use drones for the technical inspection of oil tanks.

You see, oil tanks must be inspected for tech problems every 10 years. The process is very time-consuming, costly, and, most importantly, very dangerous for the human inspector.

WP_20170504_14_51_07_Pro[1] (2)
This is how oil tanks look from the inside. The first drone’s field testing

It’s been a very challenging project, because the steel tank’s borders are reflective, which means they reflect all commonly used types of signals — GPS, Wi-Fi, BlueTooth or radio — so the UAV must do everything on its own, which means the implementation of fully coated surface flight algorithms and obstacle flight algorithms. 

And to make it even more difficult there is a serious lack of light meaning it’s extremely challenging to shoot high resolution quality images.

Снимок434
This picture was taken by drone

Worse still, Ruslan was seriously injured in car accident and spent several months in the hospital, but he’s OK now and back to work.

Accomplishing all this turned out to be far more difficult than anyone expected! It doubled our original estimate, but the scientific interest was so strong that NTR decided to complete the project ourselves. The result is that on our own we built a drone that is close to DARPA FLA  requirements among commercial drones, which is something we are very proud of!

Here’s a few videos of our drone in action.


Just checking the world tech news I’m amazed at how fast progress is. A few years ago we didn’t know what a drone was (except in sci-fi) and today we get packages from Amazon drone-delivered, DHL does drone-based medicine delivery service in Germany, Google is testing its own drone-delivery service in Australia, Walmart uses drones to inventory its warehouses, the United Arab Emirates is working on a system to use drones to transport government documents, military uses are beyond counting, and both Walmart and Amazon sell drones to consumers.

So, how does it feel to be a part of something that big and fast-growing?

Mindboggling and majestic.

Distributed team: process overview p.2

 

Distributed team: process details

Last week I shared an overview of NTR’s process, because, in the final analysis, no matter how talented the techs or smart the founder, anything goes better with a solid plan.

My boss is always saying, plan equals process, but I think of process more like a map that shows how to get from here to there.

We covered the first two steps — understanding your vision, market and biz, and the necessary paperwork — yesterday, so let’s get to the interesting stuff.

When it comes to software development, we offer three engagement options:

  • Project
  • Virtual Offshore Development Center (VDC)
  • Dedicated Offshore Development Center (DDC)

Here is what is involved with each:

Project involvement.
When requirements are well-specified and detailed we can work with you on a fixed-cost, project-based premise.

This means that you provide us with a detailed requirements document for the software and based on that we estimate the project in detail, factor in the development risks, and provide you with a fixed cost/fixed time proposal.
Substantial requirements changes will trigger change management procedures, including contract renegotiation if necessary.
We are responsible for project management, while QA can be on either side.


VDC (time-and-materials)
The development team is flexible, based on your needs. 

We track all developer working hours and bills are based on those reports. Invoices w/timesheets are submitted by email or online access and paid monthly.

Project management and QA can be on either side.
VDC is suited for fast-paced environments where the time to renegotiate a contract is too costly in terms of both deadlines and money.


DDC (dedicated staff)
The team is stable — works only on the clients business — allowing it to build a deep competence in the customer’s product, needs and processes.

We usually work iteratively and you pay either for each iteration based on time and material reports or a fixed monthly amount.

NTR offers two development process options, depending on the specific situation

  • Agile
  • Rational Unified

 

Agile process, typically SCRUM-based
Agile rests on four main iterative activities (listening, designing, coding and testing) with the following process highlights:

  • continuous customer interaction;
  • continuous testing;
  • early feasibility studies;
  • early prototyping;
  • early detailed software design;
  • early functional software;
  • gradual feature addition.

Typical activities include:

  • daily status meetings
  • planning reminders
  • code reviews
  • unit testing
  • weekly customer demos

Rational Unified process
A four-phase approach (inception, elaboration, construction and transition):

  • starts with business needs and context analysis;
  • produce the project plan and description;
  • consider challenges and basic architecture;
  • create development plan;
  • write the code;
  • complete all necessary testing and feedback-driven adjustments. This includes all customer-specific options.

Step 3

The quality and efficiency of your experience with any kind of remote work is heavily dependent on the quality of communications that facilitates the teamwork.

We use a variety of communications technology, combined with written documentation that avoids misunderstandings, mishearings or memory lapses.

As I keep saying, communications are paramount. Together we choose the optimal communication tools we set up

  • a rhythm of daily or weekly meetings, along with whatever additional communications are needed;
  • a solid online project management tool or issue tracker;
  • a tool to collaborate and share all sorts of documents about the product; and
  • tools that allow effective distributed collaboration for engineering activities.

Step 4

When applicable we build a UI prototype.

We make an interactive prototype, correct and change it depending on customer feedback, and only after that do we make the real prototype.

Step 5

Each project has a project manager and lead developer. We start coding when the spec is decided using the agreed upon development method (Agile or Rational Unified)

Step 6

We move to small one- or two-week iterations sequentially increasing the functionality of the application.

Step 7

We use a variety of technology to track errors and store the code on GitHub to facilitate full integration.

Step 8

We build effective tests into the planning process at the start, because that is the best way to assure quality and prove your application is ready to launch. Testing includes setting up measurement tools, including KPIs, if applicable.

We have our own team of QA engineers. They conduct both manual and automated testing as needed.

Step 9

Launching is always a multi-faceted process. We make sure that the marketing build-up, actual product launch, and data migration (if applicable) occur at the same time.

Step 10

Comprehensive Support

After product delivery we provide support, warranty bug fixes and usually continue developing future versions, allowing you to focus on market and monetization.

These are the details of our development process — from the seeds (AKA paperwork) to the beautiful flowers (product delivery) and berries (comprehensive support).

As NTR’s business development manager I don’t really need to know these details; even when I work with potential clients these details are beyond our typical conversation — they belong to our accounts and tech guys.

But I believe that what really distinguishes great workers from OK ones is the will to do and learn and know more.

For me, understanding how things go from idea to solid code, per aspera ad astra, really helps me  integrate into the very living essence of your company, to really feel part of it, not just a contractor, but someone who helps your dream grow and blossom — like a bee to the flower. Maybe that sounds corny, but it is how I feel.

Join me next week when I start sharing stories about our departments, people and especially the newest part of NTR — hardware. You’ll have fun. Bye!

Distributed team: process overview

 

Last week I quoted something a client said to me, “give a fool a tool and you still have a fool — they need to be used correctly.”  

I do business dev for NTR and when potential clients ask the “process question” it means they are seriously interested. It also means my response can make or break the deal.

When I first started working in IT I found it surprising that everyone wanted to know how we work. I thought that was weird, because everybody works the same way. Boy was I wrong.

People who work in IT know there is this special atmosphere of creation — developers discussing how to implement unusual features you never think about; their jokes that nobody else understand, QA department guys pretending to be a bus to test a new feature (how accurate is the bus timing in a navigator app), flying drones around the office; lots of turmoil and lots of excitement.

The atmosphere is inspiring even when it’s a bit childish. The project managers tell me that it’s a process in which they must carefully balance the creative forces, while avoiding chaos. 

NTR’s process has been developing for 16 years and continues to iterate. Probably because we have grown from the original little team of friends to 12 teams with 100+ developers working together on really large projects for both major customers and dozens of startups and from all over the world.

So our basic process must be really solid, well-curated, and fully customizable in order to deliver the best results for our clients and be proud of ourselves.

The first step is in getting to know your business; we take time to understand you market, its pain, your solutions, and how we can help tame the idea a reality.

Every engagement starts by signing a binding NDA-NCA-NSA. The reason for NDA is kind of obvious. Non-compete agreements (NCA) ensure that we don’t walk away and start a business competitive to yours, while non-solicitation agreements (NSA) mean two things. First, that neither of us will solicit each other’s customers directly, and, secondly, that neither side will poach each others employees.

Once the paperwork is done, there are three main engagement options:

  • Project-based
  • Virtual Offshore Development Center or VDC (time and materials)
  • Dedicated staff

And a choice of two development options depending on the specific situation:

  • Agile process
  • Rational Unified Process

Once these choices are made we build a UI prototype when it’s applicable.

The next step is an interactive prototype, discussed, corrected and modified depending on client feedback; only then do we build the real prototype.

Each project has its own project manager and lead developer.

We set up measurement tools and store the code on GitHub to facilitate full integration.

Our quality team conducts both manual and automated testing to ensure your product is ready for launch.

Because launching is a multi-faceted process, we make sure that the marketing build-up, launch of the product, and data migration (if applicable) occurs at the same time.

Finally, we provide comprehensive support.

Next week I’ll go into more detail on the how and why of the choices above.

Distributed team: what about the tools?

 

Most people, especially those who work in tech, and most especially Millennials like me, really like where we work — if we didn’t we would leave and work somewhere else.

I know from all the recruiters who contact me that I could move easily and probably for a little more money.

So why do I stay? Because I love the way NTR does business. I may not have a lot of work experience, but I have been on the receiving end of companies whose sole interest is taking my money and not giving a damn once they have it.

I know from chatting with people in other countries that the attitude isn’t unusual no matter how many times they say “you are very important…”

And that’s why I stay, because NTR isn’t like that.

Nick and Anton (our founders) have spent 16 years “improving the customer experience,” as they say at Amazon.

Over those years they developed a really good process and continue to tweak it, constantly evaluating the tools to be sure we use the best ones for the job, incorporating new tech because it’s better — not just because it’s new.

So let’s take a look at the tools.

 In the course of a series on outsourcing last year the importance of good communications was prominent with everyone we talked to.

Because our project managers all speak and write competent English, we can use a variety of different communications tech, partially dependent on client preferences, combined with written documentation that avoids misunderstandings, mishearing or memory lapses.

There are many tools available, so we set up

  • a rhythm of daily or weekly meetings by Skype, Slack, Google Hangouts etc.,
  • continue with online communications beyond the scheduled meetings;
  • a tool to collaborate and share all sorts of documents about the product (Google Docs, Confluence);

However, as critical as good communication with clients is it’s still not everything. Teamwork tools are also extremely important, since we are communicating across time zones. So in addition to Skype, Slack, and Google docs, we add

All of the tools we use are cloud-based, so our clients can work from anywhere.

Tech tools are great, but, as a client said to me, give a fool a tool and you still have a fool — they need to be used correctly.  That means they need to integrate smoothly into whatever process is being used.

NTR’s process is what truly sets us apart, as I will explain in detail next week.

Distributed team: why worth dealing with?

 

My boss sent me an article recently. It says that Donald Trump is cracking down on H-1B visas, meaning it will get even more difficult to hire non-citizen/non Green card holders.

 

I constantly strive to better understand the motivations and dynamics between you (buyer) and I (vendor) and how to improve the process.

 

In fact, I would write an article “How to save time and money with outsourcing,” but am not really knowledgeable enough yet. Anyway, there are already many articles, like this one, if you google it.

The world moves fast, IT moves even faster and software iteration/development is approaching the speed of light.

 

Talent, especially those with specific critical skills, such as AI, x, x, and x are in the shortest supply, difficult to source and very expensive to hire.

We move very fast in IT era and now, in 2017, hired labor is gradually disappearing into the past – it is much more profitable for companies to work with outsourcing teams than hiring employees in staff. Organizations that adhere to classical HR policies, and who close all positions exclusively in-house, are doomed to stagnation

 

It’s even difficult for companies with vast resources and tremendous cachet, such as Google, Facebook, and Apple, to fill their openings locally, which is why they have opened development facilities around the world.

 

Multiple development facilities are a luxury few startups and fast-growth companies can afford — or can they?

 

Outsourced, distributed teams from the right vendor can provide the same time and cost-effective talent solutions the big guys enjoy.

 

Last year we ran a series of posts about outsourcing — Clear expectations and communication, Reasons for outsourcing, and How to find the right vendor .

 

I think it’s time to revisit the subject starting with a look at some of the best tools for managing distributed development teams.

 

Slack connects all members of a project in one channel to facilitate discussion and collaboration.

Trello uses a Kanban board to view project status and manage tasks visually.

Gitlo = GitHub + Trello – Syncing tasks on Trello makes working on GitHub simpler.

Solo is a freelancer’s best friend for managing project details.

 

This is the first post from a new series on distributed, AKA, remote, team usage.

 

I’m planning on keeping it interesting for you; behind-the-scenes stories, sharing useful tools and learning in depth why, when and how to add a distributed team to your in-house resources.
Join me next Thursday for a close-up look at the process my company uses, whether as a comparison tool or to give you a look at what it’s like to work with NTR.

Why it is so challenging to work with US

As most of you know, I’m young (22) and NTR is my first professional job. I’m definitely a digital native and, as such, consider myself fairly capable in stuff like learning new apps, transversing the net, and email — actually, in my world outside of work, email is almost obsolete.

So it was kind of a shock to find that, in general, tech-at-work is very different than tech-in-life— especially email. In tech-at-work subject lines are critical, emoji are an absolute no-no, capitals and punctuation marks are required, spelling matters and how you sign off can be a minefield.

You should always keep in mind that you’re not perfect and it’s okay to make mistakes; what is not okay is to keep making the same ones and refusing to continuously improve.

Because I do biz dev I write a lot of emails. The first thing I always keep in mind is that I’m from Russia. And I work with USA leads.

Different languages, different cultures, different businesses and different email DOs and DON’Ts.

Most of us run on a kind of autopilot, so it’s hard to remember that when talking/writing to someone from a different culture you should not always act the way you’ve been taught, instead you need to act more like them.

You need keep in mind what they might think, how they consider your words, actions and details of your style — and it doesn’t matter how weird the result is for you.

Some things are universal – such as the subject line tips. There always should be one; it should be brief and concrete, that’s clear.

Differences begin with how you start the conversation.

In Russia, business letter must be always as formal as possible, you would never say “Hi Lena;” it’s always “Hello dear Elena L’vovna” (father’s name); sometimes it’s even necessary to use their surname. Your letter can never be too personal or informal, that’s definitely weird in Russia.

That’s why it was so strange for me from the very beginning, especially when I started to work with folks from the startup community — they’re so friendly and lovely with all those “thank you,” “appreciate that,” and other polite and a bit informal phrases, like “great working with you” and “hope to meet you sometime.” I was melting.

Spaces between paragraphs are also painful. Russians love long, difficult sentences, consisting of 3 or more parts. For sure, a solid wall of text decreases the chance of getting your message across correctly, but there’s nothing weird or bad about it.

We use paragraphs only when the subject changes; one paragraph for one thought feels a bit too… I don’t know, chit-chatty manner? Not very professional?

In English, however, the situation is quite the opposite. I’ve asked my US contacts why such short paragraphs and they tell me it is because people tend to scan, not read carefully, as Russians do. That information helped me a lot, because it made so much sense.

Questions are another difficult part of communications for me.

In Russia you are considered stupid if you ask questions and it’s your duty to always look smart. So we never ask unless we can propose, we never ask unless we can pretend we got it, because who wants to look stupid?

Even when you’re talking to a professional in some expertise, you will always try to look as professional and experienced as they are by reading brief notes on the subject and googling unfamiliar words.

It’s really hard to accept that you’re allowed to ask if something is unclear to you — no matter how complex.

Signatures are another headache. They are often overloaded with all the working contacts, images, your business card, different colors, links or they are blank as a desert. You need to decide what is truly essential and then decide the best way to display it. I’m lucky, because our NTR designer developed our official sigs.

I think that covers all the obvious differences and it’s a lot to keep in mind, however…

I think most mistakes result from culture — not just country cultural differences, but your personal culture, which involves your own goals and values. They are reflected in how you value your recipient’s time, their interest I, and how much care and attention you show them.

For example, I don’t really like to answer questions that seem to me pretty obvious and sometimes I think that we can combine the answers to all the questions in one sentence.

But then I remind myself that they don’t have my knowledge base and if they took the time to ask they deserve a clear-to-them answer. Responding this way shows respect.

All that said, even when I think I’m crushing and doing fine, I still like to take an objective figure out what I can improve. So, today I reviewed my typical emails against Business Insider email tips list

Finally, introductions are probably the most sensitive emails any of us sends.

I read an explanation from Anand Sanwal of CB Insights and finally understand why the double opt-in is the best one to use and also why it is the most likely to get a positive response — it goes back to respect.  Great advice!

WTS and Women In Tech conferences

 

As some of you know, last year I was promoted to CMO at NTR Lab. One of my new responsibilities means I attend many more trade shows. That means a lot of travel (yea!) and a lot more jet lag (ugh!)

I don’t know about you, but I get terrible jet lag. If you know/use any tricks to minimize jet lag please share them below in the comments or send them directly to ykazantseva@ntrlab.com and I’ll compile and share them in a future post.

Natasha, NTR’s AI Evangelist, and I arrived in Edinburgh after about 20 hours on the road. It took that long because there were three flights with longish gaps between them. Naturally, once settled in the hotel, we immediately fell asleep.

The Women in Technology conference began early the next morning. We used CityMapper to find our way to Dynamic Earth, where the conference was being held.
As women, we found everything very inspiring.

The speakers were women working in tech; there were chat rooms during coffee breaks and the natural beauty of the opening view of the mountains from the outer platform of Dynamic Earth.

While there were many great talks, learning how other non-technical women, like me, adapted to working in technology had the greatest personal impact.

That evening we went to dinner in a large international group of women. While it was fun, being with them had a special feel, because it happened right before International Women’s Day.
From Edinburgh we went to London and spent the next few days visiting clients.

The Wearable Technology Show started March 8; it is the largest annual event for Wearables, AR & VR, IOT, and Connected Technology

We (NTR) were exhibiting in the IoT section. NTR Lab has been doing projects related to the Internet of Things and artificial intelligence for five years (and counting). It was easy to be excited when we talked with conference-goers, because Natasha and I are very proud of our company and the cutting-edge development it does for our clients.

We met with companies and people who are involved in computer vision for driving assistance; working with such household names as Lego and Nissan (who, by the way, does AI projects on computer vision systems for self-driving cars); many AR guys and med tech companies. We talked even to a girl who does app for cosmonauts.

 

At the end of the two-day exhibition, we even gave interviews to local bloggers and we were filmed with by a professional videographer.
We hardly saw London, because we worked all the time, so I told my boss that we need to go back for another conference!

NTR Lab contest: the winner

 

And the Winner Is…

 

Last month we described our decision to give back to the startup community, which is cornerstone of NTR Lab’s success, by giving away a development team for two months.

Today I want to announce the winner.

We gave our two-person development team to InsightMedi, a company originally from Spain that moved to Baltimore, MD.

InsightMedi has already had a taste of early success. Capitalizing on the fact that doctors and nurses already send images un-securely when seeking second opinions, the product gained 20,000 users in multiple countries, including a big community in India. Importantly, the system was built to be able to handle the inherent privacy laws that go along with anything medical.

Credit: http://technical.ly/baltimore/2015/03/19/why-insightmedi-moved-spain-baltimore/

Our developers will help InsightMedi add an image recognition feature to their existing medical education / social media network.

According to co-founder Juan González, “Everyone speaks image in the medical world.”

Our competition attracted great entrants, as the runner-up list shows.

It was challenging to select a winner, but we believe that our talented team will provide exceptional value to InsightMedi, as well as getting a lot of satisfaction working on a system that will help save lives.