Про микросервисы сейчас говорят все. Почти каждая встреча, конференция и митап не обходятся без рассказа о том, что такое микросервисы и как они хороши, как уменьшают сложность проекта и тп.

Основной посыл всех этих докладов — микросервисы помогают уйти от излишней сложности и запутанности проекта. Но, как по мне, от сложности не избавится совсем, нельзя переделать проект, чтобы сразу всё стало просто. Сложность из одной области перейдет в другую.

Например: был очень сложный запутанный монолит, мы его разбили на несколько сервисов, каждый из них выглядит прекрасно, любой сможет разобраться с кодом, но что происходит с окружением? Сложность растет: это и распределенные транзакции, которые нужно журналировать так, чтобы понять, что это одна транзакция; для каждого сервиса прибавляется CI/CD и поставка; схема взаимодействия становится нетривиальной.

Самые спорные тезисы или утверждения, которые я слышал на докладах и с которыми я готов спорить:

Вход в проект монолита дороже для новых членов команды. Почему-то принято оценивать стоимость вхождения в проект по тому, как быстро новый разработчик начнёт делать задачи. Да, в маленьком сервисе он разберется очень быстро и задачу выдаст очень быстро (тем более по спецификации, «что написали, то я и сделал»).

Но как насчет других членов команды?

Новый тестировщик будет разбиратся с интеграционной моделью. Протестировать сервис — это хорошо, но кроме тестирования контракта сервиса нужно проверить бизнес-процесс, который затрагивает несколько сервисов.

Новый аналитик на первых порах может вообще голову сломать, пока разберется во всех хитросплетениях внутренних вызовов.

Микросервисы позволяют чаще релизить. Микросервисы дорабатывать быстрее, потому что они разнесены на несколько параллельных задач, которые разрабатываются и тестируются параллельно, и остается только проверить интеграцию (без учета времени на аналитику).

С монолитом тоже можно так делать, всё зависит от декомпозиции задачи. Чаще всего в самом начале будет одна задача — сделать общую функциональность (общую БД подправить, или интерфейс доработать), а дальше каждый будет пилить свои подзадачи и отдавать их в тестирование.

И время выпуска фичи, за которую платит бизнес, будет одинаковое. Фича будет закрыта только когда будут выпущены все компоненты. Микросервисы могут решить 99% задач, но пока не закроется последняя фича, их не выпустят в бой.

О чем еще не говорят

Сложность растет

При использовании микросервисов усложняется инфраструктура. Это связано с тем, что нужно поддерживать работу не одного приложения, а множества сервисов. Нужно мониторить работоспособность всех сервисов, хорошо понимать зависимости сервисов по версиям, иметь CI/CD-планы для сборки сервисов и поставки, механизмы реагирования на выходы сервисов из строя, чтобы не легло всё остальное.

Вроде бы простые вещи, и в монолите мы должны делать всё то же самое. Только в монолите мы работаем над одним приложением, а с увеличением количества сервисов сложность растет, что требует от поддержки более высоких навыков.

Микросервисы добавляют сложность — новые библиотеки, новая функциональность для поддержки распределенных транзакций, для обработки ошибок других сервисов, отправки повторных запросов, отката транзакций. По большей части эти механизмы будут общими, и большинство разработчиков не полезут в «кишки», а будут только использовать их.

Но и в них могут быть ошибки, которые придётся чинить. Если с починкой мы справляемся без проблем, то чтобы раскатать изменения по 200—300 сервисам, понадобится время и развитые средства управления. А если понадобится пересобрать сервисы с обновленной библиотекой, а то и вызовы переделать (вот так починили, не предусмотрели), то всё это будет не весело.

Монолит — небольшой комок грязи(big ball of mud)

Как обычно начинаются рассказы про прекрасный мир микросервисов? «Был у нас монолит, это был сплошной комок грязи, в котором всё запутанно и непонятно», плюс ещё картинку страшную покажут. И монолит уже стал чем-то пугающим, «будете плохо работать, ваш проект превратится в монолит». Но НЕТ.

Монолит может быть(и должен) понятным, структурированным, с ‘хорошим’ кодом, с документацией, как и микросервисный проект может превратится в еще больший комок грязи, если не заниматься процессами разработки и не следить за качеством разработки.

Так что же использовать?

Хороший вопрос, и ответ можете дать только вы. Потому что только вам известно, какие проблемы бизнеса вы решаете, каким будет проект. Нет серебряной пули, нет идеальной архитектуры, которую можно использовать и будет всегда “счастье”.

И в монолите, и в микросервисах следите за документацией и поддерживайте её в актуальном состоянии. С документацией лучше, чем без неё.

Выстраивайте такой процесс разработки, при котором качество кода будет только расти (ревью, модульные тесты). Но про качество можно целую книгу написать, это тема для отдельного большого разговора.

Простой и понятный код — это не про микросервисы, код априори таким должен быть.

Автоматизация тестирования — это тоже про качество кода.

Автоматизируйте всё, что можно автоматизировать — CI/CD. Наверное, есть такой стек технологий, который очень трудно затянуть в CI/CD, но 99% сборок/поставок можно автоматизировать.

Раствор дейтерия (концентрация 25%) и обычной воды
Несмотря на то что некоторые комбинации геропротекторов или факторы Яманаки(превращающие обычные клетки в плюропотентные) способны на продление жизни на более 50% мышам, с дейтерием и другими стабильными изотопами, важен прецедент.

Первым кто предложил использовать изотоп водорода дейтерий для биологического воздействия является наш соотечественник Михаил Щетинов.

В то время как мы думаем изотопы проявляют индентичное химическое поведение, это не совсем точно. Изотопы проявляют тонкую разницу в химической прочности связи. Чем тяжелее изотоп тем связь сильнее. Например связь углерод-дейтерий в 5-10 раз сильнее чем углерод-водород. Дейтерий гораздо тяжелее водорода по сравнению с углеродом-13 (+1 нейтрон) и углеродом (атомная масса 12). Предыдущие исследования показали, что количество свободных радикалов понижается в изолированных митохондриях крысы, подверженных воздействию тяжелой воды.

Эксперимент был вдохновлен фактом — что в пожилом возрасте содержание тяжелых изотопов (углерод-13, дейтерий, азот‐15, кислород‐18, сера‐34) в аминокислотах падает. Наиболее вероятно что в метаболитах тоже.

Щетинов основал биотехнологическую фирму Retrotope которая занимается на данном этапе клиническими исследованиями препаратов rt001 rt002 являющимися модифицированными дейтерием жирными кислотами (такими как омега 3) для лечения болезни Паркинсона и Атаксии Фридрейха (митохондриальное заболевание).

У животных, раствор тяжелой воды был способен нормализовать высокое кровяное давление вызванное диетой с высоким содержанием соли у крыс, возможно через подавление гипертонии, связанное с повышением поглощения кальция. Этот эффект конечно продлит жизнь.

Дейтерий и углерод-13 также по-видимому нетоксичны. Мышам совершенно нормально, даже когда 60 процентов атомов углерода в их организме составляют углерод-13. Десятилетия экспериментов, в которых животные получали тяжелую воду, указывают на то, что до пятой части воды в вашем организме можно заменить тяжелой водой без каких-либо побочных эффектов.

Аналогичные эксперименты были проведены на людях, хотя и с более низкими уровнями дейтерия. Один недавний эксперимент удерживал людей на низкоуровневой диете тяжелой воды в течение 10 недель, в течение которых их уровни тяжелой воды повышались примерно до 2,5% от массы тела без каких-либо побочных эффектов (Biochimica et Biophysica Acta, vol 1760, p 730).

Тяжелая вода, однако, не полностью безопасна. В млекопитающих токсичный эффект начинается где-то с отметки в 20%, и при дозе 35% летальна. В многом это происходит из-за эффекта изотопа — каждый протеин в твоем теле имеет потенциал взять атом дейтерия тяжелой воды вместо водорода, и однажды это радикально меняет всю биохимию. Все же требуется немалое количество тяжелой воды, чтобы пострадать от любого болезненного эффекта — 5 миллилитров не повредит тебе ничем, но даже так стартапы вроде Retrotrope не рекламируют тяжелую воду как эликсир жизни.

Михаил Щетинов выступает о пользе эффекта изотопа в Белоруском государственном университете

В то время как Retrotope концентрирует свои усилия на старении, Щепинов говорит, что есть другие применения изотопного эффекта, который он хотел бы изучить. Один из них защищает долгосрочных космических путешественников от воздействия космических лучей и другого ионизирующего излучения, которые наносят ущерб, как старение.

Другая возможность заключается в производстве мяса, яиц или молока, обогащенного дейтерием или углеродом-13, путем подачи дейтерированной воды или обогащенных изотопами аминокислот для сельскохозяйственных животных.

Идея использования химических изотопов для борьбы со старением может быть новой, но природа уже действует таким образом чтобы защитить нас от свободнорадикальной атаки, которая считается основной причиной старения. Младенцы и мыши рождаются с гораздо большим количеством изотопного углерода-13 в своих телах, чем их матери, и женщины, как представляется, становятся необычно истощенными в углероде-13 во время их рождения. Оба вывода свидетельствуют о активной передачи углерода-13 от матери к плоду. Это будет иметь хороший эволюционный смысл, поскольку многие из белков и молекул ДНК сформированные на раннем этапе, должны быть с нами всю жизнь. «Каждый отдельный атом в ДНК мозга 100-летнего человека является тем же атомом, что и когда ему было 15 лет».

Еще одним препятствием Retrotope придется преодолеть стоимость. В текущих ценах литр тяжелой воды стоит вам 300 долларов. «Изотопы дороги, — говорит Щепинов. «Но никому не нужно, чтобы они были дешевы. Методы, чтобы их добывать есть, но никто не хочет их». Если спрос не будет возрастать, нет стимула производить их навалом, и это удерживает высокую цену.

Также пропорция тяжелых изотопов в метаболитах и аминокислотах может служит биомаркером возраста человека.

Было бы интересно открыть, если мышь напоенная определенной концентрацией оксида дейтерия тоже жила бы дольше…

С целью освоения библиотек для работы с нейронными сетями, решим задачу аппроксимации функции одного аргумента используя алгоритмы нейронных сетей для обучения и предсказания аппроксимации.

Вступление

Пусть задана функция f:[x0,x1]->R

Аппроксимируем заданную функцию f формулой

• P(x) = SUM W[i]*E(x,M[i])

где

• i = 1..n
• M[i] из R
• W[i] из R
• E(x,M) = { 0, при x<M; 1/2, при x=M; 1, при x>M

Очевидно, что при равномерном распределении значений M[i] на отрезке (x0,x1) найдутся такие величины W[i], при которых формула P(x) будет наилучшим образом апроксимировать функцию f(x). При этом, для заданных значений M[i], определённых на отрезке (x0,x1) и упорядоченных по возрастанию, можно описать последовательный алгоритм вычисления величин W[i] для формулы P(x).

А вот и нейросеть

Преобразуем формулу P(x) = SUM W[i]*E(x,M[i]) к модели нейросети с одним входным нейроном, одним выходным нейроном и n нейронами скрытого слоя

• P(x) = SUM W[i]*S(K[i]+B[i]) + C

где

• переменная x — «входной» слой, состоящий из одного нейрона
• {K, B} — параметры «скрытого» слоя, состоящего из n нейронов и функцией активации — сигмоида
• {W, C} — параметры «выходного» слоя, состоящего из одного нейрона, который вычисляет взвешенную сумму своих входов.
• S — сигмоида,

при этом

• начальные параметры «скрытого» слоя K[i]=1
• начальные параметры «скрытого» слоя B[i] равномерно распределены на отрезке (-x1,-x0)

Все параметры нейросети K, B, W и C определим обучением нейросети на образцах (x,y) значений функции f.

Сигмоида

Сигмоида — это гладкая монотонная возрастающая нелинейная функция

• S(x) = 1 / (1 + exp(-x)).

Программа

Используем для описания нашей нейросети пакет Tensorflow

# узел на который будем подавать аргументы функции x = tf.placeholder(tf.float32, [None, 1], name="x")  # узел на который будем подавать значения функции y = tf.placeholder(tf.float32, [None, 1], name="y")  # скрытый слой nn = tf.layers.dense(x, hiddenSize,                      activation=tf.nn.sigmoid,                      kernel_initializer=tf.initializers.ones(),                      bias_initializer=tf.initializers.random_uniform(minval=-x1, maxval=-x0),                      name="hidden")  # выходной слой model = tf.layers.dense(nn, 1,                         activation=None,                         name="output")  # функция подсчёта ошибки cost = tf.losses.mean_squared_error(y, model)  train = tf.train.GradientDescentOptimizer(learn_rate).minimize(cost) 

Обучение

init = tf.initializers.global_variables()  with tf.Session() as session:     session.run(init)      for _ in range(iterations):          train_dataset, train_values = generate_test_values()          session.run(train, feed_dict={             x: train_dataset,             y: train_values         }) 

Полный текст

import math import numpy as np import tensorflow as tf import matplotlib.pyplot as plt  x0, x1 = 10, 20 # диапазон аргумента функции  test_data_size = 2000 # количество данных для итерации обучения iterations = 20000 # количество итераций обучения learn_rate = 0.01 # коэффициент переобучения  hiddenSize = 10 # размер скрытого слоя  # функция генерации тестовых величин def generate_test_values():     train_x = []     train_y = []      for _ in range(test_data_size):         x = x0+(x1-x0)*np.random.rand()         y = math.sin(x) # исследуемая функция         train_x.append([x])         train_y.append([y])      return np.array(train_x), np.array(train_y)  # узел на который будем подавать аргументы функции x = tf.placeholder(tf.float32, [None, 1], name="x")  # узел на который будем подавать значения функции y = tf.placeholder(tf.float32, [None, 1], name="y")  # скрытый слой nn = tf.layers.dense(x, hiddenSize,                      activation=tf.nn.sigmoid,                      kernel_initializer=tf.initializers.ones(),                      bias_initializer=tf.initializers.random_uniform(minval=-x1, maxval=-x0),                      name="hidden")  # выходной слой model = tf.layers.dense(nn, 1,                         activation=None,                         name="output")  # функция подсчёта ошибки cost = tf.losses.mean_squared_error(y, model)  train = tf.train.GradientDescentOptimizer(learn_rate).minimize(cost)  init = tf.initializers.global_variables()  with tf.Session() as session:     session.run(init)      for _ in range(iterations):          train_dataset, train_values = generate_test_values()          session.run(train, feed_dict={             x: train_dataset,             y: train_values         })          if(_ % 1000 == 999):             print("cost = {}".format(session.run(cost, feed_dict={                 x: train_dataset,                 y: train_values             })))      train_dataset, train_values = generate_test_values()      train_values1 = session.run(model, feed_dict={         x: train_dataset,     })      plt.plot(train_dataset, train_values, "bo",              train_dataset, train_values1, "ro")     plt.show()      with tf.variable_scope("hidden", reuse=True):         w = tf.get_variable("kernel")         b = tf.get_variable("bias")         print("hidden:")         print("kernel=", w.eval())         print("bias = ", b.eval())      with tf.variable_scope("output", reuse=True):         w = tf.get_variable("kernel")         b = tf.get_variable("bias")         print("output:")         print("kernel=", w.eval())         print("bias = ", b.eval())

Вот что получилось

• Синий цвет — исходная функция
• Красный цвет — аппроксимация функции

Вывод консоли

cost = 0.15786637365818024 cost = 0.10963975638151169 cost = 0.08536215126514435 cost = 0.06145831197500229 cost = 0.04406769573688507 cost = 0.03488277271389961 cost = 0.026663536205887794 cost = 0.021445846185088158 cost = 0.016708852723240852 cost = 0.012960446067154408 cost = 0.010525770485401154 cost = 0.008495906367897987 cost = 0.0067353141494095325 cost = 0.0057082874700427055 cost = 0.004624188877642155 cost = 0.004093789495527744 cost = 0.0038146725855767727 cost = 0.018593043088912964 cost = 0.010414039716124535 cost = 0.004842184949666262 hidden: kernel= [[1.1523403  1.181032   1.1671464  0.9644377  0.8377886  1.0919508   0.87283015 1.0875995  0.9677301  0.6194152 ]] bias =  [-14.812331 -12.219926 -12.067375 -14.872566 -10.633507 -14.014006  -13.379829 -20.508204 -14.923473 -19.354435] output: kernel= [[ 2.0069902 ]  [-1.0321712 ]  [-0.8878887 ]  [-2.0531905 ]  [ 1.4293027 ]  [ 2.1250408 ]  [-1.578137  ]  [ 4.141281  ]  [-2.1264815 ]  [-0.60681605]] bias =  [-0.2812019]

Исходный код

https://github.com/dprotopopov/nnfunc

Наиболее часто задаваемый мне вопрос по использованию рекурсивной маршрутизации звучит так: «Что делать, если основной провайдер назначает нам ip-адрес через dhcp, при этом часто изменяется шлюз по-умолчанию?».

Для чего нужна рекурсивная маршрутизация? Для мониторинга наличия интернета за шлюзом провайдера. Ведь нередко случается, что маршрутизатор провайдера прекрасно отвечает на эхо-запросы, но [ап]линк в глобальную сеть у провайдера о какой-то причине пропал.
Рекурсивная маршрутизация позволяет оценить наличие доступа в Интернет через выбранного провайдера и принять решение о маршрутизации трафика.
Однако, дело в том, что использование рекурсивной маршрутизации предполагает наличие прибитого гвоздями прямое явное указание IP-адреса шлюза среди параметров создаваемого маршрута. Указание в качестве шлюза имени broadcast-интерфейса является неправильным и во многих случаях просто не работает, т.к. требует наличия proxy-arp со стороны провайдера. А еще, вместо провайдера proxy-arp может включить ваш сосед про провайдерскому свитчу и попытаться перехватить таким образом ваш трафик, устроив классический MITM!

Магия рекурсивной маршрутизации прячется за параметрами «scope» и «target-scope». Чтобы маршрут работал как рекурсивный, его «target-scope» должен быть больше или равен значению «scope» у статического маршрута на который он ссылается рекурсивно, а указанный в маршруте шлюз лежал вне прямой досягаемости через один из интерфейсов.

Рассмотрим простейшую схему Active/Backup. Наш маршрутизатор выполнятет NAT и подключен к двум провайдерам посредством интерфейсов Ether1-isp1 и Ether2-isp2. Основной провайдер (ISP-1) раздаёт своим клиентам IP-адреса посредством протокола DHCP и никак иначе. Второй провайдер предоставляет нам статический IP-адрес, но значительно меньшую скорость.
Переключение на запасного (ISP-2) должно происходить тогда, когда доступ в Интернет через основного провайдера становится невозможным.

Изюминкой от провайдера для подобной схемы является периодическая произвольная смена не только IP-адреса клиента, но и default-gateway.

До версии 6.39 мне приходилось видеть весьма изощренные костыли в различных комбинациях sheduler, netwatch и тому подобных механизмов.
Начиная с версии 6.39 разработчики RouterOS пошли навстречу таким пользователям и создали возможность вызывать специальный скрипт при срабатывании dhcp-клиента на устройстве.
Собственно решение состоит из двух частей:
1) нужно получить по протоколу dhcp от провайдера IP-адрес и адрес шлюза для использования в рекурсивных маршрутах
2) полученный от провайдера адрес шлюза из автоматического использования по возможности исключить.
Итак, начнём с конца.
Создадим резервный маршрут через «ISP-2» со значением «distance» больше, чем у будущего основного. В данном примере я использовал «distance=2»:

Далее, для того, чтобы получать от провайдера «ISP-1» маршрут по-умолчанию, но прямо его не использовать, существует специальное значение «distance=255». Маршрут с таким значением distance попадет в системную таблицу маршрутизации, но никогда не станет активным.

Такой маршрут нужен нам только для чтения присланных провайдером параметров и внедрением их в настройки рекурсивных маршрутов посредством скрипта.
Из полученных параметров, нас более других интересует переменная $gateway-address. Как можно догадаться из названия, она содержит в себе адрес шлюза по-умолчанию в сети провайдера. Её мы и будем использовать, чтобы привести рекурсивные маршруты в актуальное состояние.
Сами же рекурсивные маршруты должны быть корректно опознаны из скрипта. Для этого, на этапе их создания мы укажем уникальный «comment», который и будет использоваться для их поиска внутри таблицы. Код создания рекурсивной пары маршрутов:

Первая строка должна (и будет!) указывать на настоящий шлюз в сети провайдера лишь после того, как провайдер выдаст параметры по dhcp и они будут обработаны посредством dhcp-client script:

Теперь, при получении от провайдера «ISP-1» IP-адреса для использования в качестве шлюза по-умолчанию, он будет внесен в маршрутную пару вместо «127.0.0.1».
Вторая строка, где указан маршрут до 0.0.0.0/0, собственно и осуществляет всю магию. Указанный там в качестве шлюза узел 8.8.4.4 будет проверяться на отклик опцией «check-gateway=ping» именно через сеть ISP-1. В случае если узел 8.8.4.4 не ответит дважды на эхо-запросы в течение 20 секунд, маршрутизатор будет считать связь с Интернетом через этот маршрут (ISP-1) недоступной. Новые соединения в этом случае будут направлены через запасного провайдера ISP-2.

Если всё сделано правильно, то в окне winbox /ip->routes около маршрута до 8.8.4.4 будет видно слова «resursive via…». Это значит маршрут построился именно как рекурсивный.

В завершении, исключительно для примера — скрин окна винбокса:

Сейчас, когда есть отличный mavic и уже появился еще более блистательный mavic 2, вопрос «какой дрон купить для путешествий» не стоит. Но все же, если у Вас остался phantom 3, который менять на mavic по тем или иным причинам еще не хочется, а возить с собой в поездки неудобный кофр/коробку надоело, есть интересное решение — складной корпус, который позволяет сделать фантом почти таким же мобильным как mavic. Называется он, неожиданно, Phavic. Я опробовал превращение на своем фантоме, об этом — под катом.

Изначально корпус разработан некими ребятами, называющими себя DJIYSJL. Сейчас его можно найти на banggood, amazon, ebay и т.д. по словам «phavic to mavic conversion kit», ну или у разных продавцов на aliexpress по словам «Phantom привидение 3 Adv Pro преобразовать складной чулки Дрон как DJI большой mavic » или что-то такое. Стоимость примерно 4500-5000 рублей.

По моим впечатлениям и отзывам других пользователей, среднее время полета с этим корпусом сократилось совсем немного. Может на пару минут. Моторы в положении с разложенными лучами разнесены чуть больше, чем у оригинала. В сложенном состоянии он теперь помещается в коробку размером 32×18х12 см (без пульта)

Одним из отличий от оригинального корпуса является отсутствие больших ног. Компоновка напоминает мавик, а значит камера находится близко к земле и это надо учитывать, выбирая место взлета.

Корпус так продуман, что всю начинку из фантома можно аккуратно достать и переставить в подготовленные места. Основной сложностью является то, что провода моторов и светодиодов из лучей надо аккуратно отпаять от платы, нарастить, вставить в новые лучи и припаять назад. Также внутрь этих лучей надо будет вставить антенны, которые располагались в ногах оригинального корпуса. Если Вы это сделали — считайте, что две трети дела сделано.

Корпуса для версий Pro/Advanced и Standart ожидаемо различаются. Дело в том, что в версии standart SD-карточка вставляется в саму камеру, а не в основание подвеса камеры. А так как в фавике подвес прячется внутрь корпуса, то для доступности microSD-карточки на Pro/Advanced в комплекте идет маленький удлинительный шлейф, крепящийся к специальной щели на корпусе фавика. Для версии Std такой шлейф не нужен, так как слот microSD на камере и так доступен. Еще одно различие между Std и Adv/Pro в наличии блока позиционирования. Один из шлейфов связывает подвес и блок позиционирования. На фавике компоновка другая, расстояние между подвесом и блоком позиционирования увеличилось, поэтому в комплекте к Adv/Pro дополнительно идет удлинённый вариант этого шлейфа.

*На фото видно, что блок подвеса спрятан внутрь корпуса. Шлейф из комплекта можно спрятать внутрь так, чтобы карточку вставлять через щель в корпусе. Кому как более удобно.

Развернутой и подробной инструкции по сборке фантома на русском или английском языке не существует, но на youtube есть видео, где китайский гражданин полностью выполняет все действия, подробно рассказывая о них на китайском языке. К сожалению, перевод в субтитрах более чем немногословен. Впрочем, на видео все и так видно.

Если Вам нюансы сборки не интересны, то в конце статьи есть краткое видео о процессе в общем. А для тех, кто задумался о такой переделке, я опишу то, что не было упомянуто в переводе китайского видео и других местах.

Первое, что надо иметь в виду, это правильный выбор корпуса у продавца. Если у Вас Pro или Advanced, то получив корпус для Standart, Вам будет сильно не хватать предусмотренных удлиняющих шлейфов. По личному опыту, продавцы сами не очень понимают разницу, если в описании явно не написано, стоит уточнить.

Когда корпус доставят, стоит внимательно осмотреть все детали и счистить облой с краев и отверстий. Иначе аккуратно собрать не получится. Качество исполнения деталей не на самом высоком уровне, но к счастью, все решается напильником и острым ножичком. Рекомендую заранее примерить на корпусе петли раскладывающихся лучей, чтобы при сборке они вставали уже без проблем (это можно увидеть на кратком видео в конце статьи)

В комплекте идет 6 типов винтов для сборки нового корпуса. Если их разложить по кучкам, становится понятно, какие для чего нужны. Их назначение упоминается и в оригинальном китайском видео. Но если вдруг останутся сомнения, то номера 3 и 4 используются для сборки лучей.

Компас фантома тоже находится в одной из ног. Когда Вы его достанете, первым делом убедитесь, что не положили рядом с каким-нибудь магнитом. Когда Вы поставите его внутрь корпуса фавика, то относительно положения в корпусе фантома он окажется повернут на 90 градусов вокруг горизонтальной оси. А значит, при калибровке компаса, при первом обороте фавик надо держать вертикально, а при втором обороте надо держать фавик горизонтально (тогда как фантом надо было держать горизонтально, а второй оборот делать держа его повернутым на 90 градусов вокруг горизонтальной оси). Это важный момент, однако я нигде не встретил упоминания об этом.

Регуляторы для моторов фантома находятся на основной плате, а провода жирно припаяны. Это значит, что придется постараться, чтобы их отпаять и потом припаять назад удлиненные, ничего не перегрев.

В ногах у фантомов спрятаны четыре антенны. У фавика таких элегантных и мешающихся ног нет. Поэтому антенны укладываются в те же складные лучи. Когда Вы будете отсоединять их от разъемов при разборке фантома, обратите внимание, что на плате подписаны номера от 1 до 4. Те же номера написаны на самих антеннах для того, чтобы не перепутать.

С антеннами есть небольшой нюанс и я надеюсь, меня поправят в комментариях, если я опишу неправильно. Стандартные антенны на пульте фантома имеют круговую диаграмму направленности и вертикальную поляризацию (при вертикальной ориентации), что хорошо сочетается с вертикально ориентированными антеннами в ногах фантома. Единственная ситуация, для которой это неудобно — вертикальный взлет ровно вверх. Так как антенны можно направить горизонтально, но поляризация совпадать не будет. В связи с этим многие замечают, что для стабильной связи на максимальной высоте полезно отвести фантом немного в сторону от себя. В случае же с фавиком и его горизонтально расположенными в лучах антеннами ситуация теоретически должна быть обратной — уверенная связь до самого верха и уменьшения радиуса дальности при небольшой высоте. На практике же я, если честно, заметной разницы в дальности не ощутил. Возможно, кому-то найдется, что добавить.

Вот основная информация, надеюсь, после этой статьи чей-то фантом будет реже пылиться на полке, когда хозяин уезжает в путешествие 🙂

Возможно, я что-то упустил, на все вопросы готов ответить в комментариях.