topic Re: Feedback for Driver Station in General

Feedback for Driver Station

marshallm900 — Tue, 06 Apr 2021 17:33:16 GMT

I'm hoping this is the right place for this. I'm actually posting it in the hopes that I can figure out where the correct place for this should be. If it's not then let me know where I can direct other teams in the future who have feedback to provide. For the actual feedback to be considered for the driver station:

For the driver station inputs, it would be nice to increase the analog input range for gamepads/joysticks/etc resolution to aid in control schemes and tuning for drivers. From discussions with other teams and the WPILib developers, this shouldn't be a difficult change and could help enable some new and interesting control schemes. I am unsure of the scope of the change though.

The log viewer for the driver station can be a bit hard to read and cryptic at times, particularly when debugging with newer users. It would be nice to borrow some of the ideas from this project to improve the log viewing experience: https://github.com/orangelight/DSLOG-Reader/releases

Please let me know how I can help make these ideas a reality. Happy to do what I can to assist. I would also appreciate an acknowledgement that someone has seen this feedback and this is the right place for it.

Re: Feedback for Driver Station

BoKnows — Sat, 12 Mar 2022 19:09:13 GMT

The joysticks idea comes up annually when we're looking at the list of ALL the things we'd like to do for the year's release. It's generally lower on the list of priorities for a couple of reasons. The first is the number of requests for this is relatively small which makes it seem like addressing things that will impact the larger community will be a better use of finite time. The second is one I think you can help with. There aren't generally explanations of how this would impact the teams that DO want it. Other than greater resolution, can you explain how you see it impacting control schemes (which I'd expect to be mostly automated and not see value from the joystick resolution) and tuning for drivers? More resolution sounds like an obvious answer. My initial gut feeling is the ability to use that extra resolution on joysticks would be something very few could/would master. I'd like to hear a dissenting opinion there to learn from it.

Log improvements are something near and dear to our heart. Most folks engaged with the FRC project at NI are also involved at events, often as a CSA or FTA where the logs can be incredibly useful. There are incremental changes made in most years to help make these more readable. Are there any of the ideas from DSLOG specifically you'd be interested in?

Re: Feedback for Driver Station

marshallm900 — Mon, 28 Mar 2022 17:47:19 GMT

Hi BoKnows!

Thanks for acknowledging my post! I apologize for it taking me a couple weeks to get back to you - as I'm sure you are aware, it's competition season and that's a busy time for teams. Also, thanks for being a CSA (or FTA, I assume)!

First off, the tactical answer for why higher resolution on the controller inputs would be helpful. Most teams are using low cost controllers that are meant for video games, not industrial machinery. Only a handful of teams are using industrial controls for driving their robots and even the ones that are using something like joysticks from APEM are using higher resolution than the 8 bits per axis we currently have available to us but can't take advantage of it.

With additional resolution we'll be able to better evaluate linearity and deadzone behavior of these inexpensive controllers to help us better map driver intent onto robot motion. Effectively, more resolution enables a higher capability to map inputs to outputs via decoupled control schemes.

As for this having an impact to a lot of teams - until we have it available to a few teams and start to see what can be done with it, it's hard to make libraries that are suited for general consumption. I don't think implementing this will magically make every robot that is struggling to drive into one that is driving great but I do think it's an area of interest for a lot of teams and has the potential to enable some cool new stuff, particularly with holonomic drive systems and brushless motors becoming more common now.

The other tactical issue being the log viewer on the driver station... The current built-in tool is a bit unwieldy to new-comers and often teams can't make heads or tails of it easily and correlate events. Custom naming and profiles for specific queries would be the most useful but aside from that bulk uploading, converting, and trending data would be awesome to see too along with labeling of probable events or actual events. Also, a quick way to upload those logs to a centrl spot for sharing would be awesome too. I think there are a lot of quality of life improvements that could be made to the DS log viewer.

You alluded to a list of priorities for the driver station software and I can safely say, I have no idea what those are. Is there a place where a team can see those? What is on the priority list for changes to the driver station? Is there a way I (or others) can contribute and help improve the code? Is there a way to get further involved in steering the direction of future improvements and changes? Knowing the priorities can help drive the conversation and asks as much as anything else.

I'd also still like to know if this is the best place to post feedback and have others post their feedback. Nearly a year on from my original post and I'm still not sure how to help teams get heard and I'd like to make sure I am directing them to the right spot. I feel like we need to address the strategic issues along with the tactical ones when it comes to this crucial piece of software for all teams.

Re: Feedback for Driver Station

kimflynn — Tue, 05 Apr 2022 17:38:16 GMT

Our team is a little limited on resources at time and while the Driver Station logs are an awesome tool, would it be possible to compress them in some way? The folder is approaching 1GB in size, plus the temporary use one on my personal laptop.

I tested ZIPping them up using just the Windows tool on my laptop and it shrunk by about 90%, which is pretty significant.

Also is this the right place for feedback and requests? If not I'll ask in the right one, provided the right one can be shared...

Re: Feedback for Driver Station

BoKnows — Wed, 06 Apr 2022 15:40:14 GMT

Thanks for acknowledging my post! I apologize for it taking me a couple weeks to get back to you - as I'm sure you are aware, it's competition season and that's a busy time for teams. Also, thanks for being a CSA (or FTA, I assume)!

Sorry it took so long to acknowledge. It really shouldn't have taken months for someone to say something here. Absolutely understand competition and build season being a time everyone is swamped. I fear the FTA role (my poor back and field setup haha). I'll CSA and referee. If events are in a bind, I'll put on the yellow hat but it's not where I'm at my best. Hopefully we'll see 900 at Houston this year.

First off, the tactical answer for why higher resolution on the controller inputs would be helpful. Most teams are using low cost controllers that are meant for video games, not industrial machinery. Only a handful of teams are using industrial controls for driving their robots and even the ones that are using something like joysticks from APEM are using higher resolution than the 8 bits per axis we currently have available to us but can't take advantage of it.

With additional resolution we'll be able to better evaluate linearity and deadzone behavior of these inexpensive controllers to help us better map driver intent onto robot motion. Effectively, more resolution enables a higher capability to map inputs to outputs via decoupled control schemes.

As for this having an impact to a lot of teams - until we have it available to a few teams and start to see what can be done with it, it's hard to make libraries that are suited for general consumption. I don't think implementing this will magically make every robot that is struggling to drive into one that is driving great but I do think it's an area of interest for a lot of teams and has the potential to enable some cool new stuff, particularly with holonomic drive systems and brushless motors becoming more common now.

This is where I'm still a bit foggy as to the expected gain. We're looking at the typical precision versus accuracy conversation. With 16-bit support compared to 8-bit support, we absolutely have more precision. There's a couple points I'm looking at here where this precision could matter:

Driver's actual input (the joystick position)
Input into the various "set" methods across the different motor controllers

Given we can already input values into the motor controllers programmatically, the only real place I see for potential improvement is the first. If we increase precision, we theoretically create the ability for a driver to have more precise control while using their joystick. For code that directly maps that input to the setters and output to the motor, we could see tighter control. What I'm trying to reconcile as I poke the dev team about prioritization is the driver accuracy. If we believe drivers have the ability to maintain an accurate control of the joystick such that they'll get value out of 65k levels, we could see gain. If drivers aren't much more accurate than the 256 levels they currently have, would we see a difference in control? With most controllers being the console style, 1/256" isn't exactly a large distance. That's been a driving factor in questioning how much value drivers would gain from the greater precision given expected accuracy. Do you have thoughts here?

The other tactical issue being the log viewer on the driver station... The current built-in tool is a bit unwieldy to new-comers and often teams can't make heads or tails of it easily and correlate events. Custom naming and profiles for specific queries would be the most useful but aside from that bulk uploading, converting, and trending data would be awesome to see too along with labeling of probable events or actual events. Also, a quick way to upload those logs to a centrl spot for sharing would be awesome too. I think there are a lot of quality of life improvements that could be made to the DS log viewer.

Absolutely agree. Any ideas you have here I'd love to push forward to devs to see what we can pull off. Teaching new CSAs how to work through the log viewer is often a trying task. I know it isn't easier for students/teams.

You alluded to a list of priorities for the driver station software and I can safely say, I have no idea what those are. Is there a place where a team can see those? What is on the priority list for changes to the driver station? Is there a way I (or others) can contribute and help improve the code? Is there a way to get further involved in steering the direction of future improvements and changes? Knowing the priorities can help drive the conversation and asks as much as anything else.

I don't have a good way to share those public. I'll share a non-prioritized list of things we have remaining to look at in future seasons as improvements (for FRC as a whole, not just the driver station):

Too many "timed loops" can cause the kernel to crash
Interrupts currently only work on rising edge
CAN can drop messages when utilization is greater than 98%
Add the ability to set IP addresses in the roboRIO Imaging Tool
Consider automatically updating the firmware during imaging if an out of date version is detected
Update the simulation options to include things like mechanum, swerve, ground intakes, etc to pull in some more commonly used subsystems in today's robots
Latch game data in the driver station
Save kernel crash data to make available on next boot
Consider disabling 6V power rail to address issues in specific third-party hardware
Provide frequency output on DutyCycle
16-bit support for joysticks
Modify DS to be a web-based utility
Other OS support for DS
Log file improvements
Report which joysticks are unplugged/lost

The primary focus this past season was focused on getting things to a state where the roboRIO 2.0 was usable. This consumed a lot of time to work with the other control system partners to make sure all the pieces worked together and was complicated by several new components being introduced at the same time. There's also a non-trivial amount of time that goes in annually to making sure everything is working as well as can be. A LOT of time this past year went into hunting down the issues with AutoSPI and getting an understanding of what causes the I2C issues that have been reported.

Really, the best way to help with the steering is to post here and post on Chief Delphi. I've heard both referenced in conversations to determine what's impacting the community and that helps weigh in on what gets prioritized with limited time/resources to get everything to teams.

I'd also still like to know if this is the best place to post feedback and have others post their feedback. Nearly a year on from my original post and I'm still not sure how to help teams get heard and I'd like to make sure I am directing them to the right spot. I feel like we need to address the strategic issues along with the tactical ones when it comes to this crucial piece of software for all teams.

Posting here for NI components is your best path. Posting to Chief Delphi for broader components will get attention. WPI, FIRST, and NI folks all watch the CD posts. Several of us watch the NI posts here.

Re: Feedback for Driver Station

BoKnows — Wed, 06 Apr 2022 16:03:13 GMT

Are you still using those older logs? If not, you're free to delete them.

I'm not sure how complicated it would be to get the driver station to be able to read those logs in a compressed format. I imagine if we looked into it, the answer would be "it's more complicated than removing outdated logs"

If you have something you're doing with the older logs that prevents this option, it'd be helpful to understand what that is when I talk to folks here.

Re: Feedback for Driver Station

jdough — Thu, 19 May 2022 14:41:04 GMT

Since I opened a WPILib issue 5 years ago about low resolution for the joysticks I was invited to comment here also when I made a comment about it on Chief Delphi yesterday ( https://github.com/wpilibsuite/allwpilib/issues/485 ). I'll add "me, too" to the request for higher resolution joysticks and better logs.

I doubt better resolution in the DS would help an XBox controller but other possible devices (better joysticks and as I mentioned in my issue the TI LaunchPad and others of that ilk) could take advantage to improve fine control of components of the robot. The FRC games are demanding for aiming and docking accurately. Tuning shooters for long distances, for example, could benefit from better than 0.5%.

For DS logs I wish the format was completely specified for our use and it's always nice to be easily parsed.

Since priorities were mentioned herein I'm obliged to undercut my own requests about the DS with these comments, if the same people are working on the issues below:

1. The I2C issues are a stain on FRC/NI credibility and hurt badly our ability to select sensors. I proved that the MXP I2C didn't work (for my team) and we were told not to use the onboard I2C. The pain and expense was significant.

2. In moving from I2C to USB at the last second (okay, literally the day before our competition) this season we hit a wall with a bug in USB discovery that limited our use of USB. Connecting a NavX and Canivore on USB didn't work right (one seemed to disconnect the other). More pain and agony.

Thanks for providing this forum.

Re: Feedback for Driver Station

BoKnows — Thu, 19 May 2022 15:21:42 GMT

There's a few things in there to comment on. Let me poke a bit to get as much information as I can to push on folks here.

I2C is something people here (and at FIRST) care greatly about. There's definitely work going into getting a better understanding of what people are running into and how to avoid said issues. If you have a repeatable problem case for the MXP, I'd be interested in reaching out to get a copy of that case to pass along to developers. Is that something you have?

The driver station is something that gets incremental fixes and is currently being prioritized. Things like I2C are going to take priority over it simply because that's something that needs a better answer than "don't use it" or "don't use it with these types of devices."

"Tuning shooters for long distances, for example, could benefit from better than 0.5%."

This seems counterintuitive to what I'd expect. If we increase resolution of joysticks, we're looking at the devices a student would use to send input. Are you having your drivers use their joystick to adjust shooters? Or, are you using another mechanism? I'd expect something along the lines of a limelight to determine distance, calculate what motor output you'd need, and then send that value to your motor controllers. That seems like it would be far more impactful to addressing inaccuracy in the shooter than increasing resolution in the joystick as the human element would remain the greatest source of error in that solution independent of 8-bit or 16-bit joysticks, right?

Or, am I misunderstanding the use case you're looking to address there?

Re: Feedback for Driver Station

marshallm900 — Thu, 19 May 2022 15:55:10 GMT

>@BoKnows wrote:
>If we increase resolution of joysticks, we're looking at the devices a student would use to send input.

Sometimes. You could also be looking at prototyping where a team is just trying to leverage an old robot and driver station to test a mechanism that is tethered but stationary or even just bolted on top of a basic robot control.

>Are you having your drivers use their joystick to adjust shooters?

I can't speak for the other poster but we do actually have manual intervention of our shooter flywheel to adjust speeds and there are a lot of teams that have nothing but manual control over it.

>I'd expect something along the lines of a limelight to determine distance, calculate what motor output you'd need, and then send that value to your motor controllers. That seems like it would be far more impactful to addressing inaccuracy in the shooter than increasing resolution in the joystick...

So, while I agree with this, not every team has the opportunity to throw resources at vision solutions to estimate target distance.

>as the human element would remain the greatest source of error in that solution independent of 8-bit or 16-bit joysticks, right?

Not necessarily... and humans are capable of pretty great control when it comes to video games and RC cars, which are pretty comparable to what we're talking about with FRC here.

Can we back up two steps - what do you or others at NI need to hear from us, the teams, to make the case that we want greater resolution on joystick input? I'm doing my best to get others to post here and provide you with feedback but it's a struggle.

Are you aware that there is at least one team that has designed a completely custom joystick and is utilizing two axis channels to send input and then recombining them onboard the RoboRIO for control? I'd wager there might even be more than 1 team doing this at this point. How do we make that sort of innovation accessible to more teams?

Re: Feedback for Driver Station

BoKnows — Fri, 20 May 2022 17:08:48 GMT

I'll try to hit all of those points. Quick pre-face, the questions I'm asking are things I'm hoping you'll challenge so I get a better understanding of what you're thinking. The teams that ask for greater resolution do so with a lot of passion so I want to be able to get my head into the same space when I bring this to prioritization conversations. The best way for me to do that (that I know) is to be borderline annoying now with counters such that you can school me a bit 😃

I'm confused to your first bit. Whether a competition robot or a prototype, joysticks are joysticks. The function there will be the same regardless, correct? If the student is using the device to send input into the system, they're using a joystick. If they're entering something in code, the resolution wouldn't have an impact. The only place where a modification of 8 to 16 bit would have an impact is where the individual is manually touching an input device and moving it to see a response.

Can you talk me through your manual intervention? What's the start to finish workflow for a student in this situation? Are there any inputs on their dashboard to show them either distance, flywheel velocity, or joystick values? Do they eyeball the distance and use their instinct to place the joystick at a specific location? Do they adjust their joystick based on where that ball shoots? (For this year, having two balls makes that possible. Last year, 5 balls. Games with one ball, I don't know how you'd accomplish this but I want to understand if you're aware of teams doing this successfully)

I agree not every team has the ability to use vision solutions. Though, I'd question if every team has the ability to make use of greater resolution successfully. A large number of teams are using xbox style controllers. 256 options already presents them with less than 1/10" of space assuming a linear shift.

No matter how great the control is, we're still looking at what factors into the measurement. We have accuracy and precision. We can make something more precise (increase resolution) but we're still looking at an accuracy issue. The question I'm trying to poke at here is do we believe the precision is the greater impact for the vast majority of teams or do we think the accuracy is? It's also worth noting we're looking at a subset of teams that lack the resources/expertise to implement the better vision solution. Do these teams typically have the input devices that can take advantage of the increased resolutions best? The smaller the joystick (xbox style controllers), the less ability to take advantage of more range. For context, 1/256th of a couple inches is less than 1/10 of an inch. It's closer to 2/5 of an inch with a joystick that moves 10"

Am I aware of the team that's constructed their own version of a 16-bit resolution using two axis? No. I was not. I'm assuming "left" here is to do the coarse movement with the "right" being the fine tuning within a range? Is this a shared library? If so, that's the quickest way to get that innovation into the hands of teams. Even with 16-bit joysticks, this still seems like a valuable option to have.

The backing up two steps is likely a good idea. I think the question asked here isn't the right question to get an answer that's going to lead to what you'd see as constructive. I think we'd all agree there are teams that want greater resolution (and have for at least several years). There isn't a dispute that it's a desired feature for a subset of teams. I've got a few questions here to help inform a prioritization conversation.

What percentage of teams do you believe would see benefit from the change? In this, we could easily say 100% but that's not entirely accurate. Teams with vision systems aren't likely to see much, if any, benefit. Teams without input devices that make this practical aren't going to see benefit. Etc. There's a reason a subset of the community is asking for this versus the entire community. If we have a decent understanding of what subset could take advantage, it's easier to have a conversation around this. You seem to have a better handle on teams that want this and would see benefit. I'd like to get your thoughts here.
Would these teams prioritize I2C work over resolution?
Would these teams prioritize Log improvements over resolution?
Would these teams prioritize CAN utilization help over resolution?
Would these teams prioritize the roboRIO 2.0 imaging experience over resolution?

2-5 aren't an exhaustive list but they're some of the things I'm personally advocating to see improvements in. I ask these to get an idea of where you'd rank resolution among those so I have a better feel to know where I should push for it.

There's generally two questions we'd want to get an answer to: What percentage of the population are affected by only having 8bit resolution? For the affected population, what extent is the impact on them?

Re: Feedback for Driver Station

Brendan_Simons — Fri, 20 May 2022 18:08:08 GMT

I created an account just to respond to this question about controller input resolution. I am a lead mentor of a successful team, and also an RC quadcopter enthusiast. Every single RC aircraft in the past 20 years has used 10+ bit resolution (~1000+ values) to transmit thumbstick inputs into servo/ESC outputs. I don't think you'd find a pilot who would agree that 8bit (256 values) was adequate to allow them to perform maneuvers at speed without crashing.

https://www.rcgroups.com/forums/showthread.php?2192866-RC-Radio-Resolution-Servos-and-Pulse-Width

https://oscarliang.com/betaflight-firmware-setup/#receiver

Why wouldn't drivers of 150 pound robots, travelling at 15 ft/s while trying to score in a tiny goal, want anything less?

Re: Feedback for Driver Station

nlaverdure — Fri, 20 May 2022 18:25:07 GMT

Thanks for asking these questions!

Characterizing the linearity and deadbands of thumbsticks on popular inexpensive gamepads has been identified as a top item on the EWCP Research Agenda, item HMI.01 Gamepad thumbstick axis linearity. The EWCP Research Agenda is an attempt to coordinate a rough consensus on the next steps of tech development in our sport, and serves as a framework for intentional, organized study of the things we think are important-- the things that will make a beneficial impact in our competition community.

Successful research on HMI.01 will be enabled by changes in the DS software to allow greater axis resolution.

This is certainly not the only suggested change to the DS software! I share this information because I am surprised by the pushback it has received.

>The backing up two steps is likely a good idea. I think the question asked here isn't the right question to get an answer that's going to lead to what you'd see as constructive... There's generally two questions we'd want to get an answer to: What percentage of the population are affected by only having 8bit resolution? For the affected population, what extent is the impact on them?

Is it the perspective of the organization that in order for a user to bring forward feedback and suggestions borne of their operational experience, the user must first collect the overarching knowledge of how this experience is shared by their peers?

Re: Feedback for Driver Station

jdough — Tue, 24 May 2022 17:30:20 GMT

We discovered the 8-bit limitation for joysticks when carefully turning a big knob on a potentiometer to adjust motor speed. The coarse adjustment was an unwelcome surprise as we thought finer tuning would give more accuracy for the shooter. The same applies for fine adjustment for any docking maneuver. We guess better joysticks would help docking but maybe not - it's hard to test.

I2C issues need to be resolved before new features for driver station joysticks and logs. I'll try to come up with an MXP I2C repeatable failure but the exact equipment that failed has been dispersed and the robot room is closed for the summer. I'll do what I can and if successful at failing, I could send you the equipment for your testing.

We bit the bullet and bought a CTRE CANivore so CAN utilization went down nicely. If NI can so something to reduce utilization so we could do without the CANivore that would be great. We use Java and swerve modules and a motor for anything that moves.

I imaged the roboRIO 2.0 and I didn't see a significant problem that must be resolved. Easier is always better but what did I miss that I thought it wasn't very hard?

Re: Feedback for Driver Station

BoKnows — Tue, 31 May 2022 23:49:30 GMT

I'll do my best to hit on the points posed in the posts since my last post.

@Brendan_Simons wrote:

I don't think you'd find a pilot who would agree that 8bit (256 values) was adequate to allow them to perform maneuvers at speed without crashing.

Using the analogy of RC pilots for FRC robots, there's two ways to interpret this that I see.

1) We go and ask RC pilots if they can adequately control their plane with 8-bit joysticks.

2) We go and ask RC pilots if they've been adequately controlling their plane before revealing it was done with 8-bit joysticks.

In the thought experiment, I'd expect you're right and it's be almost unanimous in the first situation. For the second, I think we'd get better results. If they were adequately controlling their planes, they'd be surprised to find out it was done with 8-bit joysticks. But, we'd have a subset (of whatever number) that would have answered (1) differently than they would (2) and (2) would be more accurate. If the subset that had been adequately controlling their planes was a small subset, it would stand to reason there would be a larger voice from folks that were crashing and seeking improvement. It's not exact science, but the number of requests and portion of the community making the request is an indicator to what size of the population currently believes they aren't adequately controlling the robot.

@Brendan_Simons wrote:

Why wouldn't drivers of 150 pound robots, travelling at 15 ft/s while trying to score in a tiny goal, want anything less?

I'd expect they'd want the things mentioned as other potential changes MORE than this change given the discussion around each of the issues within the community. Would you disagree? Nobody is disputing 16-bit could be useful. I'm trying to get a feel for how MUCH value it brings so I can share that when folks are prioritizing which items they'll be able to work into future releases.

@jdough wrote:

We discovered the 8-bit limitation for joysticks when carefully turning a big knob on a potentiometer to adjust motor speed. The coarse adjustment was an unwelcome surprise as we thought finer tuning would give more accuracy for the shooter. The same applies for fine adjustment for any docking maneuver. We guess better joysticks would help docking but maybe not - it's hard to test.

Was this something done in the shop to help tune a mechanism or was it something you were using on the field? For docking, I'm assuming you're looking at things such as the panel grab/placement in Deep Space? If not, please correct me. If so, were you focused more on precision or time in these exchanges? I didn't see a lot of gameplay that year that was precise and instead more that would focus on cycle times to make a quick placement instead. I'm particularly interested in what you were doing that led you to notice the 8-bit piece so I can share the workflow that it failed you in.

@jdough wrote:

I2C issues need to be resolved before new features for driver station joysticks and logs. I'll try to come up with an MXP I2C repeatable failure but the exact equipment that failed has been dispersed and the robot room is closed for the summer. I'll do what I can and if successful at failing, I could send you the equipment for your testing.

Thanks for this. It's helpful just getting a feel for how folks in this thread would prioritize. It would be wildly helpful to have an example I could take to devs as this is something they're trying to reproduce in house.

@jdough wrote:

We bit the bullet and bought a CTRE CANivore so CAN utilization went down nicely. If NI can so something to reduce utilization so we could do without the CANivore that would be great. We use Java and swerve modules and a motor for anything that moves.

This is going to need to be a group effort but it's something I'd also like to see. A lot of the CAN bus and protocols for devices were written when teams weren't using nearly the CAN devices they are now. Decisions that were made then are problematic now and it'll take some work to change those to bring utilization down. I'd honestly expect to see CAN usage increase rather than stay the same or decrease in future years. This is something I'm keeping an eye on.

@jdough wrote:

I imaged the roboRIO 2.0 and I didn't see a significant problem that must be resolved. Easier is always better but what did I miss that I thought it wasn't very hard?

There were a non-trivial number of support requests surrounding the imaging. A roboRIO 2.0 out of the box could not be imaged with the roboRIO Imaging Tool. Many accidentally used the roboRIO image instead of the roboRIO 2.0 image and it appeared as if the roboRIO 2.0 was dead on arrival when they did. Going through the SD Card writer for one step and then updating the team number in another place was a poor user experience and not really intuitive. Some of that pain can be eased to get more teams up and running quicker instead of troubleshooting where things went wrong in the process. The process, and instructions, this year required a level of attention to detail that is a high expectation for high school students excited to get to work on a robot instead of installing software.

@nlaverdure wrote:

Characterizing the linearity and deadbands of thumbsticks on popular inexpensive gamepads has been identified as a top item on the EWCP Research Agenda, item HMI.01 Gamepad thumbstick axis linearity. The EWCP Research Agenda is an attempt to coordinate a rough consensus on the next steps of tech development in our sport, and serves as a framework for intentional, organized study of the things we think are important-- the things that will make a beneficial impact in our competition community.

Successful research on HMI.01 will be enabled by changes in the DS software to allow greater axis resolution.

The way I read this, there are two questions you're really looking at here. Correct me if I'm wrong.

1) What deadbands exist in common controllers used by FRC teams?

2) How do these deadbands impact control of robots?

The first sounds like a hardware question that is independent of the FRC ecosystem. If the gamepad has a hardware limitation, that'll be true if measured using the driver station or any other method we can use to read joystick values. I'd agree having a better measuring stick here would make it easier to find where these exist.

The second seems like an attempt to understand how that would impact a team's ability to start/stop/etc and have complete control of their robot.

If that's correct, what limits EWCP to using the Driver Station to find these deadbands?

@nlaverdure wrote:

This is certainly not the only suggested change to the DS software! I share this information because I am surprised by the pushback it has received.

In a world with infinite development time, this wouldn't even be a discussion. It would get fixed. The notion there are other suggested changes is where any pushback exists. The question here isn't "could this provide value?" as much as it is "should time be spent on this specific change or on one of the other suggested changes?" Until this point, it hasn't been viewed as a higher priority than other things worked on. As there are some folks here that are passionate about getting it resolved, I'm trying to peel back a layer to understand how it's currently impacting you so I can relay that to the prioritization conversations.

@nlaverdure wrote:
Is it the perspective of the organization that in order for a user to bring forward feedback and suggestions borne of their operational experience, the user must first collect the overarching knowledge of how this experience is shared by their peers?

I can speak for my understanding. Though, I will state this feels like a mischaracterization by intentional omission. I brought up two types of issues that tend to get prioritized:

1) Something that will affect a large(r) number of teams to any extent such that fixing it helps a large(r) number of teams.

2) Something that will affect a small(er) number of teams but will affect those teams greatly.

Your question here suggests there's an expectation for you to research to bring an answer for (1). That's not the expectation. Though, I'll point out you'd likely be frustrated if we spent significant effort researching this for each issue as that's bandwidth we'd be spending on researching instead of fixing. There's a level of research where we start to lose efficiency as we're spending more time understanding problems and as a result fixing fewer. A quick measure for (1) is "how many times are we seeing this request?" With various places feedback is given, we've seen several requests for 16-bit joysticks. We've seen more requests around other frustrations. That sample suggests the other things mentioned in this thread will impact more teams than a change to joysticks.

The probing questions I'm asking are to help understand (2). With those requests, there isn't typically an explanation of how the affected teams are impacted. If we could get a better understanding of this, it could be included in prioritization conversations. The questions aren't to make you research but rather an invitation to share how you're being impacted so I can share that feedback. My only goal here is to share my best guess as to how many teams will be impacted by any change and how much of an impact it'll give each affected team. Nothing to this point says 16-bit joysticks will, or won't, be prioritized. It's me asking you how you're impacted so I can share that.

Re: Feedback for Driver Station

marshallm900 — Tue, 23 Aug 2022 16:29:11 GMT

Just wanted to share some code we are publishing that does enable the splitting of joystick axis channels via a Teensy as a passthrough device with both USB device and host ports. We tested it out and it does work but the benefits are indeed questionable and need additional study (thus, why we are sharing it here in the hopes others might experiment): https://github.com/FRC900/16bit_joysticks It does require additional changes on the robot code side and it may need tweaking to fit whatever the controller scheme being used is... and that's an exercise for the implementer. Of note, we did discover that the POV Hat values for the DS, which are the only int16 values sent by the DS at present - likely because they are defined as 0-360? Not sure of the exact reason... but it's not an uint8 or int8 like all the other axis values - are actually not capable of being any value in the 0-360 range and are instead limited to only 1 of 8 specific values (9, technically to denote a non-pressed option). This seems to be a unique quirk of USB joysticks and how HID has been implemented more than anything but the irony is too humorous not to mention it.