sgt_flyer

1P2 hydraulic cylinders can help make some nice truss structure (much better looking than using EAS-4 struts :p)

Tested out G00 hinge vs M06 rotation servo Same configuration for each (50kn motor strenght) (the hinge and the servo are surface attached on the structural plate, and a long I-Beam + a 0.625 fuel tank surface attached to the rotating part of the servo / hinge. Both were capable of rotating the i-beams and fuel tank. the one in the front is the servo, the one in the back is the hinge. Results speaks for itself under normal kerbin gravity... on scene load, the G00 bent to up to 28° during my tests (inconsistent, varies on scene load) ! (number in the hinge itself) - the M06 only bent 0.03° - on each try... for 0.006 tons more, the M06 servo is really the superior choice here if you want stability (plus it has a far greater range). note : when you surface attach the M06, it attaches from it's rotation point. (so the casing rotates)

You're lucky to get out of this with a bit of wiggle i was attacked by the kraken when i tried this design for my solar arrays (whole thing started to shake itself to death ^^) mmh - can the array wings turn around their axis ?

@MaianTrey i tested the docking part of your solution (with the separate end effector) It seems it's not enough for self docking (ex : docking the arm to the payload still attached in the shuttle's bay). the moment the separate end effector comes into magnetism range, it bends the robotic arm, so when the end effector docks, the robotic arm start swinging around (as it can now clip through the end effector's cage) i'm going to try out using a end effector made of two separate parts - the middle one will stay separate during operation (except when stowing the arm) - so when the end effector docks, the middle part should prevent the arm from clipping through everything.

7k dV total ? I don't think that will be enough to achieve LEO . Besides, spaceX is trying to make the BFR, which might be a less risky method for a fully reusable two stages to orbit rocket (you have much less aero forces to worry about during separation)

Yes, self docking's the problem it's... a bit too random... you sometime see magnetism kick in and pull on the arm, you go a bit too far, magnetism disappear and you need to save and reload to retry I'm rebuilding from scratch an orbiter, going to test precomputing the arm's movements with a Kal to see if it's more reliable funnily enough, my original canadarm (before breaking ground robotics - the thing decoupled into 3 parts with various types of joints) was easier to manage :p (even with vessel switching ^^)

robotic arm direct manipulation is not easy, even with the DLC for manipulating payloads (difficult to do manually, even with mapping some angles) i guess the better way will be to set up 3 Kal-1000's to take care of the movements from stowed position to payload position, undock the payload then from there place the payload on it's final position. then a last Kal-1000 to return the arm to stowed position (could even be useful for a station based permanent arm - map the arm's servos and hinges to one or several Kals, then you just need to input the values in the Kal's editor (if you planned beforehand in editor the upcoming mission)

stock EVE

The classics - planetshine, scatterer, EVE and realplume

If you need a lot of electricity that can fit within a MK3 cargo bay 12xgigantors, 69 parts 10.4 tons ! made with Making History and Breaking ground Features : automated array deployement with Kal-1000, (can be reversed to stow them when not in use) the solar arrays have a rotation capability. and there is also a rotatron hidden in the S3/P3 section to allow to rotate both arrays. Needed quite a few iterations to make it work properly and still fit within a mk3 cargo bay. among the problems encountered : i first tried to use the smallest robotics parts (outside of the crocodile hinges) on the early iterations - that was a recipe to invoke the Kraken... - still, be careful with reaction wheels even with that version ^^ they can quickly generate a resonance within the assembly. For comparison with ISS SAW (from CXAerospace space station parts pack) :

@ScriptKitt3h where did you find kerbals with cyber brains to interface with it ?

@cy4n waaay easier to store Testing a Mobile Base System (controlled by Kal-1000 - i hope he won't lock me out ^^) - just need to pause the Kal-1000 track when it's at the correct position album with extended positions below https://imgur.com/a/TgZOXsJ As of note, the big pistons at 800kn sucks 10.7 EC/s each (regardless of the traverse rate) - if you don't have enough energy and your batteries go dry, they will switch to disengaged state (and will continue moving based on inertia / gravity)

i'm making this post so people can share their early experiments with Breaking grounds Here's a small Rocker Bogie rover that thing really sticks to the ground Configuration : motors disengaged, unmotorized. maximum angle set at -45° to + 45° on each of the hinges

i generally use various techniques depending on the boosters one is to use downward facing separatrons (or even RT5s instead of separatrons when the boosters are big enough ^^) close to the core stage on the booster. the resulting assymetry of thrust will make the booster veer nicely away from each other. (don't try this with forward facing separatrons on the outside of the booster, it generally ends with the booster's tail colliding with each other ) another way with two sets of separatrons, is having one set above the dry COM the other below the COM, with the bottom ones configured with less solid fuel, but same thrust - gives a nice two phase decoupling sequence - the boosters go away vertically from the core stage, then once the bottom separatrons are spent, the still firing topmost separatrons make the boosters go in a tumble nose away from the rocket.

@MR L A basically, it's because the wheel's position has to be extremely precise to prevent offset thrust (the dampener force is not exactly lined up with the wheel's visual model) - even then, when using maximum pressure, the part bend slightly worsening the offset. (And it's even worse with a center of gravity far away from the drive) the reaction wheels are basically there to compensate the resulting torque now, be careful on long range missions, you can basically only use the drive from lower orbits in planets SOI, as the wheel stress rises the further away you are from the planet you're orbiting. If stress reach 100% the dampener breaks and the drives stops working. (On kerbin near 7000 KM stress is near 100%, on duna it's 4000 km) so you need very precise transfers (or classic engines to do course corrections) :p it's doable though, managed to get my mk-2 version from kerbin's surface to duna's low orbit with only jet engines (for getting above krakensbane speed) and the mk-2 krakendrive for getting into orbit, make the transfer, and braking near duna

Well, you can see it in action in the video in the first post https://www.youtube.com/watch?v=DFNXb2aaxA4&ebc=ANyPxKqVZYu5H479wuEP15RcuIyBzHIeaKqpTwmSbzWOvc-K-89UahjnIOkpCMUmRLWf9UayNIDA As for the how, basically when the wheel dampeners try to extend after having been compressed, the force is only applied to the craft the wheel is a part of (instead of also applying to whatever the wheel is pressed on). Normally there's no problems (wheels usually press on a planet's or moon's surface), It's simp'y a computing simplification for limiting the resources used by the physics engine of the game. But here, when it's the same craft that press on the wheel, the wheel only impart force in one direction (instead of two), resulting in net thrust. Before the game swithed to unity 5, the wheels could interact with the same craft, so you never needed a separate part since unity 5, wheels can't interact with the same craft, so you need a separate intermediate part. Basically, you get : 1) Part A wheel's dampener is compressed by part B. 2) Part A wheel's dampener try to extend back, pushing part A away from part B (but imparting no force on B, while in real life it would impart force on both sides) 3) because the part A also pushes on B (but B get's no return force from the wheel), you get a net thrust. It's like that magnet troll physics meme Now, for the two modes of operation (hover mode vs thrust mode) it is thought it's because Krakensbane steps into action (Krakensbane is a piece of code added by the devs to prevent kraken attacks (which worsened the faster / farther you went), but this code only steps into action after you went faster than a specific speed Now for the pure mechanical in this craft (outside the troll physics), the objective was to have a reliable sliding mechanism with redocking for part B within part A. Using the airbrakes authority limiter allows to control the movement of part B, pressing it more or less on the wheel, controlling in return the amount of force applied by the wheel on the craft When the airbrakes retract, they pull part B to redocking range (in te 2.5m model)

@Vanamonde well, i like to tinker around in the VAB more than i do missions so for me, the Krakendrive redesign was more an exercise in improving my knowledge of those, rebuilding those, and trying to improve the concept further Learned a few more vab tricks in the process which can help me in other cases

ok, tested a few things with a rebuilt the mk2 version. (tightened the slides, rebalanced the wheel position to limit reaction wheels needs) (note : i play with max physics delta time per frame set to 0.03, guess it helps taming the kraken a bit :p - he has less time to try to wreak havoc on physics ^^) from those tests, seems the wheel stress changes based on distance from the orbited body, instead of the speed of the craft. from early measurements made from a 100x100 save, seems like at 6500 km above kerbin the wheel stress rises to 95% when the k-drive is operationnal. note : quicksaving and quickloading before engaging the drive reduce a bit the stress at a given altitude, but it's a bit random From 100x100 orbit around Kerbin, with various saves : (the last save and load is made at the previous altitude) - ko means the wheel stress broke the dampener Stress Altitude 1.9 400km 2.3 500km 4.8 1000km 12.8 2000km 24.5 3000km 40.1 4013km 100/ko 7000km 100/ko 8000km Here, there was a quicksave and a quickload just before engaging the k-drive. Stress Altitude 1.0 400km 0.8 500km 2.1 1000km 10.5 2000km 10.5 3000km 15.3 4013km 30.0 7000km 100/ko 8000km in this last table, all tests with the last save and loads made from a 100x100, the orbit was then extended to an orbit with a 100km periapsis and an apoapsis at the edge of the body's SOI. no save before each test. : Kerbin Duna altitude 60 2870km 40 100 4000km 59.1 5000km 82.2 6000km 95 6500km It seems the wheel stress increases faster on a body with a smaller SOI. The tests were all done with the prototype seen here, which did make the flight from Kerbin's Airstrip to duna, with no rocket engines nor RCS ! Propulsion : 2 whiplashes (for takeoff and accelerating up to transition speed), 1 MK2 KrakenDrive the transition is real smooth with jet engines to bring the kdrive above 100 m/s simply set the authority to 56 / 57. Take off on jet engine, and accelerate to 100 m/s, engage the k-drive, then shut down the jet engines, the K-Drives do the rest. (throttling down the k-drive a bit during high altitude acceleration phase helps not burning ^^) now, for the flight to duna, i managed to make my transfer with a 1000 km periapsis around duna directly from LKO, as i had no mean to correct the trajectory (because of the behaviour shown above). I guess a more complete prototype with small rocket engines for course corrections would make the best use of this KrakenDrive. i'll try to test various SOI's to get to know the safe operation altitudes for the engine

it's kraken based technology it can be unpredictable by nature though, it's seems the further away from kerbin (or planet), the faster the wheel stress rises. when i tried braking after entering jool's orbit with low thrust, wheel stress rose instantly to 100% and broke the dampener. i guess it could still be used to send things on an interplanetary transfert, then you detach the drive and send it back to kerbin for the next payload

If you have the plane with it's propeller set to give it 50 kph forward motion, while the belt is set at 50 kph backwards, the plane will go forwards at 50 kph. (Well, could be slightly below 50kph forward because of the tiny amount of friction you could experience in the wheel's bearing) the wheels would simply free spin at two times the speed they would if there was only the plane rolling at 50 kph on runway Do the same with a classic car on a conveyor belt however, and it would appear stationary all because of the different mean of propulsion : a classic car uses the wheels to 'push' against the road to provide forward motion. A plane pushes against the air to provide forward motion,which is not affected by whatever would happen on the ground Now, if you mount an aircraft engine and propeller on your car instead of it's classic engine, and put the wheels in free spin, it would behave like the plane described before on a conveyor belt After that, most of the remaining arguing in this thread could be resumed around the scenario that the belt no longer tries to match the vehicle speed, but the wheel's rotation speed instead, which results in some kind of edge case which quickly get to either infinite speeds or mechanical failure ^^

Added the video of the KrakenDrive in operation to the post https://www.youtube.com/watch?v=DFNXb2aaxA4

Hello, i scratched my head for some time for rebuilding an effective stock KrakenDrive, within the current limitations of the game, notably that wheels don't collide with the same craft - you need a separate part for the landing gear to press upon for that. Second problem, is getting a mean to redock this separate plate after use, for warp time or for saving games. for that, i started playing around with Airbrakes to give the pressure plate enough spacing from the docking port, to get it to redock once the airbrakes retracts. So the basics is simply having a moving part applying various levels of pressure on the wheel, with rail guides to prevent the moving part from escaping. One incredible bonus in having this kind of setup, was that it was possible to change on the fly the amount of pressure applied on the landing gear, simply by varying the airbrakes authority slider. The result, is that it was now possible to control the KrakenDrive's thrust within both Hover and Thrust modes ! one thing i realised that changed though, was Krakensbane (pre 1.0, the transition speed was at roughly 700 m/s speed) During hover mode with High G manoeuvers, the thing sometimes transitionned on it's own from hover mode to thrust mode - within atmosphere ! once in thrust mode, it was easy to get the thing to orbit on it's own Tested various form factors for the engine, and i could miniaturize it enough (though, it's a bit less stable) to fit within a single CRG-08 MK2 bay ! Here's the video of the drive in operation : Here's the full mission album : https://imgur.com/a/SJtQn0o Here's the .craft files (Dropbox) KAT 25 (2.5 m form factor) : https://www.dropbox.com/s/3ie9xeimhq2xk0b/KAT 25.craft?dl=0 KAT MK2 (MK2 form factor) : https://www.dropbox.com/s/0h2tdzzu1ct80vy/KAT MK2.craft?dl=0 mods / DLCs i had during this KrakenDrive's devellopment : Making History KER, RCS Buildaid, EVE and Planetshine. While i have Making History, i didn't used any part from MH within those two drives, so a stock install should be able to launch them. i didn't use any of the new decouplers either, though i don't know how it will react in other versions of the game Operations : Pin down the AIRBRAKES, and use the slider to change pressure. the KrakenDrive effect threshold is roughly around 54% slider. For the KAT 25, press AG 1 to toggle on and off the KrakenDrive. it will redock on it's own when turned off. For the KAT MK2, press AG 1 to turn on the KrakenDrive, and press AG 2 to turn it off (a reverse pair of AIRBRAKES will then push back the pressure plate to redocking range) note : if you incorporate the MK2 within a spaceplane, you'll need to keep the cargobay slightly opened (1% in clamped mode) else the airbrakes will not move within a fully closed cargo bay. In Hover mode, the speed can vary between slightly negative descend speed (between 0m/s and -1 m/s) (though you're really at minimum effect), and + 20m/s of vertical speed (the krakendrive can't get higher vertical speed in hover mode, once reached, it's not necessary to continue to increase the airbrakes authority further) Transition : seems the transition speed seems to be between 60 and 100 m/s, the krakendrives can achieve transition during High G manoeuvers in hover mode, (though, generally, you have a really high airbrake setting at this point, the thing will be nearly uncontrollable until you dial back the krakendrive to a lower thrust setting, generally by 57 / 58% of the AIRBRAKE slider) Thrust mode in air : within atmo, you will be limited by the Krakendrive's drag, don't expect to be able to break the sound barrier with it while under 10000 m. (throttle back the krakendrive to keep a steady speed near 300m/s while under 10000m) above 10000m, the acceleration of a given setting will gradually increase as atmospheric density decreases. feel free to throttle back further to get a steady ascent (plus, it will protect the KrakenDrive from atmospheric heating) once in orbit, you can circularize with classic Kdrive operations. (and with thrust control on the kdrive, it's easy to get into low G thrust, the deactivation of the kdrive is nearly instantaneous when you hit the button (in ship mode though ^^, actiongroups won't respond in map view) In thrust mode in space, i've seen the krakendrive go from roughly 0.5G of acceleration to above 35Gs ! thankfully the thing is built like a tank so, there's nearly nowhere you can't get with those ! Limitations from my test : The number 1 limit for these KrakenDrive seems to be the Wheel Stress. the faster you go, (above 20000/30000 m/s of speed) the faster the Wheel Stress rises during operation. (and it's hard to brake if you're too fast, the stress still increases while braking) once wheel stress reach 100%, the gear's damper breaks, and krakendrive stops working. Other Limitation : the krakendrives don't seem to like aerodynamics. aircrafts with active KrakenDrive onboard are very hard to control from the few tests i made, an open ended MK2 bay at the rear of a plane can be moderatly controlled. trying to place the KDrive near the COM seemed to help to if the Kdrive was embedded within the plane. Getting to hover mode while in space : not really recommanded possible (slow down to near 0 orbital speeds), but can have side effects (can break the Airbrakes), that said, managed to land the KAT 25 on Mun once, all on it's own Have Fun playing with it, i expect KrakenDrive researchers can get new ideas from it (at least, the few KDrive researchers that weren't lost in the Kraken's belly for abusing it's powers .... the Kraken's behind me isn't it ? ^^

Hmmm. 1- how are the vectors configured ? You might want to limit the gimbal range, and even turn off gimbaling on most of them. With the COG so far away from the gimbals, lateral stresses must be simply insane 2- position of the root probe core can impact stability, leading to excessive overcorrection of SAS. you can check by trying to fly it without sas enabled and without touching the controls to see if it survives. If it survives, try placing the probe core near the engines. 3- check the first item that broke in the game's mission logs (F3) (likely one of the fuel tanks) - basically one part broke free within the clipping, leading to that RUD. 4- try to change the position of the tank onto which you applied the symmetric mk3 tanks. (Instead of on the bottom, place it on top, etc). 5- if nothing above works, it might simply be just too heavy check by using a single column of mk3 tanks of the correct height, with the corresponding number of vectors 6- finally, if the column itself is too heavy, try to switch to a shorter core stage with fewer engines, but add boosters around it with fuel crossfeed to keep the core topped off (you might want to use 1.25m SRBs for separatrons though ^^) one of my old projects of the kind : https://imgur.com/a/t5QL2 (It was able to put 1500t of oversized payload to lko ^^' before autostruts even existed thanks to a crisscrossing of struts meant to average the load) ^^ in any case, your twr might be a bit low, as your rocket is without both upperstage and payload

It was never built, (N-1 was favored in it's place) : Chelomei's UR-700 rocket http://www.astronautix.com/u/ur-700.html Was quite an advanced concept for it's time , even reusing some hardware from the proton rocket the side boosters were mated by pairs on this thing, one half of the pair carrying an extra oxydizer tank, the other half an extra fuel tank - those where meant to top off the central cores. It was meant to use crossfeed long before KSP besides, the 3rd stage (on top of the 3 boosters forming the core stage, was meant to be a modified first stage of the proton rocket ! (The modified proton stage was to only have 3 engines and 3 side tanks, instead of 6) that version was planned for 151 tons to LEO another version of this rocket would have replaced the 3rd stage with an NTR stage ^^ crazy concept which would feel just so KSP ^^

@MaianTrey A small hint for a stock mobile base system : Since the wheels physics update, wheels work in space if you can 'press' a bit the wheels against a flat surface (I tested it when i designed the s1-s0-p1 truss sections ^^)