ArduSat-PL - ogólne rozmowy

[skrzyp]

Sama implementacja to akurat najmniejszy problem, gorzej z wymysleniem wszystkich przypadkow jakie ma program obsluzyc i wszystkich "wpadek";-) Z powazaniem

No znów nie dramatyzujmy. Co my tu mamy:

1) logowanie danych odnośnie położenia, orientacji, stanów satelity itp. do późniejszej obróbki na Ziemi i wyciągnięciu informacji na temat działania satelity (pomysł Pawła), 2) wykonanie serii fotek Ziemi/horyzontu Ziemi do ewentualnego złożenia w filmik i/lub dalszej obróbki oraz 3) sesja łączności lub raczej odebrania sygnału od ArduSata (bip bip bip przynajmniej), gdy satelita będzie nad Polską.

1) - zapis wszystkiego na SD i 10x wysłanie radiem coby na pewno doszło
2) - zapis zdjatek na SD i 10x wysłanie radiem coby na pewno doszło
3) - pipanie tu bym dorzucił pomysł aby poza "hello kitty" dodać wysyłanie pozycji GPS

Zakładając, że dostaniemy gotowe procedury dostępu do sprzętu to w każdym przypadku mamy max kilkadziesiąt linijek kodu - sprawdzać zegar i co wyznaczony czas dokonywać pomiarów i zapisywać.
Jedyne czym się w tej sytuacji możemy wykazać to algorytm kompresji danych podczas wysyłania. Jakby co to służę tym który zaimplementowałem w Heveliusu - do danych GPS jakies 40% kompresji. Z jpeg wiele nie wywalczymy, więc myślę, że nawet nie ma się co za nią brać.

Zakładając, że dostajemy bezpośredni dostęp do sprzętu (zero gotowych procedur) to mamy kilka tyś. linijek kodu.


Na mój rozum, ja bym nikomu nie dawał bezpośredniego dostępu do sprzętu, bo NIKT nie sprawdzi działania kilku tyś linijek kodu w krótkim czasie, a droga do uwalenia satelity przez amatorów jest bardzo krótka w takiej sytuacji. Wystarczy jeden mały błąd, żeby zwiesić procka i pogadane.

Jest różnica miedzy kilkudziesięcioma i kilku tysiącami linijek kodu i głównie próbował bym się dowiedzieć od nich jak to w końcu będzie z tym programowaniem. Bo to że nakręcili filmik jak odczytać ciśnienie w sytuacji gdy ciśnienie będzie dużo poniżej mierzalnego zakrawa na ironię albo mydlenie nam oczu.

[Adam.Przybyla]

Sama implementacja to akurat najmniejszy problem, gorzej z wymysleniem wszystkich przypadkow jakie ma program obsluzyc i wszystkich "wpadek";-) Z powazaniem

No znów nie dramatyzujmy. Co my tu mamy:

1) logowanie danych odnośnie położenia, orientacji, stanów satelity itp. do późniejszej obróbki na Ziemi i wyciągnięciu informacji na temat działania satelity (pomysł Pawła), 2) wykonanie serii fotek Ziemi/horyzontu Ziemi do ewentualnego złożenia w filmik i/lub dalszej obróbki oraz 3) sesja łączności lub raczej odebrania sygnału od ArduSata (bip bip bip przynajmniej), gdy satelita będzie nad Polską.

Dzieki ze zaczales ten watek, mozemy powoli konkretyzowac to co bedzie nam potrzebne, na tym etapie wiedza programistyczna nie jest potrzebna, starczy
tylko odrobina logiki - czyli kazdy moze pomoc;-)

1) - zapis wszystkiego na SD i 10x wysłanie radiem coby na pewno doszło
...
2) - zapis zdjatek na SD i 10x wysłanie radiem coby na pewno doszło
3) - pipanie tu bym dorzucił pomysł aby poza "hello kitty" dodać wysyłanie pozycji GPS

Zakładając, że dostaniemy gotowe procedury dostępu do sprzętu to w każdym przypadku mamy max kilkadziesiąt linijek kodu - sprawdzać zegar i co wyznaczony czas dokonywać pomiarów i zapisywać.
Jedyne czym się w tej sytuacji możemy wykazać to algorytm kompresji danych podczas wysyłania. Jakby co to służę tym który zaimplementowałem w Heveliusu - do danych GPS jakies 40% kompresji. Z jpeg wiele nie wywalczymy, więc myślę, że nawet nie ma się co za nią brać.

Zakładając, że dostajemy bezpośredni dostęp do sprzętu (zero gotowych procedur) to mamy kilka tyś. linijek kodu.


Na mój rozum, ja bym nikomu nie dawał bezpośredniego dostępu do sprzętu, bo NIKT nie sprawdzi działania kilku tyś linijek kodu w krótkim czasie, a droga do uwalenia satelity przez amatorów jest bardzo krótka w takiej sytuacji. Wystarczy jeden mały błąd, żeby zwiesić procka i pogadane.

Jest różnica miedzy kilkudziesięcioma i kilku tysiącami linijek kodu i głównie próbował bym się dowiedzieć od nich jak to w końcu będzie z tym programowaniem. Bo to że nakręcili filmik jak odczytać ciśnienie w sytuacji gdy ciśnienie będzie dużo poniżej mierzalnego zakrawa na ironię albo mydlenie nam oczu.

Program musi wiedziec kiedy zaczac, ktora to iteracja i kiedy skonczyc. Musi tez wiedziec co zrobic w przypadku sytuacji niepewnej - bledu magistrali,
bledu transakcji, bledu zapisu (to apropos pawlowego eksperyentu). Zastanawiam sie nad mozliwoscia obslugi bledu aplikacji, ale to dopiero jak to uda mi sie
zaimplementowac.

BTW, procka sie nie uwali i nie zawiesi, ma byc kilka arduino uno i jedno arduino mega aby rzadzic nimi wszystkimi;-))) Zawiesisz najwyzej swojego arduino uno.
Z powazaniem
                                                      Adam Przybyla

[skrzyp]

Program musi wiedziec kiedy zaczac, ktora to iteracja i kiedy skonczyc.

No to akurat nie problem chyba, majac jakikolwiek zegarek/gps (który jakby nie było podaje czas).

Musi tez wiedziec co zrobic w przypadku sytuacji niepewnej - bledu magistrali, bledu transakcji, bledu zapisu

No i tu znów wracamy do braku info ze strony ardusowców, jak będziemy programować.
Jeśli oni dostarczą procedury dostępu do sprzętu, to nas obchodzi tylko info czy taki błąd wystąpił i co z tym fantem zrobić. Jeśli nie, wracamy do tysięcy linijek kodu i analizy każdego odebranego lub nie bitu.

BTW, procka sie nie uwali i nie zawiesi, ma byc kilka arduino uno i jedno arduino mega aby rzadzic nimi wszystkimi;-))) Zawiesisz najwyzej swojego arduino uno.

Jesteś pewien że jedno ardu będzie potrafiło zaprogramować drugie? Bo ja nie, ale oby tak było.

[Adam.Przybyla]

Program musi wiedziec kiedy zaczac, ktora to iteracja i kiedy skonczyc.

No to akurat nie problem chyba, majac jakikolwiek zegarek/gps (który jakby nie było podaje czas).

   ... ale trzeba podjc decyzje co do sposobu, nie podaje teraz
problemow, ale wymieniam rzeczy ktore musza byc w programie wyszczegolnione.

Musi tez wiedziec co zrobic w przypadku sytuacji niepewnej - bledu magistrali, bledu transakcji, bledu zapisu

No i tu znów wracamy do braku info ze strony ardusowców, jak będziemy programować.
Jeśli oni dostarczą procedury dostępu do sprzętu, to nas obchodzi tylko info czy taki błąd wystąpił i co z tym fantem zrobić. Jeśli nie, wracamy do tysięcy linijek kodu i analizy każdego odebranego lub nie bitu.

   ... tu nalezy sie zastanowic jaka biblioteke uzyc, standardowa "Wire" czy moze ktoras z poprawionych.

BTW, procka sie nie uwali i nie zawiesi, ma byc kilka arduino uno i jedno arduino mega aby rzadzic nimi wszystkimi;-))) Zawiesisz najwyzej swojego arduino uno.

Jesteś pewien że jedno ardu będzie potrafiło zaprogramować drugie? Bo ja nie, ale oby tak było.

            ... tak: http://arduino.cc/en/Tutorial/ArduinoISP Z powazaniem
                                                                                                                                         Adam Przybyla

[kanarkusmaximus]

Przypominam wszystkim o ankiecie odnośnie sesji IRC. Jak na razie otrzymaliśmy sześć odpowiedzi. Proszę o kolejne.

[Adam.Przybyla]

Przypominam wszystkim o ankiecie odnośnie sesji IRC. Jak na razie otrzymaliśmy sześć odpowiedzi. Proszę o kolejne.

             ... jak cos testowac bramke mozna juz teraz. Jak akuurat bede na irc to odpowiem. Ale oficjalne spotkanie bedzie wg daty z ankiety. Z powazaniem
                                                                                                                                                                            Adam Przybyla

[Adam.Przybyla]

ArduSat Prototyping Module http://www.freetronics.com/products/ardusat-prototyping-module#.UTNLGdd73qg

Build a custom CubeSat satellite module by combining your own parts and sensors with the ArduSat Prototyping Module. Excellent for non-satellite projects too!

This module is primarily designed for prototyping experimental hardware on the ground and for testing on HAB (high altitude balloon) and sounding-rocket flights. Perfect if you're planning to have an experiment performed on an ArduSat mission and you want to assemble hardware locally for testing.

Z powazaniem
                                                                                                                                Adam Przybyla

[kanarkusmaximus]

To chyba nie wygląda na zbyt wyszukaną technologię. I jeszcze jest "ciężkie"... Do takiego prototypowania to chyba jednak zwykła płytka wystarczy...

[skrzyp]

Ano zwykła płytka uniwersalna do "drutowania" układu. Przy takiej jej wielkości to już lepiej zwykły pająk z glutem (cieplym klejem) jest lepszy.
I nie kosztuje nienormalnie wysokiej ceny 50$ - toż to rozbój w biały dzień.

[Adam.Przybyla]

Ano zwykła płytka uniwersalna do "drutowania" układu. Przy takiej jej wielkości to już lepiej zwykły pająk z glutem (cieplym klejem) jest lepszy.
I nie kosztuje nienormalnie wysokiej ceny 50$ - toż to rozbój w biały dzień.

             ... no wlasnie sie zastanawiam co zacz;-) BTW, moje stanowisko do testow wyglada aktualnie tak i chyba bylo tansze w calosci niz ta jedna plytka;-) :

Z powzaniem
                                                                                                                                        Adam Przybyla

[Szaniu]

Wybaczcie, że dopiero teraz zagłosowałem w sprawie sesji! Małe problemy z grafikiem ;P.

[CoB]

A Szmymon to ja I przepraszam, że też dopiero dzisiaj uzupełniłem ankietę - dużo zawirowań na uczelni i zupełnie z głowy mi wyleciał ARDUSAT

[kanarkusmaximus]

Dzięki za głosy! Dobrze, że byłem w rozjazdach i dopiero teraz mogłem zamknąć ankietę.

W załączniku wyniki ankiety - wygrała niedziela 17 marca o 19:00 i tego dnia zrobimy sesję na IRC.
Ponieważ jednak Skrzyp nie może tego dnia się pojawić, to proponuję dodatkową sesję 15 marca (piątek) o 20:00. Przyda się dla opinii.

Zatem dwa terminy:
- (dodatkowy, rozgrzewkowy) - 15 marca, piątek, o 20:00
- główny - 17 marca, niedziela, o 19:00

[kanarkusmaximus]

Najnowsze wieści od Arduinców:
-----------
Sensors

We are excited to announce that the final sensors have been selected for ArduSat!

After our high altitude balloon tests and a lot of work our team has completed the selection of the instruments that will be used on our first satellite. We want to show you exactly what will be flying on the satellite you are make possible!

Freescale's MAG3110, small and low powered this digital 3-axis magnetometer will allow the satellite to measure the earth's magnetic field. We put together some introductory informational videos for you at these are the MAG3110 series of videos. The data sheet is available from http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Magneto/MAG3110.pdf

InvenSense's ITG-3200, this compact 3-axis digital gyro will sense the satellites movements. It is a robust instrument that is also small and sensitive. The datasheet is available at http://www.sparkfun.com/datasheets/Sensors/Gyro/PS-ITG-3200-00-01.4.pdf. 

Analog Devices's ADXL345 is a small, low power 3-axis accelerometer. Highly sensitive the accelerometer will be used to track the acceleration of the satellite. The full details about the sensor can be found here: http://www.sparkfun.com/datasheets/Sensors/Accelerometer/ADXL345.pdf. Next is the

Melexis's MLX90614 infrared temperature sensor which has a wide sensing range. The sensors can be used to measure the emissivity of the earth for more information on potential uses of the sensor please see the incormational video series MLX90614 on NanoSat_University. The full details about the sensor can be found here http://www.sparkfun.com/datasheets/Sensors/Temperature/SEN-09570-datasheet-3901090614M005.pdf.

Texas Instrument's TMO102 is a low power digital temperature sensor. Several of these will be used to track the internal and external temperature of the satellite. The full details about the sensor can be found here: http://www.sparkfun.com/datasheets/Sensors/Temperature/tmp102.pdf.

LND, Inc.'s LND 716 Geiger counters will be used to monitor the radiation environment of the satellite. With a large range these small sensors will provide valuable data. For their specifications please see the manufactures information sheet here: http://www.lndinc.com/products/pdf/306/. Additionally, we will publish more videos on how to use this sensor soon, especially as we upgraded your sensor-suite to include two(!) geiger-tubes in orthogonal configuration for more interesting experiments.

Adafruit Industries's TSL2561 luminosity sensor covers both infrared and visible light. These sensors will be placed beside the camera and the spectrometer to help you use those powerful and more complex sensors. For the full sensor details please see the data sheet here: http://www.adafruit.com/datasheets/TSL2561.pdf

MySpectral's Spectruino is our optical spectrometer specifically designed to work with Arduino. The details of the sensor are available at MySpectral's website http://myspectral.com/ and we will provide instructional videos around how to best use this sensor soon.

And then there is our camera, which was upgraded to a 1.3 MP camera so you will be able to shoot pictures from earth with 4x the resolution from the camera we had originally planned for you!

As you know, we have developed some initial educational videos for the sensors. We also have some videos that explain a little bit more about the basic principles of how the data is handled on board the satellite.

These are set up at www.screencast/users/Nanosat_University/. In the first set of files BMP085, Lara will walk you through the basic principles of the 12C bus using BMP085 as an example. The Datalogger series will walk through several of the principle involved in using Arduino for ArduSat. In MCP3424 Lara will go over the basics of how the analog to digital converter works. The remaining two series are for two of our sensors. Please use those videos and tell us what you like, dislike and what else you would like to see.

 Over the coming days and weeks we will continue to put up more instructional videos and more capabilities to help you develop your code. We want to make it as simple and easy as possible and are working on some exciting developments for you. Stay tuned!

Last but not least, we’d also like to let you know that in case you do not get ready for your experiment for the July launch, we will give you all your time on the September launch to run it there. And if that is still not quite working out for you and in case (which we really hope) we launch further ArduSats in 2014, you will still be able to get your time to run your experiment there, free of charge. We promise to do whatever we can to get you and your amazing ideas into space!

[kanarkusmaximus]

Dostałem dziś ważnego maila od kontaktu od ArduSat.  300 kb na tydzień operacji! Oznacza to, że proponowany przeze mnie eksperyment z serią fotek na orbicie jest praktycznie niemożliwy do zrealizowania.

Proszą o przesłanie kodu "tak szybko jak to możliwe", choć wcale nie wiemy co możemy obecnie zrobić.

------------
1. When can we start sending our codes to you for review and comments?

You can start sending code to us immediately - we're still working out a dedicated point of contact for all Kickstarter developers, but for now you can send it to me. We're in the process of creating a better interface for developers to interact with us as we develop shared libraries and other things for the satellite. Do you have code already prepared?

2. Recently you started putting some samples online, but probably much more should be published very soon, otherwise probably noone would be ready to put their experiment in July.

We agree completely!

3. Will there be any 'booking' form for the ArduSat? Would it be possible to select time of our week/10 days on ArduSat?

That's another system we're currently developing, the scheduling process for backers. For the first satellite, you'll select your week, and the extra 3 days will be awarded on the second satellite (assuming both work). In both cases, you'll be able to sign up for your desired week ahead of time.

4. What are the downlink capabilities? We would like to conduct several experiments, but we don't know when there will be a download of data from ArduSat and how much could it be (realistically).

The total data capacity will be determined by the number of ground stations in our network by launch date; we're targeting up to 300kb of total data per experiment per week. If you're planning on taking pictures, that would go on top of the 300kb. The 300kb is not a firm number yet, I'm just trying to be cautious and not over-promise.

5. Any details about orbit details? I understand that it will be the same inital orbit as ISS, but the station quite often corrects its orbit and the moment of deployment is not known. It is quite important to us, as we would like to conduct a 'beep beep beep' experiment for our radioamateurs, so timing is important here, so they would know when to listen to ArduSat.

You're correct, the station frequently corrects its orbit to perform maintenance and to avoid debris. Unfortunately, that means we won't know right until deployment what our exact orbital parameters will be (since we're not in control of the deployment time, the astronauts/NASA is). However, as soon as it is deployed, we will be able to publish the exact orbital parameters and maintain them on our website, so radio amateurs will be able to predict the next flight overhead and listen for the beacon.

For reference, the ISS orbit parameters are roughly 380-410km altitude, circular orbit, at a 51.6 degree inclination. 
---------------

Na grubo zaznaczyłem moje pytania do ArduSatowców.