Nuke

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.

i think modern imus have gone to solid state mems devices. though you might still see mechanical ones used in aerospace because reasons.

i dont think using super conductors/insulators in capacitor design would be of much use. super insulators may decrease self discharge rates of the device, meaning that it would not have a tendency to loose charge when not being discharged. however there will still be self discharge at the terminals. insulators used in wiring in the circuit, pcb substrate, even the air, all will allow a self discharge path (all be it a slow one). it might help out-of-circuit energy storage, but almost nobody uses capacitors in this way. doing so would also raise safety concerns because capacitors like to discharge themselves as fast as they can, so dont lick the terminals (damn it jeb) or you might die. super conductors might increase discharge rate and reduce heat generated from rapid discharge. this might help high energy applications like capacitor banks for rail guns and fusion reactors. you might use super insulators for this application as well, since caps, switching circuits, etc, may all be held at cryogenic temperatures anyway. but then again its not going to cost you a whole lot of extra power to keep those banks topped off. its a similar problem to boiloff in lox tanks, its going to need to be constantly topped off to keep up them full, but this is drops in the bucket when compared to filling the tank. so either way, its not a revolution in capacitor design. not so much as nanomaterials has been. denser packing of the layers in a capacitor helps to improve capacity vs size at a given voltage. so you can get more out of smaller devices.

three of those have been done so far so at least were on the right track.

i thought this was common knowledge for awhile now.

stop celebrating holdiays like new years.

and you thought you had lag problems now.

its such a 1970s way of doing things. i attempted designing a video card from 7400 series logic and ultimately gave up and bought an fpga dev board. i still havent built that video card one way or the other.

cinnamon rolls are too hard. its either buy them, get those crappy canned ones, or spend 3 hours in the kitchen.

if you just want a launch vehicle it would be better to keep the reactor on the ground to make fuel for a chemical launch vehicle. but if you want something you can take off from earth, fly to mars, and land there, and make the return trip all with one engine and no propellant usage while in an atmosphere, for a general go everywhere ship, then that would be totally awesome. i think a molten salt type reactor would work best here, you have your closed fuel loop isolated from your coolant loop. where the coolant loop is open, taking atmosphere from an intake or hydrogen from a cryotank and spewing it out the tail pipe, or to a closed radiator loop for offline power generation. that is a lot of heat exchangers which are heavy, not to mention the shielding for the fuel loop. you would need a high temperature version of the sabre precooler to provide the hundreds of megawatts in heat transfer. but then you get the problem of embrittlement caused by neutron damage in all those tiny tubes to deal with, so you might want another coolant loop in there or compromise with a less efficient, more robust heat exchanger. either way its going to cost you thermal power. i have a feeling it would be very difficult to get an engine with a twr > 1. bring in a small fusion reactor with direct conversion, maybe you can power electric turbine engines in the atmosphere and mpd engines in space, but that is probibly centuries away and just as theoretical as the fission hybrid.

i might swing for a solidoodle next fall if i dont have any unforeseen expenses in the near future. i believe its called another chicken and a rooster. i wont go into how it all works, its very complex, but you put corn in and out comes chickens.

there is a huge difference between owning a cell phone and wasting resources when you dont have to. cell phones are a horrible example. they dont use a lot of power, and mass production means that individually they dont carry a huge carbon footprint (unless you start getting into things like forced obsolescence, which is downright evil and should be illegal). things like running engines and heating water (or anything else for that matter) are where most of the resources (sometimes literally) go down the drain. as for rocket engines, its not like everyone takes a saturn v to work. a few launches benefits many (through science, technology, communications, etc), so its both justifiable and practical. an suv only benefits its owner. launching a rocket is more like taking the bus.

we probibly get all that material replaced by incoming natural space debrits (not our space junk). while small, it still a great many tons more than we put up there. and likely much of it replenishes our limited resources, all be in in a shotgun sort of way.

best christmas display ever. (contains much metal and the user comments will probibly be nsfw, its youtube after all)

last version i played through the tech tree without hiring additional kerbals at all. all of the extra ones i had were rescues. i didnt kill any of them.