Стандартная «фоторезьба» это дюймовая 1/4-20 UNC и 3/8-16 UNC резьбы. Кстати, из-за того что это дюймовки то найти такой крепеж у нас малореально. Метчики и плашки тоже сложно.
1) По поводу шаговика смотрите ответ на предыдущий комментарий. По расчетам, на угловое расстояние эквивалентное 1 пикселу камеры будет приходится 119 шагов.
2) По наводке на полярную звезду план таков. Выставить телевик с максимальным зумом на нее и сделать несколько снимков с выключенными и потом с включенным трекером на повышенной скорости. Подстроить позицию так что бы вращение было примерно вокруг нее. Когда таким образом откалибрую установку то прикручу искатель от телескопа и настрою его уже на выстроенной системе для дальнейшей более удобной эксплуатации.
Сейчас я не рассчитывают на очень длинные выдержки. Опыта мало. Надеюсь что в течении недели-двух удастся провести полноценные полевые испытания. Все упирается в погоду.
Наверное, она нагуглилась просто быстрее. Я пробовал вручную давать команды двигателю, но не получалось достичь плавности движения на больших и малых оборотах. Либо там, либо — там. А с AccelStepper удобно, движения очень плавные на любых скоростях. Она умеет float steps per second делать. Т.е. можно хоть за час оборот совершить.
Предел этого двигателя при питании от 5V регулятора ардуины (но не через USB) — 1200-1300 шагов в секунду.
На той фото провалы в треках по большей части вызваны переменной облачностью. Присмотритесь — на фото почти везде есть облака. Облака двигаются и перекрывают звезды то тут то там.
Угол зрения у 70-200/2.8 на 200мм составляет 10.3 градуса по горизонтали. В 5D Mark II по горизонтали 5616 пикселов. Получается что на один пиксел приходится 0.001834045584 градуса.
Радиус шпильки 182.85 мм. Длина окружности 1148.92мм. За 1 минуту гайка совершает 1 оборот и шпилька проходит 0.8 мм. Это примерно 1148.92 / 360 / 0.8 = 0.25 градуса.
Двигатель за минуту совершает 4 оборота. Т.е. его один оборот сдвигает шпильку на 0.06266725885 градуса.
За один оборот двигатель делает примерно 4075 шагов. Т.е. за один шаг двигатель сдвигает шпильку на 0.00001537846843 градуса. Что на два порядка меньше чем каждый пиксел камеры видит на небе. Мне кажется, что это более чем достаточно. Думаю что дрожание всей конструкции будет давать гораздо более значительные искажения чем неточность движения двигателя.
Так для тиражных продуктов нужно и модуль припаять к плате чтоб не отвалился (т.к. нет отверстия для крепления) и не окислились контакты, и питание свое сделать (в тираже оно будет подаваться явно не через microusb). Ну и антенна на борту скорее всего будет лишней т.к. будет использована внешняя через SMA-разъем.
Т.е. для тиража конкретно эта реализация не очень удобна как по мне. Для энтузиастов же удобнее дев-борд с модулем на борту и набором разъемов что б точно не нужно было ничего паять. А-ля Ардуино.
И получается что карамбола и китайцы уже предлагают это все за соизмеримые деньги.
Вот чего не хватает на карабмоле так это большого и быстрого хранилища для данных. Приходится городить хаб и вешать флешку. Было бы удобно иметь, скажем microSD слот для карты памяти прямо на борту.
Uptime пока только 2 суток? Интересно посмотреть на более длительную эксплуатацию.
Вот например мы делаем проект на Carambola 2 и спотыкаемся о неизвестную проблему с USB. USB подглючивает где-то через 5-10 дней. Причем не всегда и не везде. И сиди танцуй с бубном, ищи кто виноват — carambola, хаб, помехи, софт или гороскоп.
Свой репозиторий будет? Или предлагаете чистый OpenWRT? У 8devices свой репозиторий со своими настройками и плюшками. Это плюс. Но софт в нем не весь и не так что бы самый последний. Это минус.
Чем ваш продукт будет лучше Carambola 2? Ценой? Фичами? Надежностью? Поддержкой? Временем жизни продукта?
В последствии к каждой задаче я стал добавлять 10-25% времени на доделки сверху оценки девелопером. Этот запас я не включал в выделенное на задачу время в трекере. Т.е. девелопер его не видел и не рассчитывал на него. Но когда этот запас расходовался (а он почти всегда расходовался) то это не сказывалось на бюджете в плохую сторону.
Разработчику — никакого дела. А вот мне нужно было следить что бы мы не выходили за пределы бюджета.
Проблема в том что наблюдалась тенденция растягивать задачу на все выделенное время и не оставлять время для доделок которые обычно бывают т.к. что-то где-то сделано не так или не красиво или глючит в каком-то из браузеров.
Пример 1. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 8 часов. Этот же разработчик берет ее и через 8 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 9-10 часов.
Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов. Этот же разработчик берет ее и через 6 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 7-8 часов.
Понятно, что не всегда так. Где-то больше, где-то меньше. Но общая статистическая картина была именно такой.
Поэтому разработчику нужно видеть не все время, выделенное на задачу, а только его часть. Тогда он не будет стремиться «растягивать удовольствие» на все выделенное время. Точнее, он будет его растягивать на меньшее время. И по итогу сделает все в срок если не возникнет чего-то экстраординарного. Но для этого есть запас на непредвиденные обстоятельства.
Вижу два варианта.
1. Класть в «пакет с пельменями» кусочек льда в форме логотипа производителя пельменей в отдельном прозрачном пакетике или колбочке. Это даст возможность потребителям контролировать условия хранения. Если растаял — обратно в логотип уже не замерзнет.
2. Можно взять два подпружиненных контакта которые нормально разомкнуты. Сжать их для обеспечения контакта и заморозить в кусочке льда. Пока лед заморожен — контакты замкнуты. Если лед растаял — контакты разошлись и уже сами не сомкнутся. Воду лучше брать дистиллированную. Поместить в стеклянную или пластиковую колбу.
Да, я планирую 2 резинки натянуть. Одна на схлопывание «книжки», вторая — оттягивать шпильку от мотора что бы было стабильное межцентровое расстояние.
Это серия снимков длительностью около часа или полтора. Потом они были склеены в StarTrails. Она отлично фон оставляет.
Вот еще примеры:
2) По наводке на полярную звезду план таков. Выставить телевик с максимальным зумом на нее и сделать несколько снимков с выключенными и потом с включенным трекером на повышенной скорости. Подстроить позицию так что бы вращение было примерно вокруг нее. Когда таким образом откалибрую установку то прикручу искатель от телескопа и настрою его уже на выстроенной системе для дальнейшей более удобной эксплуатации.
Сейчас я не рассчитывают на очень длинные выдержки. Опыта мало. Надеюсь что в течении недели-двух удастся провести полноценные полевые испытания. Все упирается в погоду.
Предел этого двигателя при питании от 5V регулятора ардуины (но не через USB) — 1200-1300 шагов в секунду.
Угол зрения у 70-200/2.8 на 200мм составляет 10.3 градуса по горизонтали. В 5D Mark II по горизонтали 5616 пикселов. Получается что на один пиксел приходится 0.001834045584 градуса.
Радиус шпильки 182.85 мм. Длина окружности 1148.92мм. За 1 минуту гайка совершает 1 оборот и шпилька проходит 0.8 мм. Это примерно 1148.92 / 360 / 0.8 = 0.25 градуса.
Двигатель за минуту совершает 4 оборота. Т.е. его один оборот сдвигает шпильку на 0.06266725885 градуса.
За один оборот двигатель делает примерно 4075 шагов. Т.е. за один шаг двигатель сдвигает шпильку на 0.00001537846843 градуса. Что на два порядка меньше чем каждый пиксел камеры видит на небе. Мне кажется, что это более чем достаточно. Думаю что дрожание всей конструкции будет давать гораздо более значительные искажения чем неточность движения двигателя.
Без трекера в Украине получалось вот так:
В горах Непала было несколько лучше, но это уже предел выдержек до смаза:
Т.е. для тиража конкретно эта реализация не очень удобна как по мне. Для энтузиастов же удобнее дев-борд с модулем на борту и набором разъемов что б точно не нужно было ничего паять. А-ля Ардуино.
И получается что карамбола и китайцы уже предлагают это все за соизмеримые деньги.
Вот чего не хватает на карабмоле так это большого и быстрого хранилища для данных. Приходится городить хаб и вешать флешку. Было бы удобно иметь, скажем microSD слот для карты памяти прямо на борту.
Вот например мы делаем проект на Carambola 2 и спотыкаемся о неизвестную проблему с USB. USB подглючивает где-то через 5-10 дней. Причем не всегда и не везде. И сиди танцуй с бубном, ищи кто виноват — carambola, хаб, помехи, софт или гороскоп.
Свой репозиторий будет? Или предлагаете чистый OpenWRT? У 8devices свой репозиторий со своими настройками и плюшками. Это плюс. Но софт в нем не весь и не так что бы самый последний. Это минус.
Чем ваш продукт будет лучше Carambola 2? Ценой? Фичами? Надежностью? Поддержкой? Временем жизни продукта?
Проблема в том что наблюдалась тенденция растягивать задачу на все выделенное время и не оставлять время для доделок которые обычно бывают т.к. что-то где-то сделано не так или не красиво или глючит в каком-то из браузеров.
Пример 1. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 8 часов. Этот же разработчик берет ее и через 8 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 9-10 часов.
Пример 2. Задача изначально оценена разработчиком в 8 часов.
Заношу ее в трекер и указываю эстимейт 6 часов. Этот же разработчик берет ее и через 6 часов рапортует что она сделана. После проверки оказывается что что-то сделано не так, что-то забыто и вообще в ИЕ глючит. Разработчик уходит переделывать. Через час-два возвращается и показывает теперь уже готовый результат. Итого потрачено 7-8 часов.
Понятно, что не всегда так. Где-то больше, где-то меньше. Но общая статистическая картина была именно такой.
Поэтому разработчику нужно видеть не все время, выделенное на задачу, а только его часть. Тогда он не будет стремиться «растягивать удовольствие» на все выделенное время. Точнее, он будет его растягивать на меньшее время. И по итогу сделает все в срок если не возникнет чего-то экстраординарного. Но для этого есть запас на непредвиденные обстоятельства.
1. Класть в «пакет с пельменями» кусочек льда в форме логотипа производителя пельменей в отдельном прозрачном пакетике или колбочке. Это даст возможность потребителям контролировать условия хранения. Если растаял — обратно в логотип уже не замерзнет.
2. Можно взять два подпружиненных контакта которые нормально разомкнуты. Сжать их для обеспечения контакта и заморозить в кусочке льда. Пока лед заморожен — контакты замкнуты. Если лед растаял — контакты разошлись и уже сами не сомкнутся. Воду лучше брать дистиллированную. Поместить в стеклянную или пластиковую колбу.