Feedback for Driver Station

[marshallm900]

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.

[BoKnows]

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?

[marshallm900]

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.

[kimflynn]

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...

[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)!

---

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:

1. Driver's actual input (the joystick position)
2. 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):

1. Too many "timed loops" can cause the kernel to crash
2. Interrupts currently only work on rising edge
3. CAN can drop messages when utilization is greater than 98%
4. Add the ability to set IP addresses in the roboRIO Imaging Tool
5. Consider automatically updating the firmware during imaging if an out of date version is detected
6. 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
7. Latch game data in the driver station
8. Save kernel crash data to make available on next boot
9. Consider disabling 6V power rail to address issues in specific third-party hardware
10. Provide frequency output on DutyCycle
11. 16-bit support for joysticks
12. Modify DS to be a web-based utility
13. Other OS support for DS
14. Log file improvements
15. 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.

[BoKnows]

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.

[jdough]

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.

[BoKnows]

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?

[marshallm900]

>@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?

[BoKnows]

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.

1. 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.
2. Would these teams prioritize I2C work over resolution?
3. Would these teams prioritize Log improvements over resolution?
4. Would these teams prioritize CAN utilization help over resolution?
5. 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?