OLPC planetarium
From NYU CCPP Wiki
by David W. Hogg (NYU)
The OLPC XO (see also setting up an XO) is the best platform ever devised for electronic support of by-eye astronomical observing. It is a low power device that can be mechanically powered by the user; it has an reflected-light mode in which it does not contribute to local illumination (so the observer can read the display with a red flashlight and it won't compromise dark adaptation), and it is light and rugged.
Planetarium software is, in many ways, the killer app for the OLPC. It provides support for the real-world and zero-cost educational activity of observing the sky at night, but it also provides a fun activity center for students to explore the behavior of the night sky and the stars and planets it contains. Many important educational activities can be built around (or discovered within) a rich planetarium software environment.
Contents |
Tutorial
Download the executable
If you want to alpha-test the code, send email to Hogg. He is willing to give you the alpha version in exchange for a promise to provide constructive feedback.
Requirements will include:
- Linux
- The planetarium should work on most Linux distributions right out of the box.
- Mac OS-X
- You must install X Windows, python2.4, pyGTK, etc.
- If fink is kind to you (which it probably won't be), you can just "sudo fink install pygtk2-py24" and get everything you need.
- if fink isn't kind to you, see "developer notes" below.
- Windows
- There is no supported Windows functionality.
- However, Bryan Winmill wrote me to say "It does work in Windows. No modification is necessary. The person has to do download and install Python, GTK2 Runtime, and PyGTK (with PyCairo and PyGObject)."
Set your clock!
Unfortunately, OLPCs (at least the G1G1 XOs) cannot be relied-upon to have correctly set clocks. This is a travesty against God and Man, but I won't waste your time on that here. In principle you can set your clock once and for all by opening the terminal application and doing something like:
su root sugar-control-panel -s timezone America/New_York /usr/sbin/ntpdate pool.ntp.org /usr/sbin/hwclock --systohc exit
where you might replace "America/New_York" with your proper time zone (lists exist on the web).
Start
Start up the planetarium from the terminal with the command
./nightsky
(assuming you are in the directory where the executable lives. You should see a view towards the North, right now. At the bottom of the view, there will be text saying where you are, what time it is (UTC, not local time), and whether it is day or night (or twilight, which includes the period after sunset and the period before sunrise during which it is not fully dark).
By default you are in New York City, right now, looking North. Buttons on the right of the screen allow you to set your position (longitude and latitude), the time, and the direction you are looking.
Does the view look like the view?
If it is nighttime where you are, and the sky is clear, what you see on the screen should be somehow related to what you see on the sky. If it isn't, then maybe either your computer's clock is wrong, your computer's timezone is set wrong, or your longitude is set wrong in the upper left text boxes. Note that the longitude is defined to be E of N, so, for example, New York City has a negative longitude. If none of these seem to be the problem, email Hogg and please be as specific as possible.
How do the stars move?
Hit the "alt=30" button and then the "N" button. You are looking north. Hit the "+4 min" button repeatedly to see how the sky moves. Repeat for "E", "S", and "W". Do the stars do what you expect?
How does the Sun move relative to the stars?
Hit the "alt=30" button. If your Latitude is positive, hit the "S" button. If your latitude is negative, hit the "N" button. If you are near the equator, or if it is mid-summer, increase your alt so you can see the "zenith" label. Turn on the "star labels" and hit the "+1 h" or "-1 h" buttons until the Sun is in or near the center of the view.
Hit the "+24 h" button repeatedly to see how, each day:
- the Sun is at a different altitude,
- the close planets (Mercury and Venus) move with respect to the Sun, and
- the Sun moves through the constellations.
Now hit the "+23.93 h" button repeatedly. This button advances time by one sidereal day, so the stars stay fixed and the Sun "falls behind".
RA and LST
Hit the "alt=30" button and the "az=N" button. Turn on the "RA,Dec" grid. Vary the time and try to figure out the relationship between the local sidereal time ("LST" in the information string at the bottom of the field) and the RA on the northern point on the horizon. Hit the "S" button and do the same for the southern point.
Change your latitude
Imagine where Polaris would be in the sky if you lived at the North Pole. Now set your latitude to +90 deg N and check. Do the same for the equator (latitude 0 deg N). How does the Sun move in the sky in December when you are at latitude +77 deg N?
Advanced activities
Once you have used the Planetarium and understand it, look under the hood. The code is easy-to-read. Now try hacking. Make the stars bigger (or smaller). Change the point-of-view to Saturn!
Implementation notes
Resource limitations
OLPC software must be small in ram footprint, disk footprint, and CPU demands. The OLPC is not a high performance computing device, and most of the advantages of the OLPC for astronomy depend on the planetarium software operating at very low power levels. Power, ambient light, and resolution considerations make it necessary that all of the planetarium's visuals be black-and-white only.
At this point the single biggest outstanding issue with the code is that it runs too slow on the OLPC beta test hardware (and there is no guarantee that the production hardware will be as fast as the current beta test hardware). Good ideas for improving the speed are welcomed by Hogg.
Transparency and clarity
The OLPC is not just an open-source project; it embodies a strong open-source philosophy, in which children are encouraged and expected to learn in part by modifying the code on their OLPCs. This requires that code be open, but—more importantly—encourages code to be easy to understand and modify by an ambitious, young user. This makes it a priority that the planetarium code be straightforward, modular, and legible. It also must be very well documented.
Most importantly, just as the OLPC "is an education project, not a laptop project" (Negroponte), the planetarium is an educational environment, not a software product. Clarity, transparency, and support for customization and exploration are valued over visual appeal and computational prowess.
Language and translation
Right now the planetarium has no language options, but in accordance with OLPC principles, all messages and labels are built with the the gettext module to deal straightforwardly with multiple languages as translations become available.
The greek letters and constellation abbreviations are IAU conventions, so they are not wrapped in gettext wrappers, nor are the names of SI or IAU units.
Python
The planetarium is written in python and uses the PyGTK library (part of the basic OLPC software) for presenting sky diagrams via the X windows interface. The principal developer (Hogg) is a novice at python programming, so this is a limitation in the short run!
Vectors
All spherical calculations (points on the sphere, angles, projection to the viewing plane or screen, etc.) are performed with simple vector operations; in fact the code includes a simple "Vector" class for performing these operations. This makes the transformations easy to implement, but also effectively advocates vector operations for spherical geometry. Educationally, vector geometry is much more important than spherical geometry. (The Vector class duplicates similar tools in existing python packages, such as numpy and numeric, but most of these python packages are far too large to have installed on every OLPC.)
Catalogs and other data
The star positions (in J2000.0 RA, Dec coordinates) come from The Bright Star Catalog 5th revised edition.
As of yet, the constellations have not been labeled. Relevant references include the Catalogue of Constellation Boundary Data and the the RASC Calgary Constellations page. One option is to label simply the mean of the constellation's stars' positions. The ambitious option is to show all the constellation boundaries (this may be too expensive of resources).
The planet positions are computed using proper ephemerides. The relevant information, including documentation, appears on the JPL Solar System pages. This gives information for the Earth-Moon barycenter (EMB), not the Earth or Moon separately. Of course the EMB is inside the Earth, so for most practical purposes the difference between the observer's position and the EMB is irrelevant. However, ideally the planetarium will in the future track not just the EMB, but the position of the Earth center relative to the EMB, and give the view of the moon (especially) and planets from the Lon,Lat position of the observer, referenced to the Earth center.
As of yet, the Moon's ephemeris has not been included. Unfortunately, there is no accurate yet simple description (like the JPL ephemerides for the Planets) of the Earth-Moon system. This is because physically the Earth-Moon system is astoundingly complex (as it is strongly affected by the Sun's tidal influence).
Projection to the sphere
The internal "model" puts the stars on a unit sphere centered on the observer, and the planets on ellipses in three-space (units of AU). Each planet is projected onto the unit sphere by taking the vector difference between its position and the observer's position (usually on Earth) and re-normalizing to a unit vector. All the nasty spherical trigonometry is thereby replaced with a few simple vector operations.
Projection to the plane
The stars and projected planets "live" on the unit (celestial) sphere; the projection of the sphere to the plane requires decision making. The standard projection is a pure tangent-plane projection that maps the stars from the sphere to a tangent plane that kisses the sphere at a tangent point along straight lines from a projection point (usually at the center of the sphere).
The current default projection in the planetarium is a projection of this type, but projects the stars to the plane not from a projection point at the center of the sphere, but rather from a projection point further from the tangent point, or closer to the far side of the sphere. This keeps the obvious advantages of the tangent plane projection (simple description in terms of vectors) but produces less distortion at the field edges. It has the small disadvantage of making the horizon oddly curved for most useful views.
In the code the projection distance is handled in the ObservingContext by the property ViewDistance. ViewDistance=1.0 is the tangent-plane projection from the center of the sphere, and 2.0 is the projection from the far side. The current default is 1.5.
Developer notes
The planetarium is being developed on mac OS-X and RedHat and Ubuntu Linux. On the Linux distros, python and pyGTK come standard; all the challenge is in the setup of the mac.
Apple developer tools (mac only)
To compile the packages you need, you need the mac developer tools download, though I am not sure. You also need X windows. I have notes on setting up a Mac for development, which includes instructions for both the developer tools and X windows. -- David W. Hogg 21:42, 23 January 2007 (EST)
Install pyGTK (mac only)
On my mac I first added "unstable/main" to the end of the list of "Trees" in the file "/sw/etc/fink.conf". I then did:
sudo fink selfupdate sudo fink install pygtk2-py24
and accepted all defaults. It took a while. At this point, the correct python to use is called "python2.4" not "python". -- David W. Hogg 19:43, 17 January 2007 (EST)
After you have done this, it is sensible to remove "unstable/main" from the Trees in fink.conf unless you have the guts to let unstable packages populate your computer. -- David W. Hogg 11:59, 1 February 2007 (EST)
Get astrometry.net code
Temporarily, and for now, the python code lives in the "nightsky" subdirectory of the astrometry.net codebase. The subversion information is given here, but if you have an account on astrometry.net you can run
svn co svn+ssh://astrometry.net/svn/trunk/nightsky/ nightsky cd nightsky make
to pick up just the planetarium-related files and make the executable "nightsky".
Test that pyGTK is functional
You can tell that everything is working on a Mac OS/X box by typing
python2.4 scribble.py
in the nightsky working directory (this will only work if you have X running), and on a Linux box by typing
./scribble.py
This code "scribble.py" may throw some deprecation warnings, but it should show a canvas on which you can draw, crudely, plus a big "quit" button.
Python version issues (mac only)
If you want scribble and nightsky to execute straight-up on the OS/X box, you will have to make sure the first "python" in your path is a pointer to "python2.4" (or higher). You can find the paths to these executables with
which python which python2.4
I had to
cd /sw/bin sudo ln -s python2.4 python
because I have /sw/bin in my path first. -- David W. Hogg 21:07, 17 January 2007 (EST)
You can tell everything is cool by running the application
make ./nightsky
(where I have assumed you are in the nightsky working directory).
Code structure
The planetarium is written in three versioned (SVN) files:
- code_head.py contains the code header comments and import lines
- bake_catalog.py contains the code to build the python literal from the Bright Star Catalog
- nightsky.py contains the bulk of the planetarium code
Running "make" in the "nightsky" directory builds from these three files the executable "nightsky" which is human-readable and human editable but not versioned (since it is built from the three versioned files). All development should occur on the three versioned files, not the executable directly.
The "bake_catalog.py" code reads and modifies the content of the file "bright_star_catalog_v50" which should not be modified (since it is an unedited download from CDS (see Implementation Notes above).
Outstanding issues
- Need to choose and implement open-source license (GPLv2).
- Moon not implemented.
- Sun and Moon need special shape icons.
- Does not remember any aspects of its state when quit and restarted; in particular it does not remember its location!
- Has no knowledge of any cities or locations on Earth other than NYC. My kingdom for a pull-down menu!
- Observatory position relative to the EMB not implemented.
- Constellations (boundaries or stick figures) not implemented.
- Could stand to be faster.
- Interface does not conform to OLPC guidelines, although I don't entirely agree with those guidelines.
- Interface is overly complex, of course.
- Nothing works in game/reader mode or with game buttons.
- No real-time mode.
- Should the application set the system and hardware clocks (ie, with or without user permission) using the internet, if available?
Acknowledgements
Thanks very much to Keir Mierle (Toronto) for technical assistance, advice, and encouragement, and also to Bryan Berry, Albert Calahan, James Cameron, Piotr Ferus, Hartwell Fong, Dustin Lang, Phillip MacPherson, Adrian Martin, Ed Montgomery, Ben Weiner, Byron Winmill, and the developers on laptop.org for comments, suggestions, and help.
