# SDK QuestionAltitude in VS2

#### gattispilot

So Is there a way to set the Altitude of a vessel?

I know there is :
PHP:
17.57.3.76 double VESSEL::GetAltitude ( ) const
Returns the altitude above the mean radius of the current surface reference body.
Returns
Altitude above mean radius [m]

But is VS2

PHP:
• double surf_lng
longitude of vessel position in equatorial coordinates of rbody [rad]
• double surf_lat
latitude of vessel position in equatorial coordinates of rbody [rad]
• double surf_hdg

• VECTOR3 rpos
position relative to reference body (rbody) in ecliptic frame [m]

But what I what to do is raise/lower the vessel at the same spot.
I can give the appearance of it by shifting the mesh. But then the external view is wrong.

Not sure if changing the touchdown points might do it.

Really don't want to use hover as I want level flight and the ability to stay in one place

#### martins

##### Orbiter Founder
Orbiter Founder
Sorry, but from your post I can't figure out what you actually want to simulate.

But is VS2

Why are you talking about VS2 (I assume this is VESSELSTATUS2)? Do you want to place your spacecraft at some arbitrary position, ScenarioEditor-style? Then I don't understand the rest of the post.

But what I what to do is raise/lower the vessel at the same spot.
I can give the appearance of it by shifting the mesh. But then the external view is wrong.
This is a terrible idea. The vessel's centre of gravity is required to coincide with the origin of the local vessel frame, and the CoG will have a given location relative to the mesh representing the vessel. The only legit reason to shift the mesh is to compensate for an equivalent shift of the CoG. If you start moving the mesh around randomly then a lot more than the view will break. You will mess up the physics as well.

Not sure if changing the touchdown points might do it.
Is it a vessel sitting on the ground, and you want to simulate it raising/lowering itself on its landing gear/struts? Then setting the touchdown points is the right way to go. However, then I don't get this:

Really don't want to use hover as I want level flight and the ability to stay in one place
So it's not sitting on the ground after all? Isn't "level flight" and "ability to stay in one place" exactly what hover engines are supposed to provide you with?

What is your mystery object actually using to accomplish that, and why can't you simulate just that, instead of fudging something that looks a bit like what you want?

#### gattispilot

Thanks. Yes VS2=Vesselstatus2.

So what I want to do is have smooth flight like a drone. Where you have throttle and a direction.

For movement I change the lat and long and hdg.

But need to be able to rise and descend. I tried the hover engines and the craft would flip over and would move around.

So can I use hover to raise lower and use the other way for movement? The craft is light in mass 450kg

Last edited:

#### martins

##### Orbiter Founder
Orbiter Founder
Thanks. Yes VS2=Vesselstatus2.

So what I want to do is have smooth flight like a drone. Where you have throttle and a direction.
Well, the throttle presumably controls the RPMs of your rotors, so you need to calculate the the lift generated by each rotor as a function of that (in addition, the lift force will of course depend on other factors, such as atmospheric density and relative wind velocity).

For movement I change the lat and long and hdg.
Not a good idea. Try to work with the physics engine instead of bypassing it.

But need to be able to rise and descend. I tried the hover engines and the craft would flip over and would move around.
Although it may be possible to use the hover mechanism to simulate your rotor lift forces, it is probably better to use custom forces for that. If the drone flips over, then this indicates that your force distribution is unbalanced. You need some feedback system to apply differential RPM settings on the different rotors to get to a commanded attitude. This will be required anyway for steering the thing. Did you consider looking at actual drone control software for this?

So can I use hover to raise lower and use the other way for movement?
Yes. For example the DG hover hold Alt/Vs autopilot does that, so you could look at that. It also has an attitude control system that can be used to tilt it and give it a horizontal velocity. This would be the correct way to induce movement. Don't use the "other way" whatever it is.

#### martins

##### Orbiter Founder
Orbiter Founder
Where you have throttle and a direction.

I was just thinking about the direction part. How does a drone implement rotating on the spot? Presumably, if you consider a quadcopter, each pair of neighbouring rotors has the opposite spin direction, to cancel out any resulting torque. So I guess you could lower the RPM of two diagonally opposite rotors, while raising the RPM of the other two (to keep total downforce constant). Since the two opposite rotors have the same spin, this would induce a torque and rotate the drone. Is this how it's done?

#### gattispilot

I imagine the drone software has a gyroscope and controls the rotors to spin and different speeds to keep the craft in place.

So by adjust the vessel lat and long I can move the vessel along the ground. But I need to be able to rise and lower. So I will try the hover

#### martins

##### Orbiter Founder
Orbiter Founder
I imagine the drone software has a gyroscope and controls the rotors to spin and different speeds to keep the craft in place.

So by adjust the vessel lat and long I can move the vessel along the ground. But I need to be able to rise and lower. So I will try the hover

It seems I can't dissuade you from "adjusting lat and long" no matter how hard I try :lol: Which is a pity, since it sounds like a cool project.

#### gattispilot

So if I don't use the lat and long use thrust to move?

I just don't think I can get smooth movement using rcs,....

Let me put together a test setup and see.

#### martins

##### Orbiter Founder
Orbiter Founder
So if I don't use the lat and long use thrust to move?
Yes. Remember that Orbiter is a Newtonian simulator (at least that's what it says on the Wikipedia page. ) In practical terms, this means that you provide the forces, and let Orbiter do the rest (the integration of the state vectors.). So the position is an output, not an input.

I just don't think I can get smooth movement using rcs,....
Why not? And in any case, does the drone actually have an RCS system? Seems like a strange design. Surely, these things move about by tilting, so that the rotors provide a horizontal force component. Why not simulate that?

#### gattispilot

So the rotors do not tilt. I imagine it is a system that adjusts speeds of the 8 blades

Not sure how to make an autopilot to regulate the lift forces of the blades.

Rcs with no exhaust for movements

#### martins

##### Orbiter Founder
Orbiter Founder
So the rotors do not tilt. I imagine it is a system that adjusts speeds of the 8 blades
You misunderstood. I am not talking about the individual rotors tilting, but the entire drone. Just like it's shown in the animation you posted. In the last few seconds of the clip it tilts forward to get a forward velocity component - just like any standard drone or helicopter operates.

You simply implement this by a thrust differential between the fore and aft rotors. Same to generate a horizontal force vector in any other direction. Don't use RCS for this. Attitude control via differential thrust vectors is already implemented in the DG, so you can adapt this. But don't just copy it, since the DG uses hover thrusters, not rotors. You don't want your drone to operate in a vacuum.

Rotating the drone around its vertical axis can be done by a thrust differential between the two opposite rotor pairs, as I suggested a few posts back. You just have to calculate the resulting torque from the rotor spin differentials.

That should give you pretty much everything you need to implement a complete control system.

#### gattispilot

Thanks. I looked at the DG.
Code:
// AAP.h
// Atmospheric autopilot
//
// Notes:
// The atmospheric autopilot provides functions for altitude,
// The autopilot drives the aerodynamic control surfaces, but
// not the RCS thrusters. It works only at sufficient
// atmospheric pressure.
// The actual autopilot algorithms are implemented as scripts
// (Script/DG/aap.lua). This class simply provides the user
// interface to the script functions.

I think a lot of it dealt with the display. Not sure what I would need since no cockpit

So basically have 4 thrust (2 front and 2 rear) and the AP would change the thrust depending on what the pilot wanted it to do.

#### martins

##### Orbiter Founder
Orbiter Founder
I was more thinking about the implementation of the hover attitude control system. Look at HoverSubsys.{h,cpp}. Check out the HoverAttitudeComponent class (for attitude control), in particular the TrackHoverAtt method which implements the attitude feedback loop. And the HoverHoldComponent class for altitude and vertical speed control. There the HoverHoldVspd method implements the vertical speed hold feedback loop. Note that the altitude hold mode is not implemented in that class but simply calls the API SetHoverHoldAltitude method. But once you understand the vspeed hold control loop you should be able to infer the altitude hold mode.

So basically have 4 thrust (2 front and 2 rear) and the AP would change the thrust depending on what the pilot wanted it to do.

Precisely.

#### gattispilot

Thanks.
So I looked at this:
Code:
void HoverAttitudeComponent::TrackHoverAtt ()
So create 4 hover thruster where the rotor are?
I think I can remove the panel stuff as no cockpit?

#### martins

##### Orbiter Founder
Orbiter Founder
Thanks.
So I looked at this:
Code:
void HoverAttitudeComponent::TrackHoverAtt ()
So create 4 hover thruster where the rotor are?
Yes. Either that, or just apply custom forces at those points. Custom forces might be better, since Orbiter won't apply pressure-dependent ISP variations to those, which are not applicable to your application. Instead, you will have to compute and apply thrust variations specific to your rotor engines. In the first instance you could make the generated thrust proportional to RPM and atmospheric density. The relative wind incident on the rotors will also have an effect (the rotors will generate less lift if they are already moving upwards through the atmosphere), but this could initially be neglected as a second-order effect.
I think I can remove the panel stuff as no cockpit?
Yes.

#### gattispilot

So something like force 1 at (1.5,1,1) and direction vector (0,1,0) x-value force?
And do the same for the other ones.

RPM would equal variable thrust level?

#### martins

##### Orbiter Founder
Orbiter Founder
Yes. The logic here is as follows:

- first let the autopilot compute the forces required to achieve a target state
- then compute the RPM settings required to generate those forces, given the current flight environment (atmospheric density, etc.)

Of course not all target states are within the flight envelope. If you command a target altitude of 100km, then the required RPM will at some point exceed the engine specs, which gives you the altitude limit of your vessel.

#### gattispilot

Thanks. When I get home I will look at the code for hoverAP.

For sure I will need the Hover AP code not sure what else?

---------- Post added 07-31-19 at 07:10 AM ---------- Previous post was 07-30-19 at 10:39 AM ----------

Thanks. So started working on it as adding hover and moving lat and long seem to ctd.

So In my solution I added HoverSys and SubSys and removed any VC, panel, elements mention. Then changed DeltaGlider to the name of the craft DragonflyTitan.

I started to compile and only 233 errors

So does that sound right as far as the changes. I need to go back and see where the errors occurred.

#### martins

##### Orbiter Founder
Orbiter Founder
So does that sound right as far as the changes. I need to go back and see where the errors occurred.

It's not a good idea to just copy a bit of code into your project and hoping for the best. Do you know what the code does? And how it fits into your design concept of the flight control system?

I wouldn't bother trying to fix the errors. If you copied the entire hover subsystem then there will be so many DG specific references that it would be easier to write the entire thing from scratch. Even if you manage to patch up the code to the point where it compiles there is no guarantee that it does what you need.

So in summary: Make sure you understand the algorithm behind the code, and then copy that algorithm instead of the code.

#### gattispilot

Thanks. I will re-look at the code. Not sure what the subsystem code does though?

Replies
1
Views
313
Replies
2
Views
481
Replies
8
Views
1K
Replies
15
Views
393