Hey im new to programming and im trying to make a set of leds change color when ever the robot is intaking hopefully one of yall could help me
Hi!
There’s too little information for us to work off of here. Do you have an LED controller? If so, what type? What have you tried so far?
No i dont think we do we plug them directly into the roborio and program them off of the computers right now ive tired making a parallel command but cant figue that out
Can you share the relevant code (post it on here)? Also, see the parallel command documentation here: Command Compositions — FIRST Robotics Competition documentation
In general, you want to have both an intake command and your own LED command (I implement these as functional commands) in a Parallel Command Group.
1 Like
Here is our LED subsystem from last year FRC2024/src/main/java/frc/robot/subsystems/LEDs.java at main · Frc5572/FRC2024 · GitHub with the associated commands and triggers FRC2024/src/main/java/frc/robot/RobotContainer.java at 7aa409630eef50634ef5fcb5fc4440d04419f97c · Frc5572/FRC2024 · GitHub
hey thanks i was able to fix it off the documentation
1 Like
I’m super new to this and wondering if you could walk me thru how you coded this intake LED based on beam brake condition?
Take a look at what I posted. We use a Trigger when the beambrake is true to run a command that flashes the LEDs. I can provide more details if u need.
I looked at your code. It made sense. Basically I need to create the LED subsystem
and establish it in RobotContainer.
This is the command where you get the beam brake input? What is the .25 constant for?
Also, Did you have vision guided intake?
Thanks
The 0.25 is the time constant for the debouncer, specifically, “the number of seconds the value must change from baseline for the filtered value to change.” So the signal must be high for at least 0.25 seconds before the trigger goes, which filters out “false positive” pulses less than 0.25 seconds in duration.
1 Like
Many break-beam sensors have effective-debounce built-in with various and significantly different algorithms. Adding debounce to your trigger may be unnecessary and potentially cause bad delay.
The Pololu break-beam sensors that my team often uses implements internally the hysteresis path shown below. The interpretation of this sensor with your debounce would be indicate High when the distance goes above 174mm and stays above 150mm for at least 0.25 seconds. We have never needed the time-based debouncing for those sensors as the 24mm margin has always been adequate for debouncing.
I hear ya, not sure about our beam brakes but we had significant improvement removing instant blips of change in state of the beam brake by using the debouncer.
Unrelated to the LED system on your code you posted, did you have any vision that helps guide intaking process?
Thanks
Like to move the robot to line up the note into the intake using object detection? No, not for us. Our intake was wide enough that as long as we touched it, it would get sucked in. I know other teams did object detection stuff though.
1 Like
An interesting experiment is to view exactly how many spikes there are before there is a clean, final state change. Use a WPILib digital counter class on your DIO port. I’ve seen dozens of spikes on the mechanical microswitches no matter how well or firmly I press or release the switch. You could do that on your break-beam switch and see exactly how long your debounce period should be.