Timing of events for a mission - need some advice

0 views
Skip to first unread message

Brian Davis

unread,
Jul 12, 2008, 9:24:23 AM7/12/08
to HALE TEAMS
OK, Gypsy (the camera platform) is 90% done & programmed, and Lil' Joe
(the skydiver payload) is looking good (with the caution that there is
no way to test the 'chute deployment under realistic conditions, i.e.,
thin air and potentially sonic velocity (333 m/s or more than 700
mph). but now, I need to script them...

Gypsy has two script files, one for the way up and one for the way
down. These contain a series of commands (take a series of snapshots,
turn video on, turn video off, and pitch the platform to a specified
angle). I'm looking for suggestions on a good sequence of commands.
Right now I was thinking of several minutes of video right after
activation, to capture the initial ascent... but I'm not sure how long
it will be from pulling off the "remove before flight" trigger to
actual launch. Eric, any estimate? My plan was to pan down after a few
minutes to capture a "look down" before switching to still images
(there would probably be another video segment or two on the way up as
well). Upon cut-down, Gypsy would switch scripts, doing a chaotic
video of the motions right after cut-down for a minute or so, before
switching back to still photos. I'd love to try to get a "terminal"
video of the impact, but that will depend on how well the pressure
sensor works (and if I want to risk the camera - I suspect an impact
while it's operating may kill it).

What percentage of pictures come out acceptable, and why are they
often not acceptable (i.e., how can I maximize the chances by
controlling the payload pitch angle)? I figure during the descent the
pitch angle isn't going to matter as much, with the dynamics of the
payload string.

When would you suggest the best time for video is? How much video vs.
still images would people prefer? The camera has a 2 Gb SD card,
enough for 600 photos (roughly 3.2 Mb/photo) -or- 30 min of video
(about 67 Mb/min of video), or some combination thereof (300 photos +
15 min of video, for example).

Gypsy can tilt +/- 90 degrees. How many shots do we want looking up
(and the payload string above) or looking down (and the payloads
below)? It'll work if I get the center of mass right, and I figure
some back-up video of these pitch angles is good insurance as well.

Lil' Joe is more... interesting. The program will capture 147 seconds
of 3-axis acceleration data at roughly 30 ms intervals. It will
continuously log data, erasing the file after 4 seconds if it's not in
free-fall - that way, it should (at least it has in tests) capture the
actual release point. The time to free-fall is hard-coded however...
so the question then becomes what is the minimum height that Eric's
team will trigger a release, and what's the maximum height of the
terrain underneath? I'm trying to estimate the maximum safe free-fall
interval before Lil' Joe "pulls the chute" (because the whole point
is, well, free-fall :) ). Very roughly, I figured a release height of
*at least* 60k feet, with a hard deck of *no higher than* 14k feet,
gives a maximum distance of 46k feet. At sonic speed (1000 ft/s),
that's just 46 seconds of freefall, which Lil' Joe can completely
capture and still log the 'chute deployment accelerations etc. (to be
safe, it's currently set to 35 seconds from drop to deploy).

So, is 35 seconds "good", as in safe? Any estimates? I'm also
concerned that the string Eric recommended might not be ideal for
absorbing this impact, and may try to find something slightly heavier.
I know weight is everything, but if the string breaks, this will be
the biggest crater generated by an NXT and expensive SPOT

What is the expected minimum altitude of release? And what's the
recommended "hard deck"? I realize assuming sonic speeds during free-
fall is an overestimate (when it gets into the lower atmosphere,
terminal velocity might drop to around 200-300 mph or just 440 ft/s,
half my estimate above). Deployment of the chute might take 4-5
seconds, so I'll try to figure that in.

Lil' Joe hangs below the payload string upside-down, counting on air
friction and a "tail" surface to turn it 180° during free-fall, and
aerodynamic forces to pull the tail fin section away when it is
released. After start-up, it retracts it's own tail fin section,
sealing the payload compartment and then waits for a free-fall event
to start the clock. I suspect I need to figure out a way for Eric &
team to "defuse it" in the event of a non-launch after the payload is
sealed up. And still, getting even a handwarmer in there might be...
really difficult.

Advice? Comments? Snide remarks?

--
Brian Davis

David Levy

unread,
Jul 12, 2008, 11:07:38 AM7/12/08
to hale-...@googlegroups.com
I thought hand earners were deemed ineffective. Should we throw one
in just to be safe?

Sent from my iPhone

David Levy

unread,
Jul 12, 2008, 11:12:01 AM7/12/08
to David Levy, hale-...@googlegroups.com
Hand Warmers that is. It seems even with the iPhone 2.0 upgrade , I'm
still all thumbs. :)

Sent from my iPhone

On Jul 12, 2008, at 11:07 AM, David Levy

Brian Davis

unread,
Jul 12, 2008, 3:31:22 PM7/12/08
to HALE TEAMS
On Jul 12, 11:07 am, David Levy <david.l...@restonrobotics.org> wrote:

> I thought hand [w]ar[m]ers were deemed ineffective.  Should we throw
> one in just to be safe?

If you are using a battery-powered warmer or a battery-powered
thermostated heater, you don't need handwarmers. The problem with Lil'
Joe is the small size and time crunch here at the end. The shell of
this payload will probably be thicker than average (as I'm worried
about aerodynamic forces during a 30+ second free-fall and the shock
of the 'chute deployment), so I'm wondering if I can get away without
warmers at all... but I just bought some little iron-powder-based
ones. They'll dump their heat much faster at low elevation (they'll be
fresher, and they'll have more O2 down there), but inside the
insulated shell they should help. And I *think* I have room for one.

--
Brian Davis

Eric

unread,
Jul 14, 2008, 12:27:09 PM7/14/08
to HALE TEAMS
We are unsure how well hand warmers actually work. We've been wanting
to do a test for a long time. However, we throw them in anyways
because "it can't hurt" and it's better than nothing." I think that
the hand warmer essentially pre-heats all the components, which helps.
Jeff doesn't think it really helps at all.

As for the timing:
Gypsy: on the way down, photos don't look that good unless you have a
very fast shutter speed (we shoot at 1/500th typically). Which reminds
me, over exposure is an issue at altitude because half the photo will
be black (i.e. the ground ends up over exposed). You may want to meter
off of the bottom of the field of view if possible.

Gypsy won't the top-most or bottom-most payload, so looking straight
up and down will see the other payloads. We'll try and leave plenty of
string between the other payloads and Gypsy. A movie during the first
few minutes of launch would be good. A movie of burst would also be
cool - but that has eluded us so far because it's so hard to predict
burst. For most student payloads a photo once every 30 seconds is
fine. However, if you have the ability, take fewer pictures at low
altitude and more towards the top. We often use the NXT to control our
SLR camera. Once every 30 seconds down low and then once every 10
seconds up high (the photos up high look better).

As for Lil' Joe:
If it were me, I would write the program so that it timed the ascent.
That is, measure how much time elapses from launch to release. Then
use this to determine how long the free fall should be. The thing that
worries me is if the balloon doesn't go as high as planned and the
payload craters into the ground. By knowing how long you ascended, you
can reasonably guess how long you can free fall. Pressure works too,
but I would have a time out just in case.

The string - good point. I would use some serious spectra or similar
climbing-rated cord for the chute. I've seen some pretty lightweight
cord at REI. You won't need much of it - just from the payload to the
chute. Don't forget the landing point may be 9,000 feet up (worst case
scenario of landing on top of a mountain). I would deploy relatively
high (15-20k feet) just to be safe. Too bad we won't have any
measurement of actual speed :(

Eric

Brian Davis

unread,
Jul 14, 2008, 1:24:42 PM7/14/08
to HALE TEAMS
On Jul 14, 12:27 pm, Eric <lego.profes...@gmail.com> wrote:

> We are unsure how well hand warmers actually work. We've been wanting
> to do a test for a long time. However, we throw them in anyways
> because "it can't hurt" and it's better than nothing."

Well, by shaving away foam inside I was able to get space for a small
handwarmer right between the NXT and the SPOT. It will be in contact
with the battery compartments of both, so essentially it will be "pre-
heating" the batteries. The handwarmer is supposed to reach 150° F,
but I suspect it will not reach temperatures that high due to
decreasing pO2 and the cold temperatures to begin with.

As to testing them, shoot; that was payload idea #3 :). It would be
very simple, I just need to find proper temperature sensors to
interface with the HT Protoboard that cover the temperatures of
interest. The protoboard should be able to run six. For the next
mission, perhaps.

> Gypsy: on the way down, photos don't look that good unless you have a
> very fast shutter speed (we shoot at 1/500th typically).

The camera will be handling the shutter speed, so I don't have
contyrol over that. I'm going to have access to full auto ("idiot")
mode, and one set mode. For the set mode I was planning on using
landscape, to avoid focus errors.

> over exposure is an issue at altitude because half the photo will
> be black (i.e. the ground ends up over exposed). You may want
> to meter off of the bottom of the field of view if possible.

Since I can tilt the payload as a whole, I'll just use a selection of
pitch angles, biased towards the ground slightly. With all the
wiggling & shaking that may take place, I suspect that may be as good
as anything.

> Gypsy won't the top-most or bottom-most payload, so looking straight
> up and down will see the other payloads.

Good. I'll plan on some of those shots then.

> A movie during the first few minutes of launch would be good.

Check. Two minutes after the "remove before flight" trigger is pulled
sound good?

> A movie of burst would also be cool - but that has eluded us so far
> because it's so hard to predict burst.

Gypsy will detect free-fall, so a movie shortly *after* burst should
be possible. The only way I could think to do it and capture burst is
the way Lil' Joe is going to capture cut-down data: keep taking data
(or video), deleting it and starting over if cutdown hasn't happened.
But I don't have control of that on the camera. Maybe next time, have
the protoboard wired to all the buttons on the camera (I'd have to cut
the camera open, but that would be the next step anyway, saving motors
and weight and gaining still more control). Again, for next time.

> if you have the ability, take fewer pictures at low altitude and more towards
> the top... Once every 30 seconds down low and then once every 10
> seconds up high (the photos up high look better).

Got it. Gypsy will using timing on the way up, so maybe 30 sec
intervals during the first hour, 10 sec intervals during the 2nd hour?
Interspersed with some video and look-up / look-down shots. And plan
on very few shots during descent.

> As for Lil' Joe:
> If it were me, I would write the program so that it timed the ascent.
> That is, measure how much time elapses from launch to release. Then
> use this to determine how long the free fall should be.

What's a good "mapping function"? If the payload determines it was
dropped 1 hour into the mission, then how long should the delay be?
That's going to depend on the ascent rate, as well as the (almost
completely unknown) descent rate for the free-falling payload (worse,
that descent rate is a function of altitude as well, faster in the
thin air, slower in the thick). I thought of this, but it seemed the
unknowns were significantly greater (at least for me). So my thought
was if there is a *minimum* drop altitude that you can trust (is the
payload drop under control of a timer on your "carrier payload", or
under control from the ground?), I would make the assumption of a
minimum safe distance to free fall. I assumed release somewhere above
60k feet, with a hard deck at 20k feet, gives the payload 40k feet to
fall (that's an underestimate; it could be more, but I want to make
sure it's not less). If it falls at 1000 ft/sec (almost certainly an
overestimate, at least at low altitudes), that's 40 sec of potentially
safe free-fall - so I set the free-fall time at 35 seconds.

I'm all ears for better/safer ways - in fact, I'd trust your judgement
if you said "why not make it 20 seconds, to make sure?", and do it on
the spot. But I can't add a pressure sensor at this point (I've only
got the one prototype from Hitechnic, the Vernier ones are *way* to
bulky, and the Mindsensors one I've discovered only reads pressures
above 1 Atm. Rats).

> By knowing how long you ascended, you can reasonably guess
> how long you can free fall.

How about this. If a standard ascent profile is to 100,000 feet in two
hours (that's slower than average I think), then the payload is going
up at more than 14 feet/sec. So if the payload detects being dropped
after 30 minutes, it would calculate an assumed height of 25,200 feet,
subtract off 15,000 for the "hard deck", and assume it has just 10,200
feet to fall, which is at least 10.2 seconds. That seems ultra-
conservative to me... but avoids craters in the desert floor with
bright orange chunks of your SPOT transmitter mixed in.

That I think I can code in the time I've got left (rapidly vanishing).
How does that sound?

> The string - good point. I would use some serious spectra or similar
> climbing-rated cord for the chute. I've seen some pretty lightweight
> cord at REI.

That would be great, but I don't have access to anything like it here
in the flat-as-a-cornfield midwest. The main tether right now is multi-
stranded cord the same as you suggested. If when you get the payload
you have any doubts, please feel free to replace it and the strings
under the payload with whatever you have at hand. I'm simply out of
materials at this end, with no time to order more.

> Too bad we won't have any measurement of actual speed :(

I agree - something I badly wished for, and even have a potential
solution for, but again... not this mission. Using the Eaglecreek
sensor system seems like a good possibility to get uncorrected
airspeed.

--
Brian Davis

David Levy

unread,
Jul 14, 2008, 2:10:55 PM7/14/08
to hale-...@googlegroups.com

My team will be sending out payload component pictures shortly. They are
currently taping the temp sensor to the resistor plate halfway between the two
resistors. They are then sliding the plate underneath the NXT brick and
letting the resistors touch the brick's battery compartment door.

I don't think the resistors will get hot enough to damage the plastic door but
I am wondering if the resisters will be able to supply enough heat to the NXT
batteries with the brick's door in place.

David

On Mon, 14 Jul 2008 10:24:42 -0700 (PDT), Brian Davis wrote

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "HALE TEAMS" group. To post to this group, send email to hale-
> te...@googlegroups.com To unsubscribe from this group, send email to
> hale-teams-...@googlegroups.com For more options, visit this
> group at http://groups.google.com/group/hale-teams?hl=en -~----------
> ~----~----~----~------~----~------~--~---

Dave Parker

unread,
Jul 15, 2008, 3:46:41 AM7/15/08
to HALE TEAMS


On Jul 14, 10:24 am, Brian Davis <brda...@iusb.edu> wrote:
> On Jul 14, 12:27 pm, Eric <lego.profes...@gmail.com> wrote:
>
> > Gypsy: on the way down, photos don't look that good unless you have a
> > very fast shutter speed (we shoot at 1/500th typically).
>
> The camera will be handling the shutter speed, so I don't have
> contyrol over that. I'm going to have access to full auto ("idiot")
> mode, and one set mode. For the set mode I was planning on using
> landscape, to avoid focus errors.

Not sure what kind of camera you are using, but your "landscape" mode
will probably be way too slow of a shutter speed, since this mode on
automatic cameras will typically use the highest f-number it can and
subsequently the slowest acceptable shutter speed for typically
handheld photos (around 1/60 sec), so you will have motion blur. I
agree with Eric that you want 1/500 sec or faster if the camera will
be moving. I would try for 1/1000 myself. A full auto mode will also
likely pick too slow of a shutter speed. If all you have are canned
"scene" modes to choose from, I would choose action/sports (running
guy icon). If you have a shutter priority mode, try for 1/500 or
higher. If using manual settings, note that the way to get a fast
shutter speed while also getting a high f-number (for more forgiving
focus) is to raise the ISO sensitivity. Take test pictures first, of
course, no matter what you choose.

If you are worried about focus, some compact digital cameras allow you
to change the focus to manual and pick a distance (e.g. infinity) if
you go rooting through the menus, and an SLR could be easily locked
into manual at infinity by using manual focus mode and securing the
focus ring (e.g. with tape).

If you want help picking a mode for your specific camera, email me and
let me know what you have.

-- Dave Parker

Eric

unread,
Jul 15, 2008, 6:51:53 PM7/15/08
to HALE TEAMS
When we fly the SLR, we use manual focus (everything is at infinity
from 100,000 feet up).
We also use 200 or 400 ISO just so the shutter speed is faster.

Eric

unread,
Jul 15, 2008, 6:55:26 PM7/15/08
to HALE TEAMS
I think you can count on roughly 1000 feet per minute. We may be off
by +/- 200 at most. To be on safe side, say 800 ft/min multiplied by
the elapsed time would give you an approximation of elevation.

As for string - I will pick up some Spectra cord at REI and tie it
off. We also may use a higher strength drogue chute if we can fit it
in.

Eric

Brian Davis

unread,
Jul 16, 2008, 8:54:58 PM7/16/08
to HALE TEAMS
On Jul 15, 3:46 am, Dave Parker <bl...@nxtprograms.com> wrote:

> "landscape" mode will probably be way too slow of a shutter speed,
> since this mode on automatic cameras will typically use the highest
> f-number it can and subsequently the slowest acceptable shutter
> speed for typically handheld photos (around 1/60 sec), so you will
> have motion blur... If all you have are canned "scene" modes to
> choose from, I would choose action/sports (running guy icon).

That's as close as I can come (the L11 is small, cheap, simple... and
not highly configurable, especially by an NXT high in the atmosphere).
Thank you very much for the suggestion, I'm testing it right now with
the "canned" mode set to "sports"

Running an SLR under complete remote from the NXt is likely possible,
hacking into the camera and using the outputs from the Hitechnic
Protoboard for control... but again, not for this mission. Tonight,
I'm fighting with Gypsy to see if she can get through a complete
simulated mission without a camera error (currently a tough call).
Making a functional LEGO mechanism is easy, compared to making one
that functions at 99% or better. Sigh...

--
Brian Davis

Brian Davis

unread,
Jul 16, 2008, 9:08:43 PM7/16/08
to HALE TEAMS
On Jul 15, 6:55 pm, Eric <lego.profes...@gmail.com> wrote:

> To be on safe side, say 800 ft/min multiplied by
> the elapsed time would give you an approximation
> of elevation.

Actually, that's almost exactly the solution I put into the code. I'm
still *drastically* over-estimating the fall speed as near-sonic, and
the maximum free-fall time I capped at something like 40 seconds (the
world-record free-fall is closer to 14 *minutes* from about 130,000').
I think it's safe, as long as it doesn't tangle or tear free of the
'chute.

> As for string - I will pick up some Spectra cord at REI and tie it
> off. We also may use a higher strength drogue chute if we can fit it
> in.

Thank you. Lil' Joe will be shipped in a "packed" configuration, so in
unpacking it to turn it on you can see exactly how it goes together.
As to fitting a stronger parachute... I suspect stronger isn't needed,
as the cords and stitching on the parachute you sent me are likely
stronger than any way we can attach them to a foam payload shell or
the NXT/SPOT. However, the 'chute you sent me does seem small (it's
noted on it, "1 lb = 1000 ft/sec", while Lil' Joe weighs more than 1
lb). A larger or stronger 'chute would be fine, and Lil' Joe is
designed to expand. The "Tailfin cap" is just pulled up snug against
the main body, and the main body is made from squarish rings of thick
foam. If you add another 2" thick ring, the system should still
function just fine (you may have to glue it in place, or hold it with
some tape - strength isn't critical, as it will be essentially a
spacer). Modify as you see fit.

OK, back to torture-testing Gypsy. That would be me being tortured,
BTW.

--
Brian Davis

Eric

unread,
Jul 18, 2008, 1:21:20 AM7/18/08
to HALE TEAMS
Brian,
The 'chute is small. 1000 ft/min is a "gentle" landing. We've done
much worse...

We have the full range of 'chutes, but I thought smaller would be
better given how fast you will be going - i.e. the less chance the
'chute gets ripped apart at deployment.

Eric

Eric

unread,
Jul 18, 2008, 1:27:59 AM7/18/08
to HALE TEAMS
Brian,
I sympathize with you. There have been several missions where a
payload failed to work properly or malfunctioned 1/2 way through the
mission. That's part of the "educational value" of these types of
projects. Getting it work 2 out 3 times doesn't cut it....

We recently tried to fly a fisheye lens but didn't end up getting any
pictures due to a loose wire on the timer. The NXT worked fine, but in
the end a loose wire got us.

Eric

Davis, Brian L.

unread,
Jul 18, 2008, 8:28:47 AM7/18/08
to hale-...@googlegroups.com
> The 'chute is small. 1000 ft/min is a "gentle" landing... I

> thought smaller would be better given how fast you will
> be going - i.e. the less chance the 'chute gets ripped apart
> at deployment.

Actually, that's an excellent point. Please feel free to check over the system that ties the 'chute into the payload, and revise at will.

--
Brian Davis

Davis, Brian L.

unread,
Jul 18, 2008, 8:30:26 AM7/18/08
to hale-...@googlegroups.com
> There have been several missions where a
> payload failed to work properly or malfunctioned 1/2
> way through the mission. That's part of the "educational
> value" of these types of projects.

Agreed - I'm just unlikely to get another chance at this <grin>. And seriously, I'm trying to do things with as much LEGO as possible and as little "hacking" as possible, so I already made the task harder for myself. I'll see what develops. I just finished up the instructions, and will be shipping today.

--
Brian Davis

Reply all
Reply to author
Forward
0 new messages