New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calculate offset for any track #3

Closed
zwn opened this Issue Nov 18, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@zwn
Member

zwn commented Nov 18, 2016

In #1 we have a working demo for espie track with hard coded offset. When a track is loaded, it has 0,0 at the start line. However, when Speed Dreams loads a track, it offsets its coordinates so that all of them are positive. The issue is further complicated by the fact, that tracks loaded by Speed Dreams are split to subsegments as defined in the track xml file (usually max len 10m).

  1. One way to deal with this could be to use custom compiled Speed Dreams where this offseting is disabled. That would mean the 0,0 would be at the start line (actually it would be the left hand corner of the start line).

  2. Another way to deal with it could be to replicate the behavior in the python loader.

  3. Yet another way could be to load the module trackv1 from Speed Dreams into python with cffi and use their loader directly.

I am somewhat inclined to go with option 1. There is already a manual step of unziping the roborace stuff into the installation so including the exe would be no big deal.

@zwn zwn added the help wanted label Nov 20, 2016

@m3d

This comment has been minimized.

Member

m3d commented Nov 20, 2016

I would like to try to avoid custom compiled Speed Dreams executable and replace the installation. In particular I am not sure if positive coordinates are expected in "track overview" with positions of all cars??

My preference is currently (2).

@zwn

This comment has been minimized.

Member

zwn commented Nov 20, 2016

Actually, I am most inclined to (4) the adjustment could be done inside the UDP driver dll. The best would be to push it upstream to vadim's repo.

So my preference is (4) since I think it is going to be the least amount of work and it has very high likelihood of delivering what we want. I am afraid (2) is the opposite - lots of work, low likelihood.

@m3d

This comment has been minimized.

Member

m3d commented Nov 21, 2016

OK, I agree with (4) too. The best would be (0,0,0) in the middle of the start line.

@zwn zwn self-assigned this Nov 21, 2016

@zwn zwn removed the help wanted label Nov 21, 2016

@zwn

This comment has been minimized.

Member

zwn commented Nov 22, 2016

The segment after start line is flagged with TR_START in tTrackSeg::raceInfo. The driver gets pointer to tTrack where this segment can be found. It is most likely going to be the first one. Ok, maybe not:

    if (curSeg->lgfromstart < 50.0) {
        curSeg->raceInfo |= TR_START;

So all segment closer to start line have TR_START set. Let's use lgfromstart and find where it is zero. This is the resulting position of the start line in espie circuit:

00:00:30.557 Default  Info    898.679504 773.445862 17.867144
00:00:31.063 Default  Info    898.679504 760.445862 17.867144

That somewhat corresponds to

    offset = 873.676+30, 764.784

in demo.py so I am on right track so to speak 😄.

@zwn

This comment has been minimized.

Member

zwn commented Nov 22, 2016

The final offset for espie circuit is 898.679504 766.945862 17.867144. Let me know if this seems wrong for any reason.

@m3d m3d closed this in 9f993f0 Nov 23, 2016

m3d added a commit that referenced this issue Nov 23, 2016

Merge pull request #17 from robotika/offset
Remove offset, fix #3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment