Could you do Odometry in Vexcode V5 Blocks

Just an thought, Can you make do Odometry code in vex code V5 Blocks. I know it’s possible in Vexcode V5 Pro. But could you do make an Odometry Code in Vexcode V5 Blocks? How would that be possible?

The simple answer is no sadly :frowning:

Thanks for the answer.

1 Like

Actually, it is possible to track your robot’s motion via odometry and program it in blocks. But block’s built-in refresh rate makes it not optimal for use with motion planning algorithms.


honestly I’m impressed and terrified


can you please tell me what part finds the x,y value and what the refresh rate of blocks is. i want to try odom.

I think @djavaisadog could help you with that, as he is the creator of that code…

thank you. that helps

or honestly, the better solution would be to use text instead of blocks. although blocks may seem easier at the start, text is much better on the long term


I replicated this code and it does not work. It displays a message saying “error generating code” :frowning:

I don’t understand this statement - Blocks is just a GUI for generating C++ code behind the scenes - the same code used by VEXcode Pro V5. What “built-in” refresh rate are you referring to?


I think blocks automatically adds a wait to repeat and forever blocks, but I could be wrong.

You’re right, it adds a 5ms wait - but that’s still less time than the polling rate of the motor encoders - and is generally good practice when running multiple threads.


Is there also a added 5ms wait to the loops in V5 pro?

I was just referring to what the OP on discord has said (and why they advised against using blocks for anything odometry-related).

Correct me if I am wrong, but isn’t all of the stuff on the left useless? I never saw factorials in the rest of the code.

No, it’s only the blocks code generator that adds the additional wait, it’s to stop issues caused by loops that have no wait (or any other API calls) at all. When using C++ you have to deal with that on your own, python is a whole other story.


I think the OP was using some more complicated math (Taylor Series) for trig functions (I’m not sure if they knew there were trig functions in blocks yet).

1 Like

OMG 5ms, what’s up with that? That’s a lifetime with code like this. Or code in general. What a disaster mess, why would anyone use blocks for anything. With that huge overhead I’m suprised that robots programed with blocks don’t just twitch across the field.

/scarcam roboteers

This reminds me of the initial battles with Java vs C or C++ “How can an interpreted language be fast enough to do anything”. And here we are today with millions of enterprise systems running on Java.

Edited to add that in this thread,

towards the end of it is a post about implementation in Scratch, and a comment around delays in the calc loop that 7ms was a good number for the particular robot they were working on.