Jump to content

[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread


r4m0n

Recommended Posts

Is it normal that the new version of mechjeb(used in 0.23.5) than the previous version(used in 23.0)?

With the new one(in 23.5) I have an orbit of 67km*81km when I shoose a 75KM orbit; in 0.23 I would have an orbit of 75*75(more or less).

----------------------------------------------------------------------------EDIT-------------------------------------------------------------------------------------------------(yeah, I had nothing to do but making this line)

I downloaded the latest dev built and everything is good!

Edited by goldenpeach
Link to comment
Share on other sites

Anyone got a pic of a properly functioning mechjeb biome functionality? My mechjeb (.221) is functioning as per usual as far as I know.

Everything I know that's new:

http://i62.tinypic.com/2z50tmq.jpg

No overlay in map mode or anything. Toggled all buttons everywhere.

Assuming my install of MJ is up todate, where is that target biome feature/overlay/landing biome info?

Here is what it is...I think! It just tells you what Biome you're targeting when you go to 'pick a target on map' This is build 221: (BTW I didn't just copy the new DLL, I reinstalled MJ with the entire package with 221)

5NJaaon.png

Edited by Eleven
More explanation
Link to comment
Share on other sites

It also tells you the biome in the landing prediction if you're on a sub-orbital trajectory in the landing prediction section :D

I didn't know about the target selection thingy, nice :D :D

Link to comment
Share on other sites

Anyone got a pic of a properly functioning mechjeb biome functionality? My mechjeb (.221) is functioning as per usual as far as I know.

Everything I know that's new:

http://i62.tinypic.com/2z50tmq.jpg

No overlay in map mode or anything. Toggled all buttons everywhere.

Check the "show landing prediction" box to have it show in the landing AP.

Link to comment
Share on other sites

Could you explain what you mean by "unnecassery"? Are you suggesting that it would land acurately without a course correction?

The way that it works in the current version is (perhaps a little simplified) as follows:

1) High deorbit burn (unless it is doing a low deorbit burn, but that is a different matter!) This involves waiting until it is a quater orbit away, and then both changing the plane (hence the quarter orbit away) and lowering the periapsis until it is 10% below sea level.

2) Then it performs a course correction which will stop once the predicted landing spot is <150m from target

3) Then it coasts towards a deceleration burn. If the predicted landing site is more than 600m from target it will got to step 2 and course correct again.

4) If there is an atmopshere, during both 2) and 3), once the atmospheric drag is >100mm/s2 the statistical analysis of the predictions starts to time the parachutes. This is significant because if the flight path does not pass over the target at this point then timing the parachutes can not move the landing spot laterally. However because it can correct for over/undershoot it is likely to bring the error down to less than 150m and therefore not course correct, and so not correct the lateral error. For this reason it might make sense to turn the autopilot off and on again before reaching step 4 (100m/s2 drag) to force a correction if the error is let's say 300m (and significantly if there is a lateral error.)

5) The parachutes will open at the time that the satisitical analysis say they should - once at least one parachute is deployed then course corrections are not allowed, as the parachute drag would prevent the craft having effective attitude control. The deceleration burn will fire if the speed exceeds the target speed defined by the breaking policy*.

6) When we reach the deceleration end altitude above the predicted landing point (where the deceleration end altitude is something to do with the distance covered to produce enough drag to cancel our current speed, or something - it is a bit complicated and I do not quite understand it, or for bodies with no atmospehere it is 500m) we then move to the final decent phase, which is esentially a free drop down to a suicide burn to hopefully touch down at your desired speed.

7) The landing legs will deploy at any stage once the AGL < 1000m

That is pretty much how I understand it. So like I say I am not sure what you mean when you say a course correction is unneccasery. In the high atmosphere it is possbile and can result in a more precise landing. Once the drag gets too large then performing a course correction becomes difficult depending on the design of your craft, and once a parachute is deployed it becomes impossible.

Does this hold for planets other than Kerbin? Because when I try to use Landing Guidance on Duna it just can't succeed.

Edit: to clarify a bit, making course corrections in the atmosphere doesn't work well when you have Deadly Reentry installed. Things tend to blow up...

Edited by mdapol
Link to comment
Share on other sites

Dev Build #221: Cannot dock with MechJeb with the Clampo-tron docking port. It just flies around using up propellant, sometimes hitting my station (a fuel depot in Munar orbit.) It's aggravating. The only time is will "try" to work right is when I have both vessels target each others docking port and the station just spins with the lander craft circling trying to dock. Otherwise, if you just try to dock by selecting the target port and selecting control from here on the spacecraft trying to dock, it just moves around to "0.00" starting point with the x,y,z errors slowly getting larger.

Clean build and install.

It seems all other functions work well.

Edited by Meridius
Link to comment
Share on other sites

Removed and re-installed dev build #221. Restarted KSP. I put two generic Mk 1-2 pods in 150km orbit. They each had shield clampo-trons. Could not get them to dock singly, however, I ordered one to target the other (Raptor 5 to target the port on Raptor 6). The Raptor 6 docked fine. Space station (KSS) is unable to allow dock because it tries to spin towards it target (Raptor 7, generic Mk1-2 pod with shielded clampo-tron). Raptor 7 would not engage its docking program and would just wonder to "0.00 starting position" and burned up it propellant while wondering off and losing lock.

Something is screwy with the docking program.

Link to comment
Share on other sites

I apologise in advance if this is known and has been stated before but I cannot get the latest dev build 221 to launch to any other plane than the standard 90 degrees :(

Edited by Green Skull
Link to comment
Share on other sites

For some reason, MechJeb RPM integration isn't working in #221. I could have sworn it was a few updates ago.. can anyone help confirm it?

Have you updated your RPM? They have released a new version for MJ 2.2 (with a new MechJeb2RPM folder) to allow integration. (MJ RPM integration happens on RPM side)

Link to comment
Share on other sites

Have you updated your RPM? They have released a new version for MJ 2.2 (with a new MechJeb2RPM folder) to allow integration. (MJ RPM integration happens on RPM side)

Yes, and it was working fine afterwards. I'll double check everything's there, but I could've sworn it was all working fine after I updated everything and only changed after I downloaded #221.. :/

Link to comment
Share on other sites

Dev Build #221: Docking.

I've had one attempt get stuck. I just switched the autopilot off, gave the craft a nudge and switched AP back on and it fixed itself. I mention this because another 15 or more docking operations completed successfully. Standard clampo-trons but always using a single pair of B9 5 port thrusters.

What I have noticed with docking:

Excessive safe distance.

Initial movement to starting location is not optimal, sometimes the craft will backtrack 60m or more before moving around the opposite side of the target craft and eventually coming almost full circle to complet the operation.

A few times I've seen a craft undock and start spinning as it somehow inherits a SASS kill rotation setting.

On occasion a craft has undocked and RCS has immediately activated and stuck on, Auto Dock, while no longer active was displaying as green in the menu, clicking it off allowed RCS to be manually switched off.

I was using 136 and 144 with KSP 0.23.0 and while perhaps less cautious I feel docking was quicker and the path more predictable.

All in all, I wouldn't be doing what I'm doing without this so, many thanks for the continued work :)

Link to comment
Share on other sites

Yes, and it was working fine afterwards. I'll double check everything's there, but I could've sworn it was all working fine after I updated everything and only changed after I downloaded #221.. :/

I think RPM have to recompile for each version of MJ and scansat to retain functionality. I have found that if I want MJ and scansat in RPM I have to stick with fairly major builds of all three (less so with RPM).

Genrally if MJ does not work in RPM it is due to the Mechjeb2RPM folder not linking correctly anymore so posting there would be the best option although RPM does not like to fork to support dev versions...

Edited by John FX
Link to comment
Share on other sites

I think I've found a case where MJ reports delta-V incorrectly. I made a lander with an upper asparagus configuration fed from a lower asparagus, and as the lower stages are dropped the engines above ignite. MJ seems to get confused by this arrangement, only reporting the correct dV for each stage as it becomes active and misreporting the upper asparagus dV until the entire lower asparagus is staged away. KER and MJ give different dV readouts, and I think the KER one is correct. Not a big deal, as the staging is unusual enough that it's a bit of a corner case, but I thought I should report it.

Post with pics and stock .craft file.

Link to comment
Share on other sites

Can I ask for a check to be introduced for executing the last couple of m/s of maneuver nodes?

If the craft has already done a full circle or two `chasing the node` without getting to it and without using thrust then could the craft be stopped for a small time and then the node checked again? I found that a small rotation on some craft can fool KSP into thinking the craft has lateral motion (it seems that the centre of mass is not in the centre fooling KSP into thinking there is motion when rotation is applied). This means MJ adjusts for this and chases the new node position and just spins thinking there is still about 0.3-0.4m/s of burn left and always `just over there`.

What is actually happening is that there is 0m/s burn left and MJ would see this if the craft would stop spinning for a second.

Currently all my craft get to under 0.5m/s of burn and then spin, never completing the burn.

MJ chasing the node makes the node uncatchable.

Link to comment
Share on other sites

Have you updated your RPM? They have released a new version for MJ 2.2 (with a new MechJeb2RPM folder) to allow integration. (MJ RPM integration happens on RPM side)

Ok, stripped out everything (MechJeb) including MechJeb2RPM (4/12/2014) and reinstalled both, clean. "No joy." Cannot dock to a station. Looking at the safe distance, it is excessive. I tried all 6 docking ports. It will not complete a docking program. It will try to dock only when both objects are targeted, then the station just spins and the craft runs out of propelent (750) and/or autopilot shuts down.

Unfortunately, I must go to work.

Link to comment
Share on other sites

I made a video showing what happens when I try to use the Docking Autopilot. Please let me know if you need me to make more. This happens every time.

One thing I noticed, watching your video, I'd put more RCS ports on that rocket. I'm thinking it has too much mass for the ports you have. Personally, when I build something like that I'm going to dock, I put a ring of 4 ports near the nose, and 4 near the tail, maybe 4 in the middle too. I find I get much better translation control that way, as I do my own docking. I'd try it and see if that helps MJ get this under control. It could be dancing rings around your docking target because it can't get itself up to speed and slow down fast enough.

Link to comment
Share on other sites

One thing I noticed, watching your video, I'd put more RCS ports on that rocket. I'm thinking it has too much mass for the ports you have. Personally, when I build something like that I'm going to dock, I put a ring of 4 ports near the nose, and 4 near the tail, maybe 4 in the middle too. I find I get much better translation control that way, as I do my own docking. I'd try it and see if that helps MJ get this under control. It could be dancing rings around your docking target because it can't get itself up to speed and slow down fast enough.

He definitely needs better RCS placement there. Note the constant counterfiring on the RCS. That's happening because the ship is offbalance and when it tries to translate it's going to move out of alignment. That necessitates firing the ports on the opposite side.

However, that also means that the force spent keeping alignment is counteracting the effort expended in translation. The net gains will either be small or non existent depending on how much force it's having to spend to keep it aligned.

That said, the last build I tested demonstrated flawed logic in the docking process where I could take a small craft with perfect RCS balance and place it in front of an identically designed craft. Not quite in front mind you, a little off-axis such that the procedure taken should have been: Align, translate to axis, move forward. Instead it was thrusting away under RCS power until it was outside the 200m limit.

I hate to say but I'm still using build #168 compiled for 0.23.5. With some very minor tweaks to the docking AP. (like, 2-3 lines of code changed). Using that build, I can take my RCS test craft, undock, switch controlled from port and target port such that they're basically back to back. I can't even describe to you how beautiful it is to watch. Very delicately and precisely, the one craft just translates up a bit, backs up until it's on the right side, drops back down and moves forward and docks.

Unfortunately I lose some recent promising changes in the latest builds but for testing purposes right now, it's more important for me to have craft that can dock reliably, especially when I'm testing something harder to dock than my little test targets.

Edit: Decided that there's been enough builds since the last time I tried it to try again, using my standard docking targets. (download them here if you want a quick simple stock craft to test with)

Definite improvement over previous builds. I'll try it with something a little more massive that represents what I might need to dock in actual gameplay.

Edited by Starwaster
Link to comment
Share on other sites

If one of you mech jeb heroes have the time, would it perhaps be possible for the maneuver planner to be re-organized? The current switch to the left or right tab options are very user unfriendly. Every time a feature is added it becomes more difficult to find the right tab. A quick solution could be a vertical button list of possible tabs to the left or right of the view. Or maybe allowing each of the options to be integrated into blizzy's toolbar.

It would be awesome if those buttons can be constructed as macros so that I can set up two buttons, one creates a maneuvering node with an apoapsis of 100 the other with an apoapsis of 200.

If all else fails, then perhaps the option to disable the options we don't use so we can more easily maneuver our way around the maneuver planner?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...