SDK Question Altitude in VS2

[kuddel]

Could it be that a configuration file for the quadcopter (class) is missing?

000000.000: >>> ERROR: No vessel class configuration file found for:
000000.000: ============================ ERROR: ===========================
000000.000: Quadcopter
000000.000: [Vessel::OpenConfigFile | ..\Vessel.cpp | 243]
000000.000: ===============================================================
000000.000: >>> TERMINATING <<<

---------- Post added at 21:15 ---------- Previous post was at 21:05 ----------

For the provided quadcopter.dll the Mesh and Config can be copied from the sources:

xcopy .\Orbitersdk\samples\Vessel\Quadcopter\Config\Quadcopter.cfg .\Config\Vessels\Quadcopter.cfg
xcopy .\Orbitersdk\samples\Vessel\Quadcopter\Meshes\quadcopter.msh .\Meshes\Quadcopter\quadcopter.msh

...so no immediate need for an update of the repository.

 

[martins]

The missing mesh and config files should be fixed in the latest beta. It also adds a Lua interface for accessing some of the autopilot modes. No documentation yet, so you'll have to check the code to see what is available and how to call it.

 

[martins]

Not having access to a real-life drone myself, I have a question about how the controls generally work. Specifically, are the pitch and roll controls vessel-relative (e.g. pushing the pitch control stick pitches the the drone down with respect to its own forward direction) or operator-relative (e.g. pushing the pitch controller pitches the drone away from you, no matter its current heading).

I can see that the latter mode could be useful when the drone is too far away to see its orientation, where pulling the stick will always bring it back towards you. The first mode would obviously be reasonable if you have a live feed from the onboard camera, and you can use the controller as a virtual cockpit.

 

[Face]

Not having access to a real-life drone myself, I have a question about how the controls generally work. Specifically, are the pitch and roll controls vessel-relative (e.g. pushing the pitch control stick pitches the the drone down with respect to its own forward direction) or operator-relative (e.g. pushing the pitch controller pitches the drone away from you, no matter its current heading).

Most drones I know about use the vessel-relative mode, but there are many consumer-drones (low price, low weight, cam) that also implement special modes for e.g. selfies that come close to your described operator-relative mode. It's more of a PR gag, though.

 

[kuddel]

It also adds a Lua interface for accessing some of the autopilot modes. No documentation yet, so you'll have to check the code to see what is available and how to call it.

@martins:
As you mention Lua documentation:
Many stock vessel code has Lua interfaces, that need documentation.
I volunteer to add them as far as I can do it.
Do you have any preferences on how I can provide them?
- A dedicated (.lua) file containing only doc, or
- Inline documentation in code (header or source), or
- any other way?

It should mainly make your generation process as seamless as possible,
...so make a wish :lol:

 

[martins]

Thanks for volunteering on writing documentation! It's much appreciated.
Maybe a separate .lua document containing only the documentation in ldoc format would be easiest, since I could then just automatically run ldoc over it as part of the build process. The only disadvantage is that for any changes to the interface one would have to remember to also update the documentation, but hopefully that won't happen too often.

 

[kuddel]

Hi Martin,

find attached a proposal for the file-/directory layout for the samples Lua-API-documentation files.
The actual documentation content is not yet full-blown, so no need to look deep into it.

I just wanted you to ask if you could "flesh out" one of that files with the necessary meta data, that might be needed to fit your documentation process.
(DeltaGlider/Doc.lua for example).

I mean: In the top section I guess some @section or @class or @chapter might be needed...

So if you could edit and post just one to fit the process I'll take that as a template.

Regards,
Kuddel

Edit: Oh, and if the layout/names doesn't fit, just drop a note.
Edit2 (2019-09-03): I've added a "LDoc-Syntax corrected" version (I don't know who already downloaded the first pack; which was useless, sorry).

 

[gattispilot]

I haven't had a chance to look at the code. But would it work for the marscopter? Where it has 2 sets of blades on top on each other?

 

[martins]

I haven't had a chance to look at the code. But would it work for the marscopter? Where it has 2 sets of blades on top on each other?

The concept is the same surely. You need to calculate the thrust force as a function of RPM anyway, so you factor the rotor geometry in there. Obviously, arranging two rotors on top of each other provides less than twice the thrust of a single rotor. Also, if the rotors have opposite spin directions (do they?) then you need to figure out how to impart the torque used to rotate the vessel around its vertical axis. It will involve RPM differentials between the rotors in the vertical stacks.

Any reason for the choice of this particular configuration? I would have thought a conventional octocopter configuration would be more efficient than this doubled-up quadcopter setup, and probably at least as failure-tolerant. Is it due to size constraints of the payload package?

Btw. marscopter ?!? I thought this was for use on Titan. Not sure you would get this thing to take off on Mars.

 

[gattispilot]

here is the MArs copter:
https://www.nasa.gov/feature/jpl/nasas-mars-helicopter-attached-to-mars-2020-rover

 

[martins]

Fair enough, but this appears to be no quadcopter at all, but a more conventional twin-rotor helicopter. So the control mechanisms coded by my quadcopter sample won't help you much there.

 

[gattispilot]

Sounds good. Hope to get a chance to look it and recode the quad

 

[kuddel]

@martins: Just in case you've missed my Lua documentation proposals, they're here

Do you have any markup enabled in your generation, or is it fine to use HTML?
I also noticed that Math formulas are not rendered nicely (see "vessel:get_angularmoment()" from the main lua cpp files for example), is there a plugin/addon that render them more nicely?

HTML5 <math> might work, but I haven't tried if it compiles well into .chm
https://developer.mozilla.org/en-US/docs/Web/MathML/Element/math

 

[martins]

Sorry for the late response. I've been living without internet at home for the last week, and just got reconnected today. It's frightening when you realise how much you rely on it just to do something trivial like looking up ldoc format documentation :huh:

Anyway, back in business. I'll have a look at your templates and will prepare the Deltaglider one with everything required to compile it in my build system. Might not get round to it before the weekend though.

I am not sure if it would be worth trying to merge the vessel documentations into the global Lua interface documentation or just leave them as separate files. That would simplify things, but might make it more difficult for users to access the info from within the running simulation.

Thanks for pointing me to the problem with the math format. So ldoc definitely doesn't have the same functionality as doxygen - pity. I'll look at the HTML5 option. I just wish the HTML5 guys had adapted LaTeX format instead of MathML, which I am not familiar with at all. Something new to learn.

 

[kuddel]

Take your time!

I'll also take a look around regarding the math...I think I read somewhere about a TeX -> MathML/HTML conversion tool which might make conversion easier :thumbup:

 

[martins]

Ok, I've uploaded a new commit now that incorporates the framework for the documentation of the vessel-specific Lua extensions (DeltaGlider only so far). A few things:

* After some more thought, I have changed my mind about the separate dummy Lua file for documentation. I have added the documentation now directly into the C++ implementation (DGLua.cpp). Since the function name needs to be added manually anyway via the @function tag, it probably doesn't matter if it is read from a Lua or a C++ file, and having the documentation next to the implementation makes it a bit easier to keep in sync and to write the documentation at the same time as the implementation. Would you agree? I hope I haven't caused too much unnecessary work with this change.

* There is now a "config.ld" in the Help subdirectory which contains the parameters for ldoc.

* ldoc is run as part of the custom build steps for the Deltaglider.hpp and DG-S.hpp files. The Lua documentation is merged into the DeltaGlider.chm and DG-S.chm files, which are accessible from within the simulation. The Lua documentation is accessed via an entry in the TOC.

* There is an additional ldoc.props property page that the Deltaglider project now uses. This allows to customise the location of the ldoc executable (by default it is assumed in the search path). I have tried to make sure that compilation doesn't fail if ldoc isn't found. In that case, a dummy page is created saying that the Lua documentation isn't available.

* I also fixed a few problems in the DeltaGlider project file. I hadn't noticed them before because I normally build the Orbitersdk samples from a global solution file within my source directory, rather than separately from the deployed Orbitersdk directory, so some of the directory macros used in the project files have different values.

Please let me know what you think, and if this structure looks sensible.

 

[kuddel]

* After some more thought, I have changed my mind about the separate dummy Lua file for documentation. I have added the documentation now directly into the C++ implementation (DGLua.cpp). Since the function name needs to be added manually anyway via the @function tag, it probably doesn't matter if it is read from a Lua or a C++ file, and having the documentation next to the implementation makes it a bit easier to keep in sync and to write the documentation at the same time as the implementation. Would you agree? I hope I haven't caused too much unnecessary work with this change.

100% agreement here :thumbup:

Please let me know what you think, and if this structure looks sensible.

I'll take a look when I find some time (expect a minor delay).
The structure should be sensible for you in the first place, so I guess it will be O.K. for me.

So I'll post a ZIP based on that revision (r90), if that's O.K.

Thanks for the work,
Kuddel

 

[kuddel]

Here we go:
Attached you'll find my changes.

• I took the liberty and added some missing documentation in lua_vessel_mtd.cpp (LuaInterpreter).
• I am a bit puzzled about how to really use 'markdown' syntax
  (is two leading spaces really the recommended way to force a line-break?!)
  And lists do not work for me as expected (I had to add those 2 trailing spaces...)
• I couldn't really find out the exact meaning of the parameters for ShuttleA:set_attoffsetmode and ShuttleA:set_atttgtframemode,
  so you might take a short look at those two as my "description" is ...obvious at best :blush:.
• In the ZIP you'll also find a (r90 based) .pach file, which you might find useful, or can be ignored if you like to work with the individual files more

Hope this helps

Edit 2019-09-16:
Grrrrr I hate it when when it happens. Always one file missing whenever you have to edit many other (project-)files, too.
Needed changes in Interpreter.h (copied to include path during build, too) were missing, so 2nd attachment should include those changes, too.

• replaced LuaDocOrbiter 2019-09-15.zip with LuaDocOrbiter 2019-09-16.zip