Посмею сделать догадку за автора. Прикидывая результаты тестов данной платформы и общий вес, а также 8Ah аккумулятор, думаю что порядка 20 минут при отсутствии сильного ветра.
Вполне, советую начать с квадрокоптера и размером поменьше (40-50см в диаметре от мотора до мотора), меньше деталей (4 мотора и 4 контроллера скорости) упрощают обслуживание, а меньший размер — использование и обучение полету. Даже если вы не собираетесь учиться в летать в ручном режиме (он так же известен как manual, rate, acro и т.п., суть в том, что в этом режиме идёт управление угловой скоростью коптера по трём осям, а не самим углом наклона), не исключены падения и ситуации, в которых коптер полетит куда-то не туда, так что меньший размер убережет вас и окружающих от большего ущерба.
Есть очень неплохая рама на hobbyking — Turnigy Talon v2 Quadcopter.
Много всего, все ограничивается лишь полетом фантазии и желанием.
За два месяца общения с трикоптером (сборка + обслуживание) я сделал следующее:
1. Перепаял коннекторы ESC к источнику питания и моторам (3.5mm bullet)
2. 3.5mm коннекторы на моторы (мои DT750 идут с 3 проводами для фаз, без каких либо коннекторов, некоторые паяют их напрямую к монтажным площадкам ESC)
2. Программатор для перепрошивки каждого ESC (4-6 мелких монтажных площадки на каждом и 20-24 AWG провода к ним)
3. XT60 в 3.5mm bullet разветвитель + пара проводов для запитывания всяких FPV и прочих приспособлений
4. Banana коннектор для зарядника Turnigy Accucel 8150 (оригинал идёт с зажимами-крокодилами, что не очень удобно в связке с моим источником питания)
5. Программатор, подсветка и куча всяких мелочей для пульта Turnigy 9x
6. Header штырек для KK2.0, чтобы измерять напряжение аккумулятора
Попутно появилось желание запаять в доме и машине все, что требовало пайки и вообще любовь к этому делу.
Конечно, можно купить такие комплектующие, на которых коннекторы уже напаяны, но для меня это теперь не проблема.
Если есть готовность паять, то берите 9X. Я два месяца назад собрал своей первый трикоптер, потом неделю неспешно паял всякие штуки типа подсветки с регулировкой яркости, программатор, поддержку телеметрии, скоро еще хочу заменить стики на Aurora 9, но в целом сейчас все работает идеально.
А если бюджет не поджимает, то очень рекомендую FrSky Taranix X9D Plus.
Пардон, static вам, видимо, не подходит из-за необходимости добавить аттрибут PROGMEM.
Я предлагал завести тип со статическими полями, объявленными примерно так:
struct Strings {
static constexpr auto&& Prompt /*PROGMEM*/ = "Are you sure you want to format SD-card?";
};
но видимо
static
и
PROGMEM
не сочетаемы, так как по сути оба являются storage спецификаторами.
Можно вот так, грамматика практически воплощается в синтаксисе языка, на котором пишется парсер. Испозуется short-circuiting бинарных булевых операторов.
Когда у меня временно не было своего места для компьютера, меня спас длинный HDMI кабель, телевизор и Dual Shock 4. С ними я прошел GTA 4 и Fallout: New Vegas прямо сидя на диване :-) Свои плюсы есть. Конечно, есть игры, где намного больше удовольствия с клавиатурой и мышью (с джойстиком там просто будет мучение).
const на user-defined типе, возвращаемом из функции, препятствует move-семантике, и никакой пользы не приносит. Поскольку может происходить копирование, этот const все равно ничего не дает. const (не top-level) имеет смысл при возврате из функции только если возвращается ссылочный тип (ссылка или указатель).
Очень занимательно, спасибо!
Можно предположить, что в мире игры очень много состояния, и какие-то области памяти содержат значения, которые в разное время растут и убывают. Сильно мешали подобные значения при поиске скорости персонажа? Или прием с «увеличили, потом уменьшили» отсек большинство мусора?
Стоило использовать std::vector<std::string> вместо сырого владеющего указателя, не хочется вектор — тогда std::unique_ptr<std::string[]>.
if(Word.find('-')!=-1)
Cтоит использовать std::string_type::npos, эта константа не обязана быть -1.
Использование const на возвращаемом по значению типе предотвращает всякие оптимизации.
А насколько это легально в странах на видео? Я недавно собрал трикоптер с камерой, его удобно складывать и транспортировать, хочу попутешествовать с ним по миру и поснимать :-)
Разные потребности бывают, иногда и на очень низкий уровень приходится опуститься, до всяких intrinsic'ов и прочего, там и цикл по индексам может пригодиться, но старый-добрый for не кошере, а решение с мета-оберткой и range-based for хорошо оптимизируется и более читаемо. Например, вариант приведенный мною ниже, в GCC/CLang последних версий с -O2/-O3 компилируется в машинный код, эквивалентный коду, получаемому из hand-written for по индексам.
Есть очень неплохая рама на hobbyking — Turnigy Talon v2 Quadcopter.
За два месяца общения с трикоптером (сборка + обслуживание) я сделал следующее:
1. Перепаял коннекторы ESC к источнику питания и моторам (3.5mm bullet)
2. 3.5mm коннекторы на моторы (мои DT750 идут с 3 проводами для фаз, без каких либо коннекторов, некоторые паяют их напрямую к монтажным площадкам ESC)
2. Программатор для перепрошивки каждого ESC (4-6 мелких монтажных площадки на каждом и 20-24 AWG провода к ним)
3. XT60 в 3.5mm bullet разветвитель + пара проводов для запитывания всяких FPV и прочих приспособлений
4. Banana коннектор для зарядника Turnigy Accucel 8150 (оригинал идёт с зажимами-крокодилами, что не очень удобно в связке с моим источником питания)
5. Программатор, подсветка и куча всяких мелочей для пульта Turnigy 9x
6. Header штырек для KK2.0, чтобы измерять напряжение аккумулятора
Попутно появилось желание запаять в доме и машине все, что требовало пайки и вообще любовь к этому делу.
Конечно, можно купить такие комплектующие, на которых коннекторы уже напаяны, но для меня это теперь не проблема.
А если бюджет не поджимает, то очень рекомендую FrSky Taranix X9D Plus.
Я предлагал завести тип со статическими полями, объявленными примерно так:
но видимо и не сочетаемы, так как по сути оба являются storage спецификаторами.
И удостовериться, что во всех translation unit'ах используется один и тот же экземпляр.
Можно предположить, что в мире игры очень много состояния, и какие-то области памяти содержат значения, которые в разное время растут и убывают. Сильно мешали подобные значения при поиске скорости персонажа? Или прием с «увеличили, потом уменьшили» отсек большинство мусора?
Cтоит использовать std::string_type::npos, эта константа не обязана быть -1.
Использование const на возвращаемом по значению типе предотвращает всякие оптимизации.