Feedback for Driver Station

[Brendan_Simons]

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?

[nlaverdure]

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?

[jdough]

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?

[BoKnows]

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.

[marshallm900]

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.