Add hardware intro and resources overview pages - #104
Conversation
|
🌐 Preview URL: https://pr-104.frcsoftware.pages.dev |
reniejoshi
changed the title
|
I would make a distinction between absolute and relative encoders. |
roboteer5291
left a comment
roboteer5291
left a comment
There was a problem hiding this comment.
I like what you've written, but I think some reconsideration on the purpose of this section would be good. It feels like a weird mix between resources, best practices, and teaching. I think we'd be best served to keep this section as much of resources as possible, since best practices and teaching already have a home within the learning course (and best practices may get their own section, tbd).
I also think that it'd be wise to include the distinction of encoder types from a software functionality perspective as mentioned, and to also include mention of beam breaks/retroreflective sensors and distance sensors (noting that those are most commonly used as a beam break-esque sensor).
ee22451 to
a5c6c30
Compare
github-actions
Bot
added
Curriculum material
Co-authored-by: Zach Harel <zach@zharel.me>
…into hardware-intro
…into hardware-intro
…into hardware-intro
Daniel1464
left a comment
Daniel1464
left a comment
There was a problem hiding this comment.
Hey Renie, I realized that the CI wasn't compiling your code snippets properly, so I opened PR #139 to fix it. So, I would suggest merging in that change once PR #139 gets merged in.
The code looks mostly good, but you do need to explicitly define the ExampleMotor and ExampleEncoder classes, and add some missing imports.
## Description I noticed that in PR #104, the resources snippets subdirectory wasn't being compiled properly. This changes examples.gradle to be more flexible in it's subrepo search. ## Meta Merge checklist: - [x] Pull Request title is [short, imperative summary](https://cbea.ms/git-commit/) of proposed changes - [x] The description documents the _what_ and _why_, including events that led to this PR - [x] Pull Request has been [linted and formatted](https://frcsoftware.org/contribution/styleguide/#linting-and-formatting) and follows the [styleguide](https://frcsoftware.org/contribution/styleguide)
|
|
||
| **Odometry** | ||
|
|
||
| Using sensors on the robot to create an estimate of the pose of the robot on the field. |
There was a problem hiding this comment.
This definition could be improved to include how it’s estimated through accumulation of relative changes over time, and maybe mention drift. Otherwise a good definition and I like how it specifically states that it’s internal sensors and that is uses pose to refer to both orientation and position.
|
|
||
| ## Limit Switch | ||
|
|
||
| A limit switch detects if something is past a certain threshold in distance. |
There was a problem hiding this comment.
This current definition sounds imprecise in terms of describing a limit switch as an analog, continuous measurement whereas it actually is a binary mechanical contact at a fixed point. You can also contrast the limit switch to the beam break to help understand the difference between an optical vs mechanical contact.
|  | ||
|  | ||
|
|
||
| ## Encoders |
There was a problem hiding this comment.
Since this is a programming focused project, it would be wise to mention what types of measurements do different sensors use, and how that can be harnessed in code.
8 participants
Description
Add hardware intro page that briefly covers motors, encoders, and gyroscopes for programmers, including code snippets showing common use cases. This serves to introduce programmers to basic hardware components that they will encounter in writing FRC robot code. Closes #23.
Add overview page for resources navigation with styles and visual components similar to FRCDesign.org.
Meta
Merge checklist: