Quote:
Originally Posted by Joe Ross
|
I did know that but ugh, javafx? nasty.
Quote:
Originally Posted by Team3266Spencer
We use command based and I'm surprised they didn't make you shut down your smartdashboard. Do you think you could help me with this custom dashboard of yours?
|
The custom dashboard isn't much but some Swing architecture combined with a OpenCV for Java rendering agent, if you need help with any I can help. Attached is a pic of the nicer dashboard and the not-so-nice dashboard with a bigger screen. I can't give you the exact FPS on the processing, but its decent. Not the best because I do the primary step of processing (blobfinding) in my own Java code so it gets inefficient. (Though I benchmarked it and it was only getting like 5ms downtimes so idk)
Quote:
Originally Posted by AllenGregoryIV
We always displayed the speed of each of our 3 shooter wheels. We also have small things like a small disabled toggle that toggles while the robot is disabled to easily show the drivers that the smartdashboard hasn't crashed.
The dashboard was used mostly by the operator not the base driver. They could adjust the shooter speeds for each of the 3 wheels, and also the speeds the wheels ran when they were in collection mode. We had a couple things that ran on timers, like how long our flick motors ran to shoot out each disc. All of these setting could be adjusted pre-match or during the match.
One of the things that helps make sure you don't have any lag with the dashboard is to limit the number of times you update it. We have two update dashboard methods that get run based on the system clock. One runs every .2 secs and the other every 2 secs. That way we aren't trying to constantly stream information. 0.2 seconds is plenty fast for most things.
|
3 shooter wheels? Why wouldn't they be the same? Also, if your showing them on the dash theres a large chance your controlling them via pid so it would be quicker to just display a green/red image if they are ready. Again, why are you being forced to change constants? The constants used on our robot for PID controlling were pretty much universal once kettering hit. For the SD, it seems like it would be easier to just intercept the putData calls and insert them into a flush buffer :/