rubis-lab/cpsim_linux

CPSim_linux

CPSim

Fixed execution time tasks on single core PC

CPSim_MulticoreExtension

Varying execution time tasks on multi core PC

cpsim_linux's Issues

TORCS compilation error " invalid use of incomplete type ‘png_struct' "

• System: Gentoo
• GCC: 4.9.4

When trying to compile TORCS (the one recommended on the user_manual.pdf), it is very likely to encounter a compilation error with a message like:

img.cpp:101:20: error: invalid use of incomplete type ‘png_struct {aka struct png_struct_def}’

It seems that this is because the version used for TORCS assumed an older and deprecated API calls to libpng. Specifically the setjmp() function.

This can be solved by modifying the file: torcs/src/lib/tgfclient/img.cpp.

@@ -98,7 +98,7 @@ GfImgReadPng(const char *filename, int *widthp, int *heightp, float screen_gamma
                return (unsigned char *)NULL;
        }
        
-       if (setjmp(png_ptr->jmpbuf))
+       if (setjmp(png_jmpbuf(png_ptr)))

@@ -229,7 +229,7 @@ GfImgWritePng(unsigned char *img, const char *filename, int width, int height)

        
-       if (setjmp(png_ptr->jmpbuf)) {    
+       if (setjmp(png_jmpbuf(png_ptr))) {    

Car stops being driven after some predetermined amount of time

During a race after approximately 1m30s, the car seems to stop being driven by the simulator as the steering is locked and it does not continue to accelerate.

We found that this is because when computing the simulated schedule of all the task per resource (ECU) it takes x amount of time to do so. This amount of time is dependent on the hyperperiod. So, when the computed schedule runs out, a new schedule plan must be computed via the extract_schedule function. However, this takes another non-negligible x amount of time. During this time while the schedule is being re-computed the simulator cannot (and does not) communicate with TORCS hence to the user it seems as if the car was stop being driven.

We (@BaeInpyo and I) could solve this issue by increasing the hyperperiod to a large value. However, that produces another problem. Now, at the beginning of the race, precious seconds (even minutes) are lost as the simulator tries to compute the first schedule.

A better solution will allow the scheduler be re-computed without affecting the state of the race. We tried to speed up the extract_scheduler function by creating a thread per resource as it computes the new schedule (reference commit: https://github.com/BaeInpyo/CPSim_linux/commit/5beec5f9922ce3ea096280a704d2fffcd07ecbef ). However, this optimization is not enough to completely solve the problem.

We propose another solution to this problem but it requires a small modification of TORCS. The overall idea is the following: the simulator can communicate with TORCS indicating when the new schedule needs to be recomputed. TORCS will receive this information and temporarily pause the current race until the simulator indicates TORCS that the new schedule has been computed. We achieved this via shared memory.

Reference commits

• TORCS: vip7265/Torcs_src@582b39c
• Simulator: https://github.com/BaeInpyo/CPSim_linux/commit/130b7c130c1be84efbb4ba187d6a9a1b4c3d7580

This commits and other improvements will later be published for a pull request.

Problem in changing the directory structure

Camilo[@cacyss0807] (one of the students) and I found the bug that only changing eclipse/start.sh cannot locate eclipse and Simulator directories to another directory, not home directory.

This is because in Simulator/engine/real-time_simulator_basic.cpp file gets a static path of the home directory into a LOCATION variable (You can find it at line 242 and 243) which is used for loading plotting configuration files.

For the person who wants to use his or her own directory for this project (not home directory), You should change not only eclipse/start.sh file but also the code of Simulator/engine/real-time_simulator_basic.cpp file.

Camilo[@cacyss0807] will give you the way to change it.

Minus value of Final_lap_time

When the car runs with high speed (>200km/h). I am wondering why final_lap_time gets minus value.

"race start: 15.100001, end: 15.444956, cumulated_distance: 15.284203
of ECUs: 2,
lap time: -0.636000 sec,
average distance: 5.094734 m
score: -233.171371"

the score calculation seems to be unfair.

Seeing the score calc equation, the distance term could overwhelm the remained two term.

I guess that kind of situation is not intended when designing this project, so I want to ask that this equation is proper.

If It is what you already considered, I'm gonna keep going to get the highest score comfortably!

Thanks.

c.f) In the result of my design now, distance score is 10+ times larger than sum of the remained two.
and for exploiting this, it seems that we don't have to care about scheduling things in an ECU much.

(Suggestion) Way to find compile errors

In the current simulator, I cannot find the way to see compile errors of SWC codes.
Even though there are errors in the codes, it launches TORCS normally with the previous version of design.

I suggest that you add some codes to see the errors if compile errors occur.
Since this can prevent users from wasting time when they fine-tune without noticing the error (as i did...), I believe this will improve UX.

As a temporal solution, I found that we can see the errors by a 'make' command in the simulator/engine directory.

Calculating lab time has bug.

In the score board of torcs, lab time is 01:16:94, while score.txt said it is 5.78000 sec.
Reason of this is simulator reads time from lab_time.txt and it thinks race is finished when there is same variable, but simulator can writes same variable while race is processing.

Below is my lap_time.txt and distance.txt

lap_time.txt				distance.txt				Problem
Skip...					Skip...
17.500000 4.890000			17.500000 -0.143518
17.600036 4.992000			17.600036 -0.082590
17.700063 5.084000			17.700063 -0.019657
17.800000 5.192000			17.800000 0.057158
17.900047 5.278000			17.900047 0.111034
18.000070 5.374000			18.000070 0.164570
18.397092 5.780000			18.397092 0.195379			START
18.397130 5.780000			18.397130 0.195379			...
18.397157 5.780000			18.397157 0.195379			...
18.400000 5.780000			18.400000 0.195379			END
18.500000 5.872000			18.500000 0.175303
18.600156 5.992000			18.600156 0.140799
18.700000 6.084000			18.700000 0.115482
18.800077 6.192000			18.800077 0.082829
Skip...					Skip...

Therefore I think fixing real-time_simulator_basic.cpp is needed:

• change break to continue, and handle pointer when it reached to EOF.

NOTE: I'm using VMWare 12 Player and Ubuntu 14.04. This problem might be happened because of VM.

A minor bug

Examining with CPSim, I found an awkward bug but I don't know why.

Anyway I report it for future fix.

Even the simulator is stopped, the run button icon is still red square.

When I restart the SDK this disappears so i don't know the exact reason.

a difference between test prj and the provided slide.

The execution time and the period of the three other tasks which we are not allowed to modify is different.

Which one should we follow?

I guess It won't be that serious but i wanna clear it before i start.

Are we allowed to update the deadline of tasks?

I could not find any documentation regarding if it's allowed to change the deadline of tasks.

score.txt file is not generated

After I stop the simulator, I cannot find 'score.txt' in 'eclipse' directory. I did 2 other environments. But the results were same. Can I know which part I need to check for this kind of issue?

Shared memory is never removed on abnormal termination

BaeInpyo and I discover that under the current implementation shared memory for communication with TORCS is never deleted. This is because the only call to free_shared_mem is done in a correct scenario where the race is completed and the main event loop at real-time_simulator_basic is terminated.

This does not produce visible problems because as the TORCS and SIMULATOR processes die they release the shared memory but its instance remains. However, if the shared memory instance/declaration were to be changed problems could appear and would be hard to debug.

We propose a solution to this problem by releasing memory even if the simulator is terminated via a signal (abnormal termination)

The following commit can be used as reference: https://github.com/BaeInpyo/CPSim_linux/commit/50614c7dd60c19f38542f4018aadceb9c2b7ff25

Additionally, note that shared memory is deleted from both TORCS and the SIMULATOR, so in case of normal termination the shmctl function at the SIMULATOR will result in an error as this shared memory instance does not exist anymore.