НАСА использует готовые Android-смартфоны для своих новых мини-спутников
4
Иллюстрация с сайта NASA
Американское космическое агентство НАСА собирается выпустить серию небольших дешёвых спутников, получивших название PhoneSats. Управлять устройствами будут Android-смартфоны.
Анонсируя этот проект, специалисты НАСА заявили, что для реализации проекта они решили воспользоваться концепцией из мира программного обеспечения с открытым исходным кодом — «выпускай рано, выпускай часто» (release early, release often). Поэтому для создания бюджетных спутников применяются уже существующие на рынке компоненты. Говоря о современных смартфонах, НАСА так пояснила свою позицию: «Они предоставляют множество функций, требующихся спутниковым системам; среди них — быстрые процессоры, универсальные операционные системы, множество небольших датчиков, камеры с высоким разрешением, GPS-датчики и радиоприёмники».
Для первого прототипа — PhoneSat 1.0 — НАСА использовала Android-смартфон Google Nexus One производства HTC, а для второго — PhoneSat 2.0 — Samsung Nexus S, тоже оснащённый мобильной Linux/Java-платформой Android. Прототип PhoneSat 2.0 и послужит основой для будущих мини-спутников, призванных снизить стоимость компактных космических носителей.
Запуск сети из мини-спутников НАСА запланирован на начало 2013 года и станет частью программы Small Spacecraft Technology Program, призванной продемонстрировать возможность проведения гелиофизических измерений с помощью небольших космических летательных аппаратов.
Постоянная ссылка к новости: http://www.nixp.ru/news/11894.html. Дмитрий Шурупов по материалам NASA, Mashable.
Вышла Scrcpy 1.14 — обновление программы для отображения экрана Android-смартфона на ПК
2
Xiaomi выпускает MIUI 9, обещая производительность на уровне обычного Android
Представлен Nokia 2 — Android-смартфон с аккумулятором на 4100 мА·ч за 99 евро
Android-смартфоны Samsung смогут запускать обычные Linux-дистрибутивы с Samsung DeX 1 4
comScore: В США доля Android и iOS растет, RIM и Microsoft — падает 6 14
comScore: Треть рынка смартфонов США — за платформой Android 4 3
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Мусора на орбите станет больше, это печально.
Не надолго. Это будет короткоживущий мусор. Вряд ли они будут зашвыривать смартфоны сильно выше 100км, а там атмосфера их быстренько затормозит, и превратит круговую орбиту в баллистическую кривую с одним концом упирающимся в поверхность земли.
Если учесть, что они будут выведены на расчётную орбиту )))
В смысле? Если они по ошибке не будут заброшены выше? Это как раз вряд ли, чем выше, тем дороже. Топлива каждому смартфону, я уверен, будет даваться в обрез, и если апогей его орбиты и окажется выше запланированного, то в перигее он споткнётся об Эверест.
Чтобы веками болтаться на орбите нужна высота орбиты от пары тысяч километров (а может и выше). Ну а забросить на 100км или на 2000км — разница есть, и существенная.
Согласен )
НЕ ВЗЛЕТИТ, лол. Идея хороша, но не на Android же.
Думаете, в NASA хуже разбираются, что умеет взлетать? ;-)
Ну после того как я попробовал писать под Android, у меня к нему самые теплые чувства — должен гореть в аду. Вот лучше бы MeeGo поддержали :(
Я так подумал-подумал… И пришёл к выводу, что проталкивая идею кустарных спутников NASA на самом деле идёт самым дешёвым путём.При условии что NASA планирует использовать GSM для связи. В тексте новости о способе связи ни слова, но и всё же, предполагая, что в качестве связи будет использоваться GSM, мы не можем не признать, что выбор NASA оправдан на все 100%.
Смотрите сами. GSM согласно en.wikipedia.org/wiki/Comparison_of_mobile_phone_standards работает на расстояниях до 120км _до_базовой_станции_, коих дохрена по миру. Если попытаться на коленке соорудить что-то своё, то во-первых, придётся выбирать из достаточно ограниченного набора частот (мы же не рассматриваем вариант лицензирования world-wide своей собственной полосы частот?), и при этом связь со спутником будет весьма эпизодической, потому что наш приёмник за поверхности Земли будет неподвижным, и связь, соответственно, будет лишь тогда, когда спутник в прямой видимости, а вероятно даже лишь тогда, когда он достаточно высоко, чтобы атмосфера не очень гасила сигнал.
Это я к тому распинался, чем обосновывается выбор GSM. Но если GSM, то значит андройд, поскольку каким бы дерьмом не был андройд, но кроме него нет больше выбора. Ну не Windows Mobile же брать?
Да я полностью согласен про GSM, идея хорошая, но почему не MeeGo???! Ну почему б-гмерзкий Android! Он же даже в подметки не годится ей.
Хотя, с другой стороны — в Android начинается жесть по больше части лишь при работе с UI, в остальном можно полностью пользоваться Java, хотя все равно наверное необходимо будет писать тонны ненужного XML при работе GSM, GPS, в душе не понимаю — ну зачем они так сделали.
А вот MeeGo — это полноценнейший Linux с няшной сишкой / C++, да и вообще чем хочешь на борту, в котором система управляется через rpm или deb.
Потому что NASA брала уже готовые продукты для непосредственного использования. На рынке есть хороший выбор (уже выпущенных) Android-смартфонов со всеми необходимыми им модулями (с встроенными драйверами, протестированные и т.п.). MeeGo — хорошая платформа. И понятно, почему вам нравится. Но конкретно этим (ассортиментом устройств, которые подойдут NASA) похвастать не может.
Но ведь N9! Его еще очень даже продают, во всяком случае в Германии и Франции точно. Или им поддержка производителя нужна, но не будут же они поддерживать запуск телефонов в качестве спутников, нестандартный use case же.
В том и дело, что один только N9 с сомнительными перспективами…Разработают софт, потребуются новые устройства, а с MeeGo их уже нет (и сама платформа не поддерживает). В общем, со стратегической точки зрения их выбор очевиден. А с технологической — не думаю, что Android очень радикально чем-то уступает для их задач.
В принципе — согласен. Но замечу что MeeGo живее всех живых. Есть Jolla, они собираются выпускать аппараты через китайцев (пока что хоть что-то). OS сообщество всячески поддерживает развитие, я поэтому так и радею за нее, ибо планирую этим серьезно заняться, нельзя дать погибнуть такой прекрасной платформе, а Tizen, боюсь, путь в никуда, ибо Bada уже показал что Samsung вполне устраивает Android.
Кто мешает для Android писать на С++? Native SDK -то есть….
В этом Native SDK слово native надо воспринимать как шутку. Для Java платформы, нативным приложением является java-приложение.
Чем Вам не угодили библиотеки написанные на C++? На Java завязан весь ГУЙ не более…
Ну, во-первых, есть у меня вполне определённые сомнения в том, что моё понимание гуя не уже, чем понимание гуя у разработчиков андроида. А во-вторых, программа без гуя, хоть без какого-нибудь долбаного экрана конфигурации, в ОС заточенной на гуй — это не программа. Я вот только что из гугла — сходил освежил в памяти, как там из Java делать ffi вызовы в C++… Это ведь жуть. То что, допустим, что в lisp’е требует лишь глубоко осмысленного кода — объявлений foreign библиотек, объявлений иностранных типов и функций, — то в Java требует невероятных объёмов тупой писанины. То есть, даже если предположить что я написал основную часть программы на C++, используя лишь нативные для C++ библиотеки, то потом я буду вынужден ещё прорываться с боями через JNI. Очень показательна вся эта писанина описана здесь: www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html
И думается мне, что у гугла была какая-то тайная цель, что они такой хлам допустили. Может они тайные враги native-кода? То есть, конечно же, вся эта писанина была изобретена в Sun Microsystems, но ведь гугл даже приблизительно не попытался что-то исправить. Я уж не говорю про компилятор C/C++ хидеров в Java/C++-код и Makefile к нему, чтобы нажатием одной кнопки получить C++ API в Java. Но, хотя бы, что-то можно было сделать?
Да, и напоследок, вы не знаете способа а ля CFFI, для того чтобы использовать C++ классы в… ну допустим в ruby? Или в python’е. Или в racket, haskell, tcl, ocaml, etc, etc, etc. Да хоть в том же lisp’е. По-моему, отсутствие какого бы то ни было стандарта на C++ ABI как препятствовало всегда созданию пристойного FFI к C++, так препятствует и по сей день. То есть, подружить свою программу с .class файликом быть может даже проще чем с «нативным» .so файликом созданным при помощи C++.
Есть проблема: редкий андроид-смартфон может от батарейки работать больше суток :)
Ну, я почти уверен, что этот вопрос решался одним из первых и решение таки нашли.
вы про custom kernel наверное никогда не слышали? мой nexus prime от одной зарядки работает трое с половиной суток, при этом активно его юзаю по 4-5 часов в день, 4G LTE.
ps: и что вы люди все спорите, спорите… я больше чем уверен что в NASA не любители работают, поэтому будьте уверены, и распотрошат и перепишут как надо и андроид, и при желании СВОЙ андроид напишут, если задача того потребует. в статье прямо говорится о планировании использования ЖЕЛЕЗА, но никто не говорил что они хотят тупо и операционку на глюкавой яве оставить как есть. не удивлюсь если они вообще андроид использовать не будут совсем, а напишут все на ассемблере что нужно или адаптируют под это железо свою real-time операционку, которая успешно у них работает годами и на спутниках и на роверах. так что не нужно копья ломать, все у них будет хорошо и без нас ;)
В Финляндии проводят соревнования по метанию мобильных телефонов.
Наверно, NASA таким же способом будет выводить эти спутники на орбиту. :)