So for this season, our team decided to do something different for our autonomous. Instead of hardcoding all the functions, we designed a feature in EZ-Template that records controller input every 18 ms and saves it either to an SD card or to RAM.
Then, when we press certain buttons, the replay happens, and once the match is activated it defaults to the replayed autonomous.
I know the spirit of the rules is that autonomous is supposed to be a non-driver-oriented part of the game, but I feel like replaying the functions could be smart, faster to develop, and maybe even win some points with judges if we explain it correctly.
This is not illegal per the manual. I do believe that people have tried it before with varying levels of success, but I am not a programmer and can’t advise further.
Also long as there is no controller input during the auton period there is nothing illegal about this. In my mind simply a different way of setting out autonomous routes. No different to creating a route with something like path.jerryio.com.
I have seen many people on the forum attempt this before so if I may give some advice. The main issue was usually accuracy as it relies on the same controller inputs moving to the same point every time. I never tried it, but in the my idea was to do something similar but record the position and velocity with odometery instead. Then use that to make paths to drive later.
You could record other controller inputs as normal.
This would have the same benefits as recording input. But also utilise the benefits of odometery to minimise variation on different fields.
This could be really cool. About its legality, by the letter, I would say its legal, but it could definitely be considered against the spirit of the rules. I would ask this in the Q&A, which opens tomorrow.
First of all thanks for the clarification about the legality and when we were designging this a bunch of videos showed up about how theirs didnt work and we kinda thought it wouldnt work either but we found a way to make it work really well that i havent scene people talk about much
It stems from recording the actual functions of the robot and storing it basically we don’t check the controllers input we check what is actually happening so we can perfectly replicate that every 20 or so miliseconds we run a function that records voltage and/or power of each motor and save it as a integer after that we basically see how the integer translate to actual movement and replicate that it also uses a kinda PID system thing where it measures between the amount of power stuff is getting and how much its actually using or actually moving and then corrects it so its nearly identical between the manual mode and autonmous
PS: for anyone wondering how we stored it theirs two modes one on the brains ram if their is no SD card insertedn into the slot
So this sound very cool and i am proud that you guys got this to work. Do you think you could share the actual code so we could also try. But if not that it is 100 percent fine
I think student finding a unique solution they made themselves to solve a problem is THE spirit of the game. Definitely more than using a premade blackbox library they simply fill out a template to use.
100%, your very right. When I replied, I wasn’t thinking about this, I was just reading that autonomous means no humans so it’s up to be interoperated in different ways. I also wanted to make sure the Q&A was being consulted for official rulings.
In my opinion, the VEX Community should not discourage sharing their discoveries. To innovate, you first need to be educated, and this could be something that teams could innovate on.
Don’t get me wrong, I don’t think we should force people to share their hard work. It’s completely up to them, and playing to win is a completely valid way to play the game of VEX. I just don’t believe that there should be a culture of not sharing things for fear of losing an advantage. Others have absolutely said this better than me, so I recommend looking at those posts. I truly don’t mean to come off as argumentative lol.
We probably will release it after we finish testing everything out a bit more. The only thing we’d ask is that teams don’t copy it 1:1 because our robot branding is literally all over the program lol. The boot animation, HUD, menus, logos, pretty much everything is customized to our team, so an exact copy would probably get flagged under G4d pretty fast.
We mainly want people to use it as inspiration and build their own version off the idea instead of just cloning it directly.
Thanks for the compliments. Respectfully, we’re kind of shifting toward releasing the code publicly because if other teams try to attempt this themselves, they’ll mostly be working with really old resources, and that doesn’t really promote creativity or innovation.
Also, thank you for the concern about losing an advantage. Our solution is branding our program has our branding deeply integrated into it. Our logo shows up on basically every screen, including the boot animation and the normal HUD with all the buttons and UI elements.
My team and I did this last year by utilizing key frames; we decided not to use an SD card or RAM. It worked; however, it was very sensitive. Just make sure the program is catching every movement.
i disagree with this take. op is free to share whatever they want, but they’ve already explained the core idea, the polling method, what they’re actually tracking, and how the pid loop ties it all together.
any programmer can take that and build it themselves with some effort. dropping the full code would just make it super easy to copy-paste without actually learning anything, which kinda defeats the point if the goal is helping people improve.
Additionally… if you record stick/button inputs’… that’s great. But realize that you are recording INPUTS not OUTPUTS (actual movement). They will be close but not the same due to friction, lag, etc. You need to record OUTPUTS to achieve 100% repeatable results. You must monitor the rotational encoder for this.