Coders Strike Back: Your ideas!

So I empirically found that -(orth_speed^2)/(d) was preventing my pods from turning around checkpoints. And the taylor expand was a “proof” I found later on to convince myself that this was optimal. For example I had -orth_speed^2 for a while during the contest but looking at alot of replays it seemed like it needed a /d. For me the taylor expand thing made sense of my heuristic. Hoping it’s clearer for you.

Yes, but isn’t the y^2/d you found only relevant in the neighborhood of 0 ?

Yeah it’s an approximation but I believe I tried afterwards to replace that first term by the full series so sqrt(d^2+v_ortho^2)-sqrt(d^2) and it worked just as well.

Ok thank you I understand now

How do I get next_next_checkpoint coordinates?

Before Gold league, you have only 2 options. The easiest is to wait until you pass them the first time and then remember them on the next lap. The other is to memorize all the maps and hardcode the bot to recognize which one you’re on when the race starts.

Once you make it to Gold league, the checkpoints are provided to you when the race starts.

Thanks a lot. I’ve tried the 1st method and it got me on the 15th place in silver. Since then it is just impossible for me to improve anything. This is my code:

Any tips?

<Mod edit: don’t post the full code, please.>

Think drift racing. Instead of slowing down when you get near the checkpoint, start turning towards the next-next checkpoint. If you don’t know where it is, take an educated guess. Only slow down if the next-next is behind you.

Thanks a lot.

Tried something like this to make turn radius bigger still shieeet… :confused:

<Mod edit: Don’t post the full code, please. Instead, just post the code you’re having the problems with. Like so:>

if new_index>(len(czekpoints)-1) and next_checkpoint_x<8000 and next_checkpoint_y<4500 and next_checkpoint_dist>2500:
    next_checkpoint_x=next_checkpoint_x+800
    next_checkpoint_y=next_checkpoint_y+800
elif new_index>(len(czekpoints)-1) and next_checkpoint_x>8000 and next_checkpoint_y<4500 and next_checkpoint_dist>2500:
    next_checkpoint_x=next_checkpoint_x-900
    next_checkpoint_y=next_checkpoint_y+800
elif new_index>(len(czekpoints)-1) and next_checkpoint_x<8000 and next_checkpoint_y>4500 and next_checkpoint_dist>2500:
    next_checkpoint_x=next_checkpoint_x-900
    next_checkpoint_y=next_checkpoint_y-800
elif new_index>(len(czekpoints)-1) and next_checkpoint_x>8000 and next_checkpoint_y>4500 and next_checkpoint_dist>2500:
    next_checkpoint_x=next_checkpoint_x+900
    next_checkpoint_y=next_checkpoint_y-800

Rather than a hard-coded offset to the target, maybe you could link the offset to your current speed? That would take a lot of other factors into account.

1 Like

i don’t get any of the code so i will need a lot of help with variables and postioning

I think that you are mixing trajectory plan and the actual control logic.
If you plan a bezier curve and point your pod towards the next point you will never be able to follow the trajectory because of the physics of the problem. You don’t compensate for the drift

What I was actually trying to do is :

  • compute a Bezier curve that starts on my pod and ends on the next checkpoint
  • compute the derivative at t=0, that would be the speed vector that I want my pod to have
  • compute the necessary acceleration at t=0 that would give me this speed on the next turn,
    But as you see there is an issue as I my pod would have the desired speed vector one turn too late. Besides, given the constraints it is not always possible to achieve the desired acceleration.

So yeah, my trajectory plan was Bezier curve, but I did not get the control logic right