Nuke

it played last month at our one screen, one movie a week theater. i didnt think we would get it at all.

this is probibly because of boiloff. you need the hoses to constantly top off the tank. at some point in the countdown the valves are closed and the tanks sealed. i think they leave the hoses attached in case there is a hold up and they need to top off the tanks some more.

also you have proton-boron11 fusion as an alternative, and the earth is fairly rich in boron. save the helium 3 for space side reactors, such as those needed for a lunar colony.

g loads dont only affect the occupants but also structural tolerances as well. a capsule might be able to handle a 5g re-entry just fine, and most stuff launched into space can usually survive up to 3g which is the standard for most payloads. a modular craft assembled in space however might have issues with such high g loads. the iss would probibly break if it had to handle even a fraction of a g (if you hypothetically wanted to perform an aerocapture with it, which you would never do irl). you would never want to exceed your craft's design tolerances. if you had a multi mission space craft that was manned and had a large nerva cluster and tankage or perhaps an orion drive, an aerocapture just might be out of the question at some places.

i am aware of this. but im familiar with the maneuver and use it whenever possible to save fuel. this is why im tempted to fire up orbiter and see what kind of g loads i end up with (though im too lazy to actually do this).

aerocapture is really just aggressive aerobraking. in ksp i usually go for a highly eccentric near-escape orbit, the bare minimum of what would constitute an aerocapture maneuver. i follow up on this by using slower and more controlled aerobraking passes to reel in the apoapsis to where i want it. on some planets the g load is very small, oddly jool usually offers a more gentle breaking than does laythe, where the gs are usually in the red. once in a blue moon (i see what i did there) i can hit both jool and laythe with only minor corrections, pick up a partial deceleration job at jool, and finish at laythe without redlining the g meter. but this is a rare occurrence in a real solar system. one of these days i might load up orbiter and see what some more realistic aerocapture maneuvers look like. hitting terrain is something you can figure out ahead of time and plan a mission around (for example timing the approach so that periapsis doesn't intersect olympus mons), but g loads can break things and kill astronauts. so you might do partial powered deceleration where the orbit remains solar, but results in less orbital energy needing to be dissipated during the aerocapture phase. this might bring the margins to manned safe levels.

found something cool: https://www.youtube.com/watch?v=0u7CWB40ezMx r/c aircraft attempting takeoffs and landings on an advengers inspired r/c helicarrier. for science!

jsut dont put your negative apples in the same fruit basket as positive oranges. that could make a mess.

my experience with aerocapture at duna from an interplanetary trajectory usually involves getting dangerously close to the surface and pulling a lot of gs. not to say aerocapture at mars wouldn't be possible, but it might push the danger margins far beyond what is considered acceptable for a manned mission.

i started blocking ads when they started making noise and running fancy graphics, animations, and blocking the content you were trying to look at. it got to the point where the ad was bigger (in both file size and appearance) than the page you were looking at, you look at your internet bill and wondered where your transfer quota was going. ads used to be these small little gif files of a few k, but when they started pushing annoying 5mb ads and costing people money they blew it. then they started poking holes in your security. its actually a shame because a lot of smaller web communities are supported entirely by ads and donations. a few obnoxious ads ruined it for everyone.

i like some of these newer rtg-on-a-chip solutions they are coming out with. just solder it to a pcb like it was any other component. very low power though, enough to periodically wake up a microcontroller for a few fractions of a second at a time to do some task, and then put it back to sleep before the buffering caps loose their charge. and enough to keep low power srams from loosing data. could power a chip sat while in standby.

alpha and beta voltaic are taking over these applications.

night is the perfect condition for optical based target tracking. it gets rid of most of the noise that would need to be processed out before doing blob detection. use wavelength matched filters and lights can be effective. uv light can penetrate clouds and fog sufficiently to find the pad in the final phase of landing. in daylight, chances are other than the sun the rocket plume would be the brightest spot in the sky, especially on infra red. just cause you cant see it doesnt mean computer vision systems cant. but i admit that if you cant control the thing then all this tracking gear would be for nothing. dont you also need hydraulic power for the gimbal systems as well? seems for the final phase the gimbals would take over from the drag fins since there would not be sufficient airflow over them to be of use.

looks like it missed the center. i think you need more precise tracking for the final part of the landing, something video based. for example have tracking cameras on the barge set up to track the rocket's motor plume, calculate local position and transmit course corrections up to the rocket. it makes me wonder if you cant correct for wave motion in software. have some accelerometers on the barge keeping track of wave motion. transmit that data up to the landing rocket. final touchdown would then begin at the top of the wave and complete at the bottom of the wave. that way you never have to worry about the waves slamming the barge into the rocket.

yea there are other ways to have a stable landing platform at sea. oil platforms are capable of this. there is also that flip research boat that is supposedly extremely stable (though not large enough to land a rocket on its tail end). even a catamaran vessel would work well here, we have a few catamaran ferries here that are rock solid even in rough seas. a barge is probibly the worst thing you can use for this. but finding an old decommissioned oil platform and retrofitting it with a landing pad, might be both cheap and effective.

you dont need as much fuel for the return trip, especially if you use aerocapture (mars <-> earth run for example can aerocaptue at both places). so low isp fuel works there. i also imagine doing a moon <-> mars run with isru fuel produced at both ends being a thing. the nuclear reactor would be usable for many trips before it needed to have its core refueled. i also have the feeling we wont routinely run nuclear ships (for obvious political reasons) till we have an off world source of the nuclear fuel somewhere.

it would have gotten thrown out otherwise. its kind of a convenient way to test the landing system, you still get your payload to orbit, then you get to have a little fun with the stage.

it would be more versatile to have an engine that can switch propellants during the mission. hydrogen gives you the best isp, but if you cant find it for some reason, you can still put something in the tank and get some deltav out of it. of course this really only matters if you have isru capability. if its a one shot mission with no refueling just tank up with hydrogen.

war is nasty. a good fighter pilot is a wolf. you pick out the weak (in terms of position, available support, etc) for your targets and take them out first. its a lot like any animal planet special on any predatory species where they kill stragglers, the old, the injured, the babys. its just the mind set you have to have. thats how the red baron managed 80 something kills. dogfights, the closest thing to a fair dual a fighter pilot ever engages in, is something one tends to avoid at all costs in favor of easy kills. this might not be as true as it used to be, with radar in everything, and beyond visual range engagements, but its still in the manual. you want the most gain for the least risk. bomber pilots on the other hand flew straight to their targets, getting shot with all kinds of nasty things on the way there and back, then get all the hate because their missions often involved collateral damage. its the dirty job that needs doing. and if i was a pilot i think i would feel safer in the fighter than in the bomber. these days its all about precision bombing with stealth aircraft and as a result its a much safer and cleaner job than it was in ww2 or vietnam. but it still takes nerves of steel. anyone who goes into battle has a pair of brass ones, and i dont think its really fair to give one more praise than the other. they both have their missions and they both do them well. except of course the ground pounders who need air support. a-10s are their angels.

philae used lithobreaking.

bruce willis was in it? i didnt notice.

heres is the library i was using to get data out of my gyro. it covers many i2c sensors including most of the sensors i was using (and other platforms too so be sure you use the ones for arduino). it comes with examples. one gotcha i noticed is that sometimes an i2c device has a few extra pins for setting its address. depending on whether they are pulled up or down will change the default address of the sensor. on mine the address was set to 0x68 where the library (and device datasheet) defaulted to 0x69. here is a snippet from my code to access the sensor: //include stuff #include "Wire.h" #include "I2Cdev.h" #include "L3G4200D.h" void setup() { //start libraries Serial.begin(115200); Wire.begin(); L3G4200D gyro = L3G4200D(0x68); //set address here. this chip has two address options, this and 0x69 //initialize and configure gyro gyro.initialize(); if (!gyro.testConnection()) Serial.println("$gyro_init_fail;"); //set some gyro options gyro.setFullScale(500); gyro.setHighPassFilterEnabled(true); gyro.setBlockDataUpdateEnabled(true); } void loop() { //get data from gyro int x,y,z; gyro.getAngularVelocity(&x, &y, &z); Serial.print("$gyro_x="); Serial.print(x); Serial.print("_y="); Serial.print(y); Serial.print("_z="); Serial.print(z); Serial.println(";"); delay(50); } should run in arduino 1.0 with the libraries from the first link.

i spent hours watching youtube videos on kalman filtering. much of it was over my head, a lot of math and whatnot. but thanks to c++ libraries you dont need to understand it to use it. i dont know of any books on the subject, but i do know that many a student has written a phd thesis on it. i tried using the freeimu library with not so useful results (it was slow and very gimbal lockey). the main issue was it didnt have support for the l3g4200d gyro (i have the same one on my imu board), so i had to port the code over to a new library. the results were sub satisfactory. there was another library here that kind of looked promising, but it said that it needed at least a due to run it. again it doesnt support all my sensors but that is just a matter of finding a new library and swapping out all the function calls. dont expect any of this code to work without hours of hair pulling out.

if you have a decent orientation reference you can integrate the acceleration detected by the accelerometer and get a rough approximation of your position. acceleration * time = change in position, add up those each iteration and chart your position in relation to your starting position. but you have to transform all the coordinates out of rocket local space and into world space, and filter out acceleration from gravity out of the accelerometer data. inertial navigation is probibly beyond the capability of a single mems device, but a rocket's flight time is sufficiently short enough to not loose a lot of precision to gyro drift. when i tried it i ended up with something that maybe could keep an r/c heli level, but wouldn't be very good at knowing its location. you would need a quaternion based kalman filtering library to give you the best information for finding your orientation accurately enough to integrate position. the one i was using was only covering roll and pitch, but without heading my position would be hard to find. also euler angles are horrible with gimbal lock. quaternions also simplify the maths to vector operations and vector-quaternion multiplication. of course the avr was not well suited to this kind of maths and the project kinda stalled there. i got an arduino due for xmas so i may try again in the future. hardware wise just mount the imu board on a solid surface in the rocket. most of the imu boards ive seen have an i2c interface which is kind of straightforward to use (voltage, ground, and 2 wires with pullup resistors). you can use the wire library or whatever library works with your mems chip(s). read the data sheets for information about how to talk to the imu.

use one of the 32 bit arduinos. avrs are a little slow at kalman filtering. i was getting about 15 updates/sec on an avr using (software) float math. you could probibly speed it up with fixed point math though. kalman filtering is kind of tricky, but there are libraries you can use if you cant get your head around it. i saw a counterweight and gimbal setup used for a camera autoleveler (found it). such a thing works well if you are not translating around a whole lot. it used door hinges tac welded at a 90 degree angle as the gimbal. i would probibly want to use ball bearings for a smoother result though. you would probibly want an active system if you were mounting it on something like a vehicle or air craft. it would definitely help if we knew what you wanted to build it for.