V5 auton selector options

Our team is considering various input options to set the “autonselector” variable in a function pointer array that callback autonomous programs.

  1. LCD - emulated buttons (we tried, and haven’t gotten this work because some other higher priority tasks with no delay - consuming all the processor resources. So the buttons don’t show up at all).
  2. Bumper sensors - 2 of them; one to goes up in the array ladder and the other down. seem to be a robust solution. downside: taking up two 3-wire ports; also requiring on-the-spot selection which could introduce error in the chaos.
  3. Jumper clip - simple/robust solution. pre-selected with no on-the-spot selection. downside: taking up as many 3-wire ports as your number of auton programs.
  4. Potentiometer - versatile but harder to setup. Only need one 3-wire port. downside: on-the-spot selection.

What is your team experience for “autonselector” input? Any other ideas besides aforementioned?

We have three autonomouss and have two limit switches. Our code goes like if ls1 is pressed {if ls2 is pressed (autonomous 1) else (autonomous 2) } else (autonomous 3). It works out fine but does take up two 3 wire ports.

The V5 system has support for multiple programs, part of last year we just had the same program but with a different auto commented out downloaded to the different slots. Its fine but a pain if you change teleop code at competition.

Also auto selection will always be “on the spot” unless you have some method of detecting where you are on the field without prior input (ultrasonic sensors or a camera). So its kinda silly to rule out an idea just because it requires some sort of setup.

Also also, why do you have loops without a delay? The sensors and motors can only update at a rate of like 20 milliseconds, so its not gaining speed from doing it.

1 Like

LCD is the most convenient IMO, since you don’t sacrifice any sensors. I did potentiometer last year and it was pretty convenient and nice, but since I’m using all of the ADI ports this year, it’s no longer an option.

If you plan to use the LCD and emulated buttons (presumably in PROS), you can create some auton selection logic quite easily using the lcd callbacks.
If your LCD task is not getting enough task time, consider reworking your code, so it does, at least in pre-auton state.
Side Note: For the most part, you should be using a delay in every task, so one task doesn’t hog all the processing time. Remember that tasks, aren’t all run at the same time. It uses a scheduler which swaps tasks in and out (based on priority), and only one task can be running at one time.

1 Like

Can you explain what tasks are? I hear that word get thrown around a lot and don’t know what exactly people are referring to.

ahh, I think this problem is not what you think it is. there’s a weird interaction glitch happening right now where the LVGL buffer isn’t flushed until things update. so you can either have it force a screen redraw (if there is even a function to do this-- i can’t remember off the top of my head) in initialize or somewhere, or you can try the workaround that involves setting the brain’s screen to “inverted” in the settings.

if it is actually some other higher priority tasks with no delay starving the display update daemon, then, uh, you might want to fix those.


there’s a basic overview on our site.

1 Like

So basically, a task allows you to run multiple functions at once? Is there any consequence to misusing tasks?

1 Like

Well that depends on what you mean here by “misusing.” The post I linked to on our site discusses one type of abuse…

1 Like

Thanks for the tip! Will try the work around.

Happy cake day hotel!

What are other abuses and can they have fatal consequences (I’m mainly worried about consuming all processor resources – can that have any unintentional damage on anything else? My friend told me misusing PROS can damage hardware – is that possible and how can I avoid it?)

you’re very unlikely to damage hardware just by overusing tasks-- at least you won’t be doing any physical damage to the CPU… the only hardware damage I think it’s even worth considering would come from situations in which you lose control of your robot, but those can happen with any platform, regardless of whether you’re using tasks.

as far as consuming all processor resources, well, i don’t think that’s quite as big of a deal as you seem to think it is. first of all, you’d have to be doing really badly in order to use all the CPUs resources. PROS uses FreeRTOS configured as a priority-based preemptive scheduler, so unless you’re screwing around and making absurdly high priority tasks, you’d basically only be starving your own tasks-- which could of course lead to a situation like the ones I mentioned above.

I think it’s safe to say none of these consequences are “fatal.”

Can someone split these posts off into a separate topic? we’re straying away from the OP.