Vessel Mars 2020 Rover and Mars Helicopter Scout

[MarkWatney2015]

So with Brian's help we have launch:

The trick is going to be getting the skycrane/rover to the surface

Can this be applied to your Curiosity add-on as well?

 

[gattispilot]

yes. Basically the same

 

[MarkWatney2015]

Mars 2020 launches today at 11:50 UTC!

 

[emin2004]

Successful Launch

Perseverance Rover have Successfully Launched and now en-route to mars

 

[gattispilot]

So I am stumped. I keeping getting ctd. I have trying running the debugger and all I get is stuff not loaded. It seems to be related on the load and save state.

Unhandled exception at 0x773B20C0 (ntdll.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x0000003C. occurred

 

[gattispilot]

So I tried 2010 orbiter but it ctd. Tried debugging and it gives this:
Exception thrown at 0x773F7389 (ntdll.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000.
So not sure what to do next

 

[kuddel]

0xC0000005: Access violation reading location 0x00000000.

Usually when an exception is thrown in Orbiter core, the call-stack might not be correct anymore, but in general this kind of exception means:
You have given a function a NULL-pointer ( reading location 0x00000000), wich is not handled there.
So the root-cause is any function-call with no good pointers provided.

If you are lucky, the call-stack is still valid and you can "step back" through the stack and identify where the null-pointer was given.
Like:
> FunctionX [@Orbiter.exe] (where the exception is thrown) was called by
>> FunctionY [@YourModule] ...that called FunctionX ...
>>> FunctionZ [@YourModule] ...that called FunctionY ...
..etc. pp.

The art of debugging this is: Find out what function call was bad!
If the call-stack is not valid, you can only break at "strategic" points in your modules code and step through until you get a feeling for when the exception usually happens.
If the CTD happens after a specific key-press for example, start at the keyboard handling methods.
If it happens right after startup, start at the c'tor.
...it's a process of small steps until you get the root-cause.

 

[gattispilot]

It starts at start up. But I have gutted it and slowly adding things back in. Working on a 2010 version and then a 2016.

---------- Post added 08-04-20 at 04:36 AM ---------- Previous post was 08-03-20 at 04:04 PM ----------

So I have a 2010 version that works good.

So I used it for a model for the 2016.

So now the issue is moving it.

so if I move it with the scn editor I get this:

rover:MARSROVER2020new
  STATUS Landed Mars
  POS 77.5792890 18.3776370
  HEADING 73.74
  ALT 1.#QO
  AROT 65.647 73.042 135.587
  AFCMODE 7
  NAVFREQ 0 0
  XPDR 0

Notice the ALT

double ro = Passo;
	TOUCHDOWNVTX td[4];

	double x_target = -0.5;
	double stiffness = (-1) * (MASS * 9.80655) / (3 * x_target);
	double damping = 0.9 * (2 * sqrt(MASS * stiffness));
	for (int i = 0; i < 4; i++)
	{

		td[i].damping = damping;
		td[i].mu = 3;
		td[i].mu_lng = 3;
		td[i].stiffness = stiffness;
	}
	td[0].pos.x = cos(30 * RAD) * ro;
	td[0].pos.y = -Height_From_Ground;
	td[0].pos.z = -sin(30 * RAD) * ro;
	td[1].pos.x = 0;
	td[1].pos.y = -Height_From_Ground;
	td[1].pos.z = 1 * ro;
	td[2].pos.x = -cos(30 * RAD) * ro;
	td[2].pos.y = -Height_From_Ground;
	td[2].pos.z = -sin(30 * RAD) * ro;
	td[3].pos.x = 0;
	td[3].pos.y = 15 * ro;
	td[3].pos.z = 0;


	SetTouchdownPoints(td, 4);

---------- Post added at 09:25 PM ---------- Previous post was at 04:36 AM ----------

So when I run this in 2016 I get a ctd on start. I start a debug attached to the process orbiter:
this is what I get in the call stack

 

[kuddel]

The altitude is showing a NaN rsp. QNaN ("not a numbe"r rsp. "quiet NaN")

"1.#QO" is "1.#QNAN" after "rounding" for 3 places after the decimal. The N rounds to an O as 'A' >= '5' and 'N' + 1 == 'O'.

This is similarly why your debugger shows "1.#QNAN00", as it prints with 7 places and adds padding zeros to the end.

In some of your calculations you've created a NaN (either the memory only contained 0xFFFFFFF's) or by an invalid mathematical operation:

The NaN values are used to identify undefined or non-representable values for floating-point elements, such as the square root of negative numbers or the result of 0/0.

---------- Post added at 22:23 ---------- Previous post was at 22:19 ----------

And for your call-stack: As I said, the point at which the exception is thrown is already too late and the call-stack is not accurate anymore. You are experience a stack-overflow!
You can only place breakpoints at strategic points and try to divide and conquer until you are left with only one singe statement that is wrong.

 

[gattispilot]

Thanks. So I don't think I placed any beak points. So I guess I should try to put on in. Any suggestions where to start?

---------- Post added 08-07-20 at 06:50 AM ---------- Previous post was 08-06-20 at 03:33 PM ----------

So I set up break points

and ran it. odd it it didn't hit any breaks and loaded.

I exited and ran again and got this:

rover:MARSROVER2020new
STATUS Landed Mars
POS 77.5792890 18.3776270
HEADING 73.74
ALT 0.001
AROT 66.641 73.319 135.757
AFCMODE 7
NAVFREQ 0 0
XPDR 0
ARM0 0.0000
ARM1 0.4631
ARM2 0.0970
ARM3 0.6846
ARM4 0.0000
HGA3 0.0000
HGA1 0.0000
HGA2 0.0000
CAMY 0.4870
CAMZ 0.3317
CAMMAST 1.0000
MIDDLESHAFT 0.0000
REARSHAFT 0.0000
FRONTSHAFT 0.0000
FRONTRIGHTWHEEL 0.0000
FRONTLEFTWHEEL 0.0000
END

 

[kuddel]

Hi,

The 1st breakpoint will not be hit because it is not an actual statement that is executed at runtime (it's just a definition at compile time).
The 2nd breakpoint will also not be hit because it is a data structure (definition) and -again- not an instruction to be executed at runtime.
The 3rd breakpoint is not hit, because you've placed it at the declaration of the method.

If you move the 3rd breakpoint two lines down (line 50) it will be on an actual statement (an assignment in this case - HGA_status = DOOR_UP;, which will be executed at runtime*)
And as this is the constructor of your MSL_ROVER class (thus creating an instance of that), you can step over each and every assignment, method call, etc. pp.

Some methods will be called from the Orbiter core as "callbacks", placing a breakpoint at the first statement in such a function will trigger the break as soon as some code (from Orbiter-core or Graphic-Client or OS-Keyboard handling...) calls this method.

Try to get a feeling for where you can place breakpoints. Then step some lines ([F10] step-over).
After that you might like to step into some of you methods ([F11] step-into).
If the method you like to step into is not from your code, something like your 2nd sceen might appear as that method has no debug-information available.
In that case you could step into it at Assemby-Level, but that's a whole new dimension and unless you know x86 assembly and the connection between C-Language calls to them, you should at first keep away from that route.

If you however find, that you would like to look into such a method, this is where you definitely should carefully read the API documentation of that method and make sure that you
a) understand what it expects and
b) provide it with the expected parameters!

So, place some breakpoints, see when which one gets triggered, remove (or disable) those that do not lead directly to a crash until you're left with an idea what leads to the issue.

As said, it's not a "one click and you're done" job.
Be patient persistent.

/Kuddel

[*] at least in the Debug build, in a Release build this assignment might get optimized out.

 

[gattispilot]

Thanks. Move the break points. And solved it. It was the copter stored mesh.

So may need to make 2 versions. An d3d9 and normal graphics. The reason is the animations seem to be move at different speeds

 

[kuddel]

Thanks. Move the break points. And solved it. It was the copter stored mesh.

:thumbup:

So may need to make 2 versions. An d3d9 and normal graphics. The reason is the animations seem to be move at different speeds

Shouldn't be! I am no expert in animation definitions, but I bet that they are pretty similar for inline- and external- graphic-clients.
Especially when it comes to animation speed, there is no difference to be expected.
I would try to find where the difference might come from. I'll bet there is one more error in the code that is just "presented" differently in inline vs. external GC.

Why not share the code (github maybe)? Others might be able to help. There is no reason to hide code[*]!



[*] ...and don't get the feeling that your code is not good enough. It might not be perfect (which no code is), but you can only improve when you know what could be better.

 

[gattispilot]

Well for instance on my sf I move an attachment that moves the guy. It normal graphics he moves faster than in D3D9

 

[kuddel]

It normal graphics he moves faster than in D3D9

That's the observation. Now all we need is the reason.
I would definitely go the way of publishing the source code, as this multiplies the chances of people (see, plural ) finding flaws.:thumbup:

Just by reporting observations, it makes it orders of magnitude more difficult to assist / help compared to the open source approach.
Even posting a ZIP with the source-code will increase chances a lot!

 

[gattispilot]

Thanks. Here is what I have for the rover and code.
https://drive.google.com/file/d/1biwq0mTRVl4cqlx5OQd75BJIMp6SFS6h/view?usp=sharing

might take some time for me to set up a github

 

[kuddel]

Thanks, you don't have any .sln and .vcxproj files for me? Your resource.h would also be nice.

---------- Post added at 21:14 ---------- Previous post was at 21:08 ----------

...some resources are also missing (icon1.ico, down.ico, ico00001.ico, ico00002.ico, ico00003.ico, ico00004.ico, Bitmaps\tkbk_label.bmp)

Nevermind, figured out a way to get it compiling.

 

[emin2004]

i'm using a 2010 version of Orbiter because the high texture planet addon for Orbiter 2016 was borked

is there a 2010 version for That Perseverance Rover & Ingenuity Helicopter?

 

[kuddel]

I can not find any difference in the animation speeds.
Regardless whether I run it with D3D9Client or the inline client.

Attached you'll find my (release)build including any changes I did.
I only changed the one conversion to int in line 265 to get rid of the warning,

TurnANGLE = int(TURN_proc * 360);

but that definitely does not change anything regarding animations, as the assigned variable (TurnANGLE) is only used in HUD display code.


To exclude any obscure build-process differences I also added my solution and project files and all the added resources I had to add.

 

[gattispilot]

Thanks. So did the rover move at different speeds based on the graphics?