It's not all Lego! Not good! It uses K'nex pieces as well! It looks like it uses a comp screen to show the views or whatever.
Anonymous said…
i noticed it was K'Nex also. don't know what the point is thouugh,
Anonymous said…
One of the Flickr groups led me to a page for what looks like an astronomy conference (http://www.cacr.caltech.edu/hotwired/). From there, I read through the Agenda to find the presentation by the telescope's creator (http://www.cacr.caltech.edu/hotwired/program/presentations/HTU_threadsafe.pdf). I also had to do a little sleuthing, but it also looks like the presenter is tied to a Virtual Observatory project (http://nvo.noao.edu/).
From what I can tell, it looks like the guy was using an NXT and LabVIEW to prototype how multithreaded autonomous astronomy might work.
Thanks, nxteach. But...what is "multithreaded autonomous astronomy"?
Rick
Anonymous said…
Don't know. I imagine a telescope sitting in some remote location, servicing requests from many users on where to point the thing. Maybe it needs to make decisions about what order to service the requests in, to minimize how much time the scope spends tracking to the next location in the sky? Or maybe the telescope controls itself based on what the observation images look like. It "sees" star A, then some computer software fires off requests to look back at stars B and C to do some sort of comparison. But looking at those stars fire requests for D, E, F...
In other words, I'm way out of my depth here and just making wild guesses. :-)
I'm speaking off-the-cuff here, especially since I can't find the presenter info mentioned...
When you have multiple users wanting to guide a large remote 'scope, planning how to handle the requests can get tricky. For instance, let's say we want to view three stars, one low in the east, one low in the west, and one in the southeast, in a single night. If you execute those observations in that order, there's two problems: (1) you're spending a bunch of possible observational time slewing the telescope all over the sky (it would make more sense to hits targets in order of how close they are to each other), and (2) by the time you've completed observing the eastern (rising) star, the western (setting) star may already be too low to observe. This gets even tougher if you have some observations that really need to be made a certain specific times (transits of exoplanets or moons), and worse yet it has to be dynamicly changed based on weather (if there are clouds on the western horizon, no sense in wasting that observing time on the westernmost target that you can't see anyway while clouds start rolling over your other targets).
I have enough problems setting up manual observing list on some nights, with satellite observations as well as lunar and stellar target, and asteroids. And I have considerably more processing power than my NXT (at least I *think* so...)
One project I've been tossing about since I first started playing with the beta HW is a tracking platform. I've got an 8" Dob I just love, but it would be nice if it could track automatically... which actually shouldn't be too hard at all with the NXT and two motors. The biggest problem is getting them firmly mounted to drive the platform.
'Course, having taken a 2nd look at the conference, it apears it was about transients. This is where a rare brief event is detected, and the detecting device sends out an automated email to the humans, as well as redirected other large telescopes autonomously to observe the event before it goes away. These sort of automated or "robotic" colloborations have been very successful in catching things like the afterglows of GRB's and the rising portion of a supernova lightcurve.
-- Brian "read the WHOLE page, dummy" Davis
Anonymous said…
Hi Guys,
I built the model in question. I'm writing a newsletter article about the conference and stumbled across this blog. To answer some of your questions:
1) I prefer open standards. K'Nex permits larger, lighter structures. They also have parts that mate with LEGOs (classic, not technics, per se). Maybe LEGO should sell parts that mate with competitors?
2) "Multithreaded autonomous astronomy" would be building interoperating networks of telescopes to accomplish observations related to multiple projects using adaptive scheduling - with minimal human guidance.
3) Pretty much all professional telescopes are sited in remote locations, often served poorly by power, transport or communications networks. A lot of the challenge is in building standards robust against extreme challenges. One of the speakers discussed the need for heaters to keep robotic telescopes operating in Antarctica. His heater might be described by others as a "flamethrower".
4) It is indeed all about scheduling for multiple users, multiple projects as the Earth moves underneath us, the weather changes, etc. But this describes regular astronomy, not just autonomous astronomy. To those challenges, add adaptively scheduling out of a queue filled by numerous investigators, add a market-driven paradigm for trading time on one telescope for time on another (typically with very different cameras), add rapidly varying or moving celestial objects - in particular, add the capabilities of fully untended, robotic telescopes. (Big telescopes are quite fragile and finicky and rife with strange legacy requirements.)
5) Celestial transients are anything but rare. A supernova in a galaxy observable from Earth occurs about once a second. (The hard part is knowing what direction to look - although neutrino telescopes can in principle predict a supernova before the flash of light arrives.) There are hundreds of thousands of known asteroids. A large fraction of the stars you see when you look up are variables of one sort or another. They've gotten so good observing the sun with techniques similar to seismology that they can "see" sunspots on the far side of the sun.
6) Several large telescopes are being built to constantly survey the sky for such transient events. Hundreds of small robotic telescopes will soon be deployed that can productively follow up on these discoveries. The missing parts are what the conference was about - the standards for describing the celestial events so decisions can be made about what to observe next - and the standards for commanding multiple robotic facilities to do what you want once you figure out what that is.
7) ...and we're down to the NXT telescope. I need not belabor the fun factor. The NXT processor is, however, easily powerful enough to pilot a telescope. I really can't consider the brick a toy. LabVIEW is also a professional package that we use to drive several of our instruments, for instance. I got the excellent new Java NXT book the day before the workshop started. I'll be doing future development using Java. The model shown is a functioning altitude-azimuth mount. Making actual optics wasn't really the point. As discussed above, the point is to have networks of telescopes operate with a common purpose. I plan to get at least one more NXT, preferably four or more, so they can work together via bluetooth.
The difficult part is really to figure out how to communicate with the target audience of humans at astronomical conferences the issues we're focusing on - making the NXTs play well together seems very straightforward.
I do need to rebuild the gear boxes a little better and I would like to assemble another telescope purely out of technics parts - but the resulting model will likely turn out quite a bit smaller.
For those who want to explore more, the conference website is http://www.cacr.caltech.edu/hotwired. And yes, the VOEvent standard derives from a Virtual Observatory project.
Hi guys, I just ordered my NXT kit speificaly because I want to try to roboticize my telescope (4.5" Newtonian on a eqitorial mount) . Then I found this thread.
Rob: Can you post or provide a link to the softwhere? LabVIEW or Java or whatever you can.
My kit should arive monday, If I can make this work I'll get a big dobsinian and add motors to that.
Comments
Jim
From what I can tell, it looks like the guy was using an NXT and LabVIEW to prototype how multithreaded autonomous astronomy might work.
Rick
In other words, I'm way out of my depth here and just making wild guesses. :-)
When you have multiple users wanting to guide a large remote 'scope, planning how to handle the requests can get tricky. For instance, let's say we want to view three stars, one low in the east, one low in the west, and one in the southeast, in a single night. If you execute those observations in that order, there's two problems: (1) you're spending a bunch of possible observational time slewing the telescope all over the sky (it would make more sense to hits targets in order of how close they are to each other), and (2) by the time you've completed observing the eastern (rising) star, the western (setting) star may already be too low to observe. This gets even tougher if you have some observations that really need to be made a certain specific times (transits of exoplanets or moons), and worse yet it has to be dynamicly changed based on weather (if there are clouds on the western horizon, no sense in wasting that observing time on the westernmost target that you can't see anyway while clouds start rolling over your other targets).
I have enough problems setting up manual observing list on some nights, with satellite observations as well as lunar and stellar target, and asteroids. And I have considerably more processing power than my NXT (at least I *think* so...)
One project I've been tossing about since I first started playing with the beta HW is a tracking platform. I've got an 8" Dob I just love, but it would be nice if it could track automatically... which actually shouldn't be too hard at all with the NXT and two motors. The biggest problem is getting them firmly mounted to drive the platform.
--
Brian "yes I do amatuer astronomy too" Davis
--
Brian "read the WHOLE page, dummy" Davis
I built the model in question. I'm writing a newsletter article about the conference and stumbled across this blog. To answer some of your questions:
1) I prefer open standards. K'Nex permits larger, lighter structures. They also have parts that mate with LEGOs (classic, not technics, per se). Maybe LEGO should sell parts that mate with competitors?
2) "Multithreaded autonomous astronomy" would be building interoperating networks of telescopes to accomplish observations related to multiple projects using adaptive scheduling - with minimal human guidance.
3) Pretty much all professional telescopes are sited in remote locations, often served poorly by power, transport or communications networks. A lot of the challenge is in building standards robust against extreme challenges. One of the speakers discussed the need for heaters to keep robotic telescopes operating in Antarctica. His heater might be described by others as a "flamethrower".
4) It is indeed all about scheduling for multiple users, multiple projects as the Earth moves underneath us, the weather changes, etc. But this describes regular astronomy, not just autonomous astronomy. To those challenges, add adaptively scheduling out of a queue filled by numerous investigators, add a market-driven paradigm for trading time on one telescope for time on another (typically with very different cameras), add rapidly varying or moving celestial objects - in particular, add the capabilities of fully untended, robotic telescopes. (Big telescopes are quite fragile and finicky and rife with strange legacy requirements.)
5) Celestial transients are anything but rare. A supernova in a galaxy observable from Earth occurs about once a second. (The hard part is knowing what direction to look - although neutrino telescopes can in principle predict a supernova before the flash of light arrives.) There are hundreds of thousands of known asteroids. A large fraction of the stars you see when you look up are variables of one sort or another. They've gotten so good observing the sun with techniques similar to seismology that they can "see" sunspots on the far side of the sun.
6) Several large telescopes are being built to constantly survey the sky for such transient events. Hundreds of small robotic telescopes will soon be deployed that can productively follow up on these discoveries. The missing parts are what the conference was about - the standards for describing the celestial events so decisions can be made about what to observe next - and the standards for commanding multiple robotic facilities to do what you want once you figure out what that is.
7) ...and we're down to the NXT telescope. I need not belabor the fun factor. The NXT processor is, however, easily powerful enough to pilot a telescope. I really can't consider the brick a toy. LabVIEW is also a professional package that we use to drive several of our instruments, for instance. I got the excellent new Java NXT book the day before the workshop started. I'll be doing future development using Java. The model shown is a functioning altitude-azimuth mount. Making actual optics wasn't really the point. As discussed above, the point is to have networks of telescopes operate with a common purpose. I plan to get at least one more NXT, preferably four or more, so they can work together via bluetooth.
The difficult part is really to figure out how to communicate with the target audience of humans at astronomical conferences the issues we're focusing on - making the NXTs play well together seems very straightforward.
I do need to rebuild the gear boxes a little better and I would like to assemble another telescope purely out of technics parts - but the resulting model will likely turn out quite a bit smaller.
For those who want to explore more, the conference website is http://www.cacr.caltech.edu/hotwired. And yes, the VOEvent standard derives from a Virtual Observatory project.
Rob: Can you post or provide a link to the softwhere? LabVIEW or Java or whatever you can.
My kit should arive monday, If I can make this work I'll get a big dobsinian and add motors to that.