Add python binding for the track preprocessor

[kktse]

From what I can tell, this involves exposing an interface to class Circuit_preprocessor in fastestlapc.h, and then adding the new methods to the Python bindings.

It looks like this PR shows an example of how to interact with the circuit preprocessor class using .kml files.

    Xml_document coord_left_kml("./database/tracks/lfg/LFG_left.kml", true);
    Xml_document coord_right_kml("./database/tracks/lfg/LFG_right.kml", true);

    Circuit_preprocessor circuit(coord_left_kml, coord_right_kml, {}, 500);

    std::unique_ptr<Xml_document> xml = circuit.xml();
    xml->save("./database/tracks/lfg/lfg_discrete.xml");

Any feedback on this approach?

[kktse]

I put up a branch but have a discrepancy between calling this method from Python vs. from a compiled C executable. Both seem to solve ok but calling from Python results in the XML file containing no data. I am not quite sure what is going on :confused: I'd be interested if this is a problem on other machines, or any ideas how to work around this.

<circuit format="discrete" type="closed">
    <header>
        <!--THERE ARE SUPPOSED TO BE VALUES HERE-->
        <track_length units="m"></track_length>
        <L2_error_left></L2_error_left>
        <L2_error_right></L2_error_right>
        <max_error_left></max_error_left>
        <max_error_right></max_error_right>
    </header>
...

[juanmanzanero]

Hello Kelvin!

Correct, this is what this PR is about. As you did, to pass the KML files as inputs and generate a track. More options would be desired, such as adaption (we can generate tracks controlling the spacing between points, e.g. to concentrate points in tight corners), but what you did is a very good starting point.

It is quite surprising that these fields are left empty. These are errors indicators so that you can quickly see if it was successful. Also, it is indeed surprising that from python you get different behaviours as from a compiled C++ test. As soon as I have time I will take a look.

Thank you!

[kktse]

I pushed my some test scripts in another branch to have a reference of how I am testing the changes

test.c - It took some messing around to compile this to point to the shared library. If I recall, it involved updating LD_LIBRARY_PATH and compiling with -L and -l flags pointing to the header/shared lib.

#include <stdio.h>
#include "fastestlapc.h"

int main(void)
{
    int i;
    printf("Hello world!\n");

    const char *left = "/home/kktse/src/fastest-lap/database/tracks/lfg/LFG_Left.kml";
    const char *right = "/home/kktse/src/fastest-lap/database/tracks/lfg/LFG_Right.kml";
    const char *out = "/home/kktse/src/fastest-lap/database/tracks/lfg/mytrack.xml";

    circuit_from_kml(left, right, 500, out);
}

test.py

# Put parent folder in the pythonpath
import sys,os,inspect

import matplotlib.pyplot as plt
sys.path.append("../../")
import fastest_lap
from fastest_lap import KMH

# In[2]:

# Load vehicle
vehicle=fastest_lap.load_vehicle("car","limebeer-2014-f1","/home/kktse/src/fastest-lap/database/vehicles/f1/limebeer-2014-f1.xml");

# In[ ]:

fastest_lap.circuit_from_kml(
    "/home/kktse/src/fastest-lap/database/tracks/lfg/LFG_Left.kml",
    "/home/kktse/src/fastest-lap/database/tracks/lfg/LFG_Right.kml",
    500,
    "/home/kktse/src/fastest-lap/database/tracks/lfg/mytrack.xml"
)

My python version is 3.10.3 on Arch Linux 64bit

[juanmanzanero]

Hello @kktse . Sorry, I am quite busy these days and I will need some time to address your comment. Sorry again!

[juanmanzanero]

Hello @kktse ! I am back at maximum power. I have prepared this branch so that we can iterate and work together. Can you please pull request there?

[juanmanzanero]

Hello, I have just added a version of the circuit preprocessor that prints the XML file perfectly and does other fancy stuff.

An example can be found here

Thanks everyone, Cheers!

[kktse]

I did some testing and interestingly, the same XML problem occurs with your new changes on my machine. However, the track data is persisted in the vector table so it's computing. My gut feeling is this is related with TinyXML. It is something I might ponder a bit more and do additional testing to understand what's happening, and see if there is a workaround. Thanks again, these changes really help the usability of the tool!

[juanmanzanero]

Huh, makes sense. I don't know why I started using TinyXML, I will migrate to the standard libxml when I have the time. Thanks to you and your usual top class contributions! Sorry I had to take over but I just had some free time and wanted to address it.