А нет ли у вас информации, на сколько сильно сокращается срок жизни литий-полимерного аккумулятора, если его заряжать большими токами? Например, у меня есть 1000мА*ч аккумулятор с максимальным током заряда 5С. Какое количество циклов он может прожить, если заряжать его токами 1С, 2С и 5С?
Я бы на счёт «без риска для здоровья оператора» не был так уверен. Если на дрон вешать камеру весом в 3кг (скажем, зеркалку + объектив), то винты дюже здоровые будут. Зазеваешься — получишь глубокие порезы, а то и палец отрубит.
Я тут недавно примонстрячил к хвосту от вертолёта 450 класса лопасти 120мм каждая. Тяга получилась в немного меньше 500 грамм. В процессе измерения максимальной тяги лопасть слегка задела пустую лежащую коробку из-под лампочки накаливания, которую (коробку, не лампочку) я использовал в качестве подставки, прорезала картон сбоку и отрезала половину крышечки коробки. Это лопасть квадрика, который будет таскать максимум 500 грамм полезного груза. Понимаете, на сколько опасны тяжёлые квадрокоптеры?
GPS приёмник и так уже решает задачу пересечения сфер методом наименьших квадратов.
И при этом все три круга будут смещены в сторону от реальных координат на 5 метров. В какую сторону и на сколько — зависит от кучи факторов.
К тому же, телефон выдаёт вам координаты с точностью в 10 метров при вероятности ошибки 50%. Сколько измерений вы будете делать, чтобы получить итоговую погрешность в 1 метр при 95% вероятности? А что будете делать, когда во время измерения координаты на всех 3 девайсах будут плавно уплывать в разные стороны?
То, о чём вы говорите — это постпроцессинг, но для него нужны сырые данные с приёмника, желательно с фазой сигнала. Затем скачать точные орбиты спутников, обычно доступны через несколько часов после измерения. Потом — данные по ионосферным задержкам. Вот тогда можно говорить о точности в сантиметры. Софт уже много раз написан, есть даже open source система под названием RTKLIB. Только вот GPS чип в iPhone5 вам сырые данные не отдаст.
Можно поглядеть в даташитах, если получится их достать. Например, uBlox для NEO6 указывает точность так: CEP, 50%, 24 hours static, -130dBm, SEP: <3.5m.
Если он даёт 3D позицию при 3 спутниках GPS и 3 ГЛОНАСС — значит умеет dual constellation. При этом различные фазовые искажения антенны совершенно не столь важны, при точности в +-5 метров фаза в рассчётах учитываться не должна (в RTKLIB не учитывается).
Про оценку точности, честно говоря, не очень понял, что вы имели в виду. Оценку точности работы навигации в iPhone5 в помощью гедезического приёмника? Про то, что надо сначала подготовиться к эксперименту и постараться минимизировать системные погрешности — полностью согласен.
Из того, что я читал (к сожалению, линков сходу не вспомню), некоторые чипы умеют работать с GPS+ГЛОНАСС как единым созвездием, но с разными альманахами, в итоге видно больше спутников, большее количество находится не в зените. Судя по картинкам, использовался RTKLIB, и я не уверен, что он с двумя альманахами сразу умеет работать. Возможно, фазовые искажения, вносимые антенной, отличаются на GPS и ГЛОНАСС частотах, а RTKLIB тоже может не уметь такого.
Да и у него итоговая погрешность +-5 миллиметров и PPP, это другая лига.
Да, это немного другое. Но как система убедится, что у меня в этом репозитории все-все коммиты уже есть, перед тем, как положить туда мой? Чтобы мне что-то положить и не вызвать конфликтов, мой HEAD должен быть не старее, чем у кого либо ещё. Тут какая-то синхронность нужна. Может, какой нибудь PAXOS наворачивать надо. Только тогда в выходные дни никто коммит положить не сможет, потому что кворум не наберётся :)
У 10 разработчиков редко когда бывает одинаковый master. Наверное, вы не сталкивались с ситуацией: делаешь коммит, пуллишь мастер ветку, мержишь, пытаешься сделать пуш — а там уже ещё один коммит упал. Снова пулл, мерж, и потенциально опять феил при пуше. Иногда это развлечение растягивается надолго. А если будет 100 человек — то совсем беда. И все они никак не синхронизируются. Это первая половина проблемы.
Вторая половина — откуда билдферме брать правильную версию. Либо должен быть ответственный, который в специальное место выкладывает правильно смерженные исходники, либо ферма будет собирать что-то непонятное.
С очерёдностью коммитов тоже засада — мне приехали изменения от коллеги, я замержил всё, всё работает. Второй коллега тоже замержил к себе изменения первого, и присылает результат мне. Его коммит должен встать перед моим, но тогда у меня всё поломается. Его коммит может встать после моего, тогда мне надо его коммит мержить, а ему потом мёржить мой мёрж с его новым кодом. Код гарантированно (с точки зрения VCS) собирается только в одном случае — все коммиты присутствуют и располагаются в правильном порядке. Если хотя бы одного не хватает — никаких гарантий. Может быть, именно в том коммите была создана какая нибудь переменная, которую потом все активно используют.
Мне кажется, правильный ответ на ваш вопрос — идея то, может, и хороша, но технически не реализуема, не взлетит. С другой стороны, при изобретении вечных двигателей много всякого полезного напридумывали по ходу дела.
Не раскрыт вопрос проблем с merge в вашей равнораспределённой архитектуре. Есть ощущение, что при >10 разработчиках консистентной версии, которую можно положить в билдферму и там собрать, никогда не будет.
Частенько хватало низко проходящей тучи, чтобы на длинных междомовых линках порты повышибало. Была у нас в городе одна сетка году в 2000, так они летом свитчи не меняли, типа всё равно сгорят :) Так и работали, с сентября по май, затем сеть разваливалась на куски, в сентябре соединялась снова. Но интернет тогда ещё через локалку не продавали, всё на добровольных началах делалось.
А у вас он возвращает hex в виде строки? Если модуль для php из исходников ставили — то просто пропатчте его, чтобы uint возвращал, и будет вам счастье в виде хорошей хэш-функции, возвращающей чиселку.
Ну вот 32 бита — это как раз uint32_t. Я hashmurmur2 в плюсовом коде использую, и интерпретирую ответ именно как чиселку, сразу делю ей на количество хэш-бакетов. Не знаю, как именно сделано в php, поэтому не могу посоветовать, как с результатом работать.
Я тут недавно примонстрячил к хвосту от вертолёта 450 класса лопасти 120мм каждая. Тяга получилась в немного меньше 500 грамм. В процессе измерения максимальной тяги лопасть слегка задела пустую лежащую коробку из-под лампочки накаливания, которую (коробку, не лампочку) я использовал в качестве подставки, прорезала картон сбоку и отрезала половину крышечки коробки. Это лопасть квадрика, который будет таскать максимум 500 грамм полезного груза. Понимаете, на сколько опасны тяжёлые квадрокоптеры?
И при этом все три круга будут смещены в сторону от реальных координат на 5 метров. В какую сторону и на сколько — зависит от кучи факторов.
К тому же, телефон выдаёт вам координаты с точностью в 10 метров при вероятности ошибки 50%. Сколько измерений вы будете делать, чтобы получить итоговую погрешность в 1 метр при 95% вероятности? А что будете делать, когда во время измерения координаты на всех 3 девайсах будут плавно уплывать в разные стороны?
То, о чём вы говорите — это постпроцессинг, но для него нужны сырые данные с приёмника, желательно с фазой сигнала. Затем скачать точные орбиты спутников, обычно доступны через несколько часов после измерения. Потом — данные по ионосферным задержкам. Вот тогда можно говорить о точности в сантиметры. Софт уже много раз написан, есть даже open source система под названием RTKLIB. Только вот GPS чип в iPhone5 вам сырые данные не отдаст.
Если бы вы были правы — никто бы не покупал дорогие геодезические приёмники.
Про оценку точности, честно говоря, не очень понял, что вы имели в виду. Оценку точности работы навигации в iPhone5 в помощью гедезического приёмника? Про то, что надо сначала подготовиться к эксперименту и постараться минимизировать системные погрешности — полностью согласен.
Да и у него итоговая погрешность +-5 миллиметров и PPP, это другая лига.
Вторая половина — откуда билдферме брать правильную версию. Либо должен быть ответственный, который в специальное место выкладывает правильно смерженные исходники, либо ферма будет собирать что-то непонятное.
С очерёдностью коммитов тоже засада — мне приехали изменения от коллеги, я замержил всё, всё работает. Второй коллега тоже замержил к себе изменения первого, и присылает результат мне. Его коммит должен встать перед моим, но тогда у меня всё поломается. Его коммит может встать после моего, тогда мне надо его коммит мержить, а ему потом мёржить мой мёрж с его новым кодом. Код гарантированно (с точки зрения VCS) собирается только в одном случае — все коммиты присутствуют и располагаются в правильном порядке. Если хотя бы одного не хватает — никаких гарантий. Может быть, именно в том коммите была создана какая нибудь переменная, которую потом все активно используют.
Мне кажется, правильный ответ на ваш вопрос — идея то, может, и хороша, но технически не реализуема, не взлетит. С другой стороны, при изобретении вечных двигателей много всякого полезного напридумывали по ходу дела.
Как вообще процесс выкладки происходит? Вот есть новый билд (кстати, что это: набор php файлов, большой бинарь, пакет?), как он попадает на машины?