Problem Docking ports, approach and mate

[paddy2]

I am designing my first vessel and am have trouble with getting it to dock to a Delta Glider.

SetDockParams (_V(0,8.86,0), _V(0,-1,0), _V(0,1,0));

is the line of code.

So the docking port is aligned to the centre line of the craft but 8.86 metres up. For me to say its working right, you need to move down a line coming out of the top dead centre of the craft to do a good docking.

As I know little about C++, it is modified Code from the ShuttlePB in the samples folder.

From the 3Dmodel PDF
<xi> <yi> <zi> is the reference position of the docking port in the vessel’s local coordinates.
{8.86 Metres up got that}

<dxi> <dyi> <dzi> is the direction in which a ship approaches the dockingport in the station’s local reference frame. 0,1,0 or maybe 0,-1,0 to come in “head” first {tried both!!!}

“<rxi> <ryi> <rzi> is a reference direction perpendicular to the approach direction used for aligning an approaching ship’s rotation along its longitudinal axis.”
As a native English speaker I understand the words but have no real idea of what this is on about!! nor does playing with the values seem to change anything.

Using the UAP docking auto pilot the craft get close to the Test DG but only seems to want connect via its ears not the top of its head!! It never does that last 90 degree rotation required.

The RCS works fine manually and the standard VC buttons will get it to move to prograde, kill rotation and the like

Any pointers here gents????

---------- Post added at 03:52 PM ---------- Previous post was at 03:51 PM ----------

Yes I re compile the .dll after each change

 

[Urwumpe]

Perpendicular = 90° to the reference direction. Or: scalar product of direction and rotation vector should be zero: dx*rx + dy*ry+dz*rz = 0

In your case, the two vectors direction and rotation are (anti-)parallel and NOT perpendicular at all.

0 *0 + 1 * -1 + 0 * 0 = -1 !!!!11

Yes, the description of the reference lacks some clarity. You must always define the vectors in a way, that its possible to define an orthogonal coordinate system with them.

 

[ADSWNJ]

It's simply asking you for the three things that I need to do a precision docking with RV Orientation (shameless plug!!). I.e.

1. Where's the center of your docking port in ship's local coordinates.
2. Give me a direction vector to travel to dock with you (i.e. what way is the port facing).
3. Give me a direction that represents "up" on your docking port, so I can rotate to align properly.

I.e. what my friend Urwumpe is saying to you is the "forward direction" to the port and the "up direction" have to be right angles (e.g. _V(0,-1,0) and _V(0,0,1)), not parallel to each other else "up" doesn't mean anything.

By the way - if you are doing a docking sequence, you need to be able to convert local port coordinate systems into local ship coordinate systems (ie. translate and rotate the matrices), then to global, then back to your local ship, then to your port and to your viewing position, and then project in 3D onto a HUD. Pretty interesting manipulations, but PLEASE get your coordinates right, or I'll crash into you

 

[paddy2]

So if I have it right......... (big if)

First numbers are the location of the middle of the docking ring

in my case its in the middle but 8 odd meters up 0,8.86,0

it maybe 8 meters up but it also points up "y" not sticks out like my nose "z" or ears "x"
0,1,0
and there is a locking pin or something to line up with like the numbers on a clock face

0,0,1 which would mean that the under carriage of a DG faces my nose

Thanks gents

 

[ADSWNJ]

X is left/right, Y is forwards/backwards, Z is up/down. Add the right sign depending on your perspective (inside the ship or outside, etch).

The 8.86m is the offset for a stock DG forwards to the front port. The -1 on the direction would say you fly into the port from the port inwards towards the ship origin. The last number should be a _V(0,0,1) for up (or down!).

 

[Urwumpe]

X is left/right, Y is forwards/backwards, Z is up/down. Add the right sign depending on your perspective (inside the ship or outside, etch).

Wrong.

X is left/right
Y is up/down (important for hover)
Z is forward/backwards (important for main engines/retro engines)

(All important if you want to program your RCS)

 

[paddy2]

Thanks for the help folks, done a number of dockings now. Yet to test a lunar surface to orbit, to aligned, to close, to dock but each part has been tested. Then to work on a 2nd vc with a docking camera.

 

[ADSWNJ]

Wrong.

X is left/right
Y is up/down (important for hover)
Z is forward/backwards (important for main engines/retro engines)

(All important if you want to program your RCS)

Oops! Sorry for the transposition of Y and Z.

I checked the numbers for the stock DG:

pos _V(0,-0.49,10.076)
dir _V(0,0,1)
rot _V(0,1,0)

i.e. on the centerline, 49cm below the origin, 10.076m forward, with a direction vector in the Z plane (pointing out of the port), and a rotation vector pointing up at "12 o'clock" on the docking port.

As Urwumpe said!

 

[paddy2]

on the centerline, 49cm below the origin, 10.076m forward, with a direction vector in the Z plane (pointing out of the port), and a rotation vector pointing up at "12 o'clock" on the docking port.

If only that had been written down like that I would have much farther along in finishing my project. Just got to find out why the RCS is hunting to the final value using HoverMFD and I can pop it off to the hanger for sharing.

 

[Urwumpe]

If only that had been written down like that I would have much farther along in finishing my project. Just got to find out why the RCS is hunting to the final value using HoverMFD and I can pop it off to the hanger for sharing.

Requirements specification is ALWAYS 70% of solving the problem. :thumbup:

For the RCS, remember that you have two different ways to define it. In configuration files and spacecraft3.dll, you only define the reference thrust around the surface of a spherical spacecraft - and the direction of the exhaust flames by pointing away from the spacecraft.

In the DLL, you usually define the thrusters with the direction of the thruster being the direction of the force vector (opposite of the direction of the exhaust flame)

Also, for the rotational RCS, it helps knowing which torque you need for which axis and direction of rotation to check if your RCS is properly defined.

 

[paddy2]

Hi Urwempe,
Got the thusters working nicely and exhaust lined up. ( couple of typo's did mean I had 3 working together and 1 working against !!)

Just now if I set it to point at 90, it sweeps round to 110, back to 80 ( so far so good) but then its 95,86,94,87,93,88 for about 60 secs. If I reduce the RCS power the UAP docking routine takes forever to close up.

Then its a case of working out a happy balance of power to weight , fuel needed/wanted/required ..... fine tuning

 

[Urwumpe]

Its mostly UAP using ineffective coefficients for its guidance and trying to establish much higher attitude rates, than the spacecraft can reduce in time. If you would do that yourself in your own autopilot, you could limit such overshooting to a few arc minutes. You would need to make the RCS much stronger instead of weaker, since the thrust of the RCS defines how fast the spacecraft accelerates or stops its rotation, while the maximum rotation speed is always unlimited by physics (unless you implement structural damage due to excessive rates)

 

[paddy2]

do that yourself in your own autopilot

How very nice of you to think me capable of such skill:rofl:

I am 60 and only just worked out joined up writing.

Actually one of the lines of thought that I had when I started this vessel was "Why do we need a manned DG just to ferry boxes to and from the surface when we have autopilot like UAP and HoverMFD. The craft is really just a cage and rockets. The function of the docking is just to hold the thing still while its loaded /unloaded.

 

[Urwumpe]

How very nice of you to think me capable of such skill:rofl:

Its less complicated as it seems initially. The real magic starts much later, when you play with multiple-adaptive autopilots.

In the simplest case, you can already get good results by just saying "Move in this axis at 1°/s until target attitude is 2.5° away. Then move at gradually decreasing speed until distance to target is 0.1°. If closer to target than 0.1°, don't so anything at all."

That's no magic.

I am 60 and only just worked out joined up writing.

60? That's still young.