From ca83b79be708647e46e1767c680ad1c0b333a8fd Mon Sep 17 00:00:00 2001 From: atiravseth Date: Fri, 1 May 2026 21:09:34 -0400 Subject: [PATCH 1/6] Atirav Seth - Add hardware design tips article --- _data/navigation.yml | 2 + .../hardware-design-tips.md | 106 ++++++++++++++++++ 2 files changed, 108 insertions(+) create mode 100644 wiki/system-design-development/hardware-design-tips.md diff --git a/_data/navigation.yml b/_data/navigation.yml index 60b17258..c9a89ab2 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -53,6 +53,8 @@ wiki: url: /wiki/system-design-development/subsystem-interface-modeling/ - title: In Loop Testing url: /wiki/system-design-development/In-Loop-Testing/ + - title: Hardware Design Tips + url: /wiki/system-design-development/hardware-design-tips/ - title: Project Management url: /wiki/project-management/ children: diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md new file mode 100644 index 00000000..482c9d03 --- /dev/null +++ b/wiki/system-design-development/hardware-design-tips.md @@ -0,0 +1,106 @@ +--- +# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be +# overwritten except in special circumstances. +# You should set the date the article was last updated like this: +date: 2020-05-11 # YYYY-MM-DD +# This will be displayed at the bottom of the article +# You should set the article's title: +title: Title goes here +# The 'title' is automatically displayed at the top of the page +# and used in other parts of the site. +--- +This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. + +This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. + +If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. + +In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). + +## First subheading +Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. + +This section covers the basic syntax and some rules of thumb for writing. + +### Basic syntax +A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . + +> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. + + +#### Bullet points and numbered lists +Here are some hints on writing (in no particular order): +- Focus on application knowledge. + - Write tutorials to achieve a specific outcome. + - Relay theory in an intuitive way (especially if you initially struggled). + - It is likely that others are confused in the same way you were. They will benefit from your perspective. + - You do not need to be an expert to produce useful content. + - Document procedures as you learn them. You or others may refine them later. +- Use a professional tone. + - Be non-partisan. + - Characterize technology and practices in a way that assists the reader to make intelligent decisions. + - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. + - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. +- Use American English (for now). + - We made add support for other languages in the future. +- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. + +Entries in the Wiki should follow this format: +1. Excerpt introducing the entry's contents. + - Be sure to specify if it is a tutorial or an article. + - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. +2. The content of your entry. +3. Summary. +4. See Also Links (relevant articles in the Wiki). +5. Further Reading (relevant articles on other sites). +6. References. + +#### Code snippets +There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. + +Larger chunks of code should use this format: +``` +def recover_msg(msg): + + // Good coders comment their code for others. + + pw = ProtocolWrapper() + + // Explanation. + + if rec_crc != calc_crc: + return None +``` +This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. + +#### LaTex Math Support +Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: +$$ \frac{1}{n^{2}} $$ + +#### Images and Video +Images and embedded video are supported. + +![Put a relevant caption here](/assets/images/images_Hk47portrait-298x300.jpg) + +{% include video id="8P9geWwi9e0" provider="youtube" %} + +{% include video id="148982525" provider="vimeo" %} + +The video id can be found at the end of the URL. In this case, the URLs were +`https://www.youtube.com/watch?v=8P9geWwi9e0` +& `https://vimeo.com/148982525`. + +## Summary +Use this space to reinforce key points and to suggest next steps for your readers. + +## See Also: +- Links to relevant material within the Robotics Knowledgebase go here. + +## Further Reading +- Links to articles of interest outside the Wiki (that are not references) go here. + +## References +- Links to References go here. +- References should be in alphabetical order. +- References should follow IEEE format. +- If you are referencing experimental results, include it in your published report and link to it here. From 12788040ec30a8098274ea7f8bef677b4fe89637 Mon Sep 17 00:00:00 2001 From: atiravseth Date: Fri, 1 May 2026 21:15:02 -0400 Subject: [PATCH 2/6] Atirav Seth - Update hardware design tips --- .../hardware-design-tips.md | 130 ++++++++---------- 1 file changed, 59 insertions(+), 71 deletions(-) diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md index 482c9d03..7e11909c 100644 --- a/wiki/system-design-development/hardware-design-tips.md +++ b/wiki/system-design-development/hardware-design-tips.md @@ -2,105 +2,93 @@ # Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be # overwritten except in special circumstances. # You should set the date the article was last updated like this: -date: 2020-05-11 # YYYY-MM-DD +date: 2026-05-01 # YYYY-MM-DD # This will be displayed at the bottom of the article # You should set the article's title: -title: Title goes here +title: Hardware Design Tips for Robotics # The 'title' is automatically displayed at the top of the page # and used in other parts of the site. --- -This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. -This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. +## Mechanical Design -If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. +### 1. To learn CAD, Do the ModelMania Problems. -In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). +After you have crossed the tutorials stage, try . **SOLIDWORKS ModelMania** has 26 years worth of problems, free, at different difficulty levels: [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) -## First subheading -Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. +A few personal tips: +- Try following the rule of not exiting the sketch till it is fully constrined. Even better, use parametric variables so that your model's most important dimensions remain editable and independent. +- Try rebuilding the same part a different way after you finish it, it broadens design perspective. +- Open source software will always be the best choice if you know how to use them. Learning [FreeCAD](https://www.freecad.org/) would be a great bulletproofing for the future (not dependant on licenses for CAD software). It also has a free API/CAD kernel if you are interested in exploring generative CAD design using MCP servers and LLMs. -This section covers the basic syntax and some rules of thumb for writing. +--- -### Basic syntax -A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . +### 2. FEA Simulation -> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. +Get the free ANSYS student license through CMU: [CMU Software Access](https://www.cmu.edu/computing/software/access.html) +ANSYS is what most companies use. It covers structural, thermal, and fluid sim. It shows up on job descriptions constantly. -#### Bullet points and numbered lists -Here are some hints on writing (in no particular order): -- Focus on application knowledge. - - Write tutorials to achieve a specific outcome. - - Relay theory in an intuitive way (especially if you initially struggled). - - It is likely that others are confused in the same way you were. They will benefit from your perspective. - - You do not need to be an expert to produce useful content. - - Document procedures as you learn them. You or others may refine them later. -- Use a professional tone. - - Be non-partisan. - - Characterize technology and practices in a way that assists the reader to make intelligent decisions. - - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. - - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. -- Use American English (for now). - - We made add support for other languages in the future. -- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. +COMSOL is better for research work where you're coupling multiple physics together (e.g., heat + structure + electrical all at once). More flexible, more common in academic papers. -Entries in the Wiki should follow this format: -1. Excerpt introducing the entry's contents. - - Be sure to specify if it is a tutorial or an article. - - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. -2. The content of your entry. -3. Summary. -4. See Also Links (relevant articles in the Wiki). -5. Further Reading (relevant articles on other sites). -6. References. +Examples of usage: +- Checking if a robot link will break under load: ANSYS +- Thermal analysis on a motor or PCB: ANSYS +- Piezoelectric actuator or anything multi-physics for a paper: COMSOL +- Airflow around a drone → ANSYS Fluent +--- -#### Code snippets -There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. +## Electronics & Mechatronics Design -Larger chunks of code should use this format: -``` -def recover_msg(msg): +### 1. Drop Eagle. Learn KiCad. - // Good coders comment their code for others. +Autodesk Eagle is being phased out and the free version has a tiny board size limit. KiCad is free, open source, has no restrictions, and is what you'll want if you ever start a company and don't want to pay software licensing fees forever. - pw = ProtocolWrapper() +KiCad has everything: hierarchical schematics, 3D board preview, SPICE simulation, custom symbol/footprint editors. It's also what a lot of startups and open hardware projects use now. - // Explanation. +To get started: +- Do the [DigiKey KiCad 9.0 Tutorials Playlist](https://www.youtube.com/watch?v=0Q6gU7-QqUg&list=PLEBQazB0HUyQ5YJSdCBb79orXaR3Uk5vm&index=2) (<1h play time) to get a really quick jumpstart as it covers the full schematic to layout to gerber to BOM workflow. +- Practice making your own symbols and footprints. You will always have some weird component that's not in any library. +- Always check community footprints against the actual datasheet before trusting them. +- Check your Gerbers in [Tracespace](https://tracespace.io/view/) before submitting to a fab. - if rec_crc != calc_crc: - return None -``` -This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. +For prototyping boards: JLCPCB and PCBWay both work great with KiCad exports, cheap and fast. -#### LaTex Math Support -Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: -$$ \frac{1}{n^{2}} $$ +--- -#### Images and Video -Images and embedded video are supported. +### 2. PCB layout tips -![Put a relevant caption here](/assets/images/images_Hk47portrait-298x300.jpg) +A board that works in simulation or on paper but has zero test points or indicators is a nightmare to debug in real life. Here are some general PCB design tips: -{% include video id="8P9geWwi9e0" provider="youtube" %} +- **Biforcate the placement of power and signal processing electronics on the board** — This ensures that none of the high EMI/EMC devices like inductors and switching regulators can cause noise on the low-power signal/GPIO traces. +- **Copper thickness** - DO NOT forget to mention the thicknes off copper traces (in oz usually) while placing your PCB order, as this can mean that your circuit can't even take 25% of its designed current load as the traces would be much thinner. +- **Test points** on every power rail and important signal. Just a pad. Saves hours. +- **Status LEDs** on your power rails (3.3V, 5V, 12V etc.) with a current limiting resistor. You want to immediately know if a rail isn't coming up. +- **Current sense resistors** on high-current paths — small value (0.01–0.1Ω), measure voltage across it with your ADC or multimeter. +- **Label your connectors** on the silkscreen. Pin 1 marker, net name, polarity. You will forget this in the lab at 2am one day. -{% include video id="148982525" provider="vimeo" %} +--- -The video id can be found at the end of the URL. In this case, the URLs were -`https://www.youtube.com/watch?v=8P9geWwi9e0` -& `https://vimeo.com/148982525`. +### 3. Simulate Your Power Circuit Before You Spin the Board -## Summary -Use this space to reinforce key points and to suggest next steps for your readers. +Most board failures are catchable before you even order the PCB. -## See Also: -- Links to relevant material within the Robotics Knowledgebase go here. +Use **LTspice** (Analog Devices) as it has models for most common components. Use it to: +- Check your gate drive waveforms +- Catch oscillation in feedback loops (buck converters especially) +- Test your design at edge cases (min/max input voltage, max current) -## Further Reading -- Links to articles of interest outside the Wiki (that are not references) go here. +--- -## References -- Links to References go here. -- References should be in alphabetical order. -- References should follow IEEE format. -- If you are referencing experimental results, include it in your published report and link to it here. +### 4. Wiring and wire management + +- **Use PG Cable Glands and conduits** - Use [PG glands](https://www.mcmaster.com/products/pg-glands/cord-grips-2~/) and [cable conduits/hose cariers](https://www.mcmaster.com/products/cable-conduit/) to provide strain relief on cables that go in/out of enclosures, and also provide water and dirt resistance to the electronics inside the enclosure. +- **Use [DIN rails and DIN-Rail Mount Terminal Blocks](https://www.mcmaster.com/products/din-rails/)** - They are the industrial alternative to breadboards and WAGO connectors. They provide a standardized wire connection interface. +**Use colour coded signal wires** - This is one of the most trivial-seeming tips but the one that gets overlooked the most, resulting in burnt ICs and shorted Jetson Nano's. General colour schemes are given below: + - VCC|GND : RED|BLACK + - SDA|SCL : YELLOW|WHITE + - CAN-H|CAN-L : WHITE|BLUE/BLACK + - UART TX|RX : GREEN|WHITE + - PWM : ORANGE +- **Twist your differential pair wires** - For CAN and RS-485, physically twist the wire pairs together. They cancel out common-mode noise through EMI rejection. If your CAN bus is dropping frames or throwing errors, untwisted wires are a likely culprit before you go hunting for software bugs. BUT, NEVER TWIST I2C CABLES TOGETHER. They are not differetnial signals and cause interference/result in the bus not working at all. +- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. \ No newline at end of file From b5b6a7c42bd0ba13c9354b738bc7714de1bdd4d1 Mon Sep 17 00:00:00 2001 From: atiravseth Date: Fri, 1 May 2026 21:18:30 -0400 Subject: [PATCH 3/6] Atirav Seth - Add intro and required wiki sections --- .../hardware-design-tips.md | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md index 7e11909c..d09bc650 100644 --- a/wiki/system-design-development/hardware-design-tips.md +++ b/wiki/system-design-development/hardware-design-tips.md @@ -10,6 +10,13 @@ title: Hardware Design Tips for Robotics # and used in other parts of the site. --- +This article covers practical hardware design tips for robotics engineers across +mechanical and electronics/mechatronics design. These are drawn from hands-on +experience building robotics systems and are meant to complement formal coursework. +Topics include CAD workflows, FEA simulation tool selection, PCB design for +debuggability, power circuit simulation, and wiring best practices including +emergency stop wiring, colour coding, and cable management. + ## Mechanical Design ### 1. To learn CAD, Do the ModelMania Problems. @@ -91,4 +98,17 @@ Use **LTspice** (Analog Devices) as it has models for most common components. Us - UART TX|RX : GREEN|WHITE - PWM : ORANGE - **Twist your differential pair wires** - For CAN and RS-485, physically twist the wire pairs together. They cancel out common-mode noise through EMI rejection. If your CAN bus is dropping frames or throwing errors, untwisted wires are a likely culprit before you go hunting for software bugs. BUT, NEVER TWIST I2C CABLES TOGETHER. They are not differetnial signals and cause interference/result in the bus not working at all. -- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. \ No newline at end of file +- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. + +## Summary +These are just starting tips, design only comes from experience! + +## See Also +- [Printed Circuit Board Design](/wiki/system-design-development/pcb-design/) +- [Mechanical Design](/wiki/system-design-development/mechanical-design/) +- [Cable Management](/wiki/system-design-development/cable-management/) + +## Further Reading +- [KiCad Getting Started — DigiKey YouTube Playlist](https://www.youtube.com/watch?v=0Q6gU7-QqUg) +- [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) +- [LTspice Simulator — Analog Devices](https://www.analog.com/en/resources/design-tools-and-calculators/ltspice-simulator.html) From 4d1bb83705c83514a92652ac5cf9e566e593a967 Mon Sep 17 00:00:00 2001 From: atiravseth Date: Sat, 9 May 2026 18:58:04 -0400 Subject: [PATCH 4/6] changes requested --- _templates/template.md | 133 ++++++++---------- .../hardware-design-tips.md | 2 +- 2 files changed, 63 insertions(+), 72 deletions(-) diff --git a/_templates/template.md b/_templates/template.md index 482c9d03..fbf72d3a 100644 --- a/_templates/template.md +++ b/_templates/template.md @@ -2,105 +2,96 @@ # Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be # overwritten except in special circumstances. # You should set the date the article was last updated like this: -date: 2020-05-11 # YYYY-MM-DD +date: 2026-05-01 # YYYY-MM-DD # This will be displayed at the bottom of the article # You should set the article's title: -title: Title goes here +title: Hardware Design Tips for Robotics # The 'title' is automatically displayed at the top of the page # and used in other parts of the site. --- -This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. -This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. +## Mechanical Design -If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. +### 1. To learn CAD, Do the ModelMania Problems. -In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). +After you have crossed the tutorials stage, try . **SOLIDWORKS ModelMania** has 26 years worth of problems, free, at different difficulty levels: [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) -## First subheading -Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. +A few personal tips: +- Try following the rule of not exiting the sketch till it is fully constrined. Even better, use parametric variables so that your model's most important dimensions remain editable and independent. +- Try rebuilding the same part a different way after you finish it, it broadens design perspective. +- Open source software will always be the best choice if you know how to use them. Learning [FreeCAD](https://www.freecad.org/) would be a great bulletproofing for the future (not dependant on licenses for CAD software). It also has a free API/CAD kernel if you are interested in exploring generative CAD design using MCP servers and LLMs. -This section covers the basic syntax and some rules of thumb for writing. +--- -### Basic syntax -A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . +### 2. FEA Simulation -> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. +Get the free ANSYS student license through CMU: [CMU Software Access](https://www.cmu.edu/computing/software/access.html) +ANSYS is what most companies use. It covers structural, thermal, and fluid sim. It shows up on job descriptions constantly. -#### Bullet points and numbered lists -Here are some hints on writing (in no particular order): -- Focus on application knowledge. - - Write tutorials to achieve a specific outcome. - - Relay theory in an intuitive way (especially if you initially struggled). - - It is likely that others are confused in the same way you were. They will benefit from your perspective. - - You do not need to be an expert to produce useful content. - - Document procedures as you learn them. You or others may refine them later. -- Use a professional tone. - - Be non-partisan. - - Characterize technology and practices in a way that assists the reader to make intelligent decisions. - - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. - - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. -- Use American English (for now). - - We made add support for other languages in the future. -- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. +COMSOL is better for research work where you're coupling multiple physics together (e.g., heat + structure + electrical all at once). More flexible, more common in academic papers. -Entries in the Wiki should follow this format: -1. Excerpt introducing the entry's contents. - - Be sure to specify if it is a tutorial or an article. - - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. -2. The content of your entry. -3. Summary. -4. See Also Links (relevant articles in the Wiki). -5. Further Reading (relevant articles on other sites). -6. References. +Examples of usage: +- Checking if a robot link will break under load: ANSYS +- Thermal analysis on a motor or PCB: ANSYS +- Piezoelectric actuator or anything multi-physics for a paper: COMSOL +- Airflow around a drone → ANSYS Fluent +--- -#### Code snippets -There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. +## Electronics & Mechatronics Design -Larger chunks of code should use this format: -``` -def recover_msg(msg): +### 1. Drop Eagle. Learn KiCad. - // Good coders comment their code for others. +Autodesk Eagle is being phased out and the free version has a tiny board size limit. KiCad is free, open source, has no restrictions, and is what you'll want if you ever start a company and don't want to pay software licensing fees forever. - pw = ProtocolWrapper() +KiCad has everything: hierarchical schematics, 3D board preview, SPICE simulation, custom symbol/footprint editors. It's also what a lot of startups and open hardware projects use now. - // Explanation. +To get started: +- Do the [DigiKey KiCad 9.0 Tutorials Playlist](https://www.youtube.com/watch?v=0Q6gU7-QqUg&list=PLEBQazB0HUyQ5YJSdCBb79orXaR3Uk5vm&index=2) (<1h play time) to get a really quick jumpstart as it covers the full schematic to layout to gerber to BOM workflow. +- Practice making your own symbols and footprints. You will always have some weird component that's not in any library. +- Always check community footprints against the actual datasheet before trusting them. +- Check your Gerbers in [Tracespace](https://tracespace.io/view/) before submitting to a fab. - if rec_crc != calc_crc: - return None -``` -This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. +For prototyping boards: JLCPCB and PCBWay both work great with KiCad exports, cheap and fast. -#### LaTex Math Support -Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: -$$ \frac{1}{n^{2}} $$ +--- -#### Images and Video -Images and embedded video are supported. +### 2. PCB layout tips -![Put a relevant caption here](/assets/images/images_Hk47portrait-298x300.jpg) +A board that works in simulation or on paper but has zero test points or indicators is a nightmare to debug in real life. Here are some general PCB design tips: -{% include video id="8P9geWwi9e0" provider="youtube" %} +- **Biforcate the placement of power and signal processing electronics on the board** — This ensures that none of the high EMI/EMC devices like inductors and switching regulators can cause noise on the low-power signal/GPIO traces. +- **Copper thickness** - DO NOT forget to mention the thicknes off copper traces (in oz usually) while placing your PCB order, as this can mean that your circuit can't even take 25% of its designed current load as the traces would be much thinner. +- **Test points** on every power rail and important signal. Just a pad. Saves hours. +- **Status LEDs** on your power rails (3.3V, 5V, 12V etc.) with a current limiting resistor. You want to immediately know if a rail isn't coming up. +- **Current sense resistors** on high-current paths — small value (0.01–0.1Ω), measure voltage across it with your ADC or multimeter. +- **Label your connectors** on the silkscreen. Pin 1 marker, net name, polarity. You will forget this in the lab at 2am one day. -{% include video id="148982525" provider="vimeo" %} +--- -The video id can be found at the end of the URL. In this case, the URLs were -`https://www.youtube.com/watch?v=8P9geWwi9e0` -& `https://vimeo.com/148982525`. +### 3. Simulate Your Power Circuit Before You Spin the Board -## Summary -Use this space to reinforce key points and to suggest next steps for your readers. +Most board failures are catchable before you even order the PCB. + +Use **LTspice** (Analog Devices) as it has models for most common components. Use it to: +- Check your gate drive waveforms +- Verify voltage divider ratios under real load +- Catch oscillation in feedback loops (buck converters especially) +- Test your design at edge cases (min/max input voltage, max current) + +--- -## See Also: -- Links to relevant material within the Robotics Knowledgebase go here. +### 4. Wiring and wire management -## Further Reading -- Links to articles of interest outside the Wiki (that are not references) go here. +- **Use PG Cable Glands and conduits** - Use [PG glands](https://www.mcmaster.com/products/pg-glands/cord-grips-2~/) and [cable conduits/hose cariers](https://www.mcmaster.com/products/cable-conduit/) to provide strain relief on cables that go in/out of enclosures, and also provide water and dirt resistance to the electronics inside the enclosure. +- **Use [DIN rails and DIN-Rail Mount Terminal Blocks](https://www.mcmaster.com/products/din-rails/)** - They are the industrial alternative to breadboards and WAGO connectors. They provide a standardized wire connection interface. +**Use colour coded signal wires** - This is one of the most trivial-seeming tips but the one that gets overlooked the most, resulting in burnt ICs and shorted Jetson Nano's. General colour schemes are given below: + - VCC|GND : RED|BLACK + - SDA|SCL : YELLOW|WHITE + - CAN-H|CAN-L : WHITE|BLUE/BLACK + - UART TX|RX : GREEN|WHITE + - PWM : ORANGE +- **Twist your differential pair wires** - For CAN and RS-485, physically twist the wire pairs together. They cancel out common-mode noise through EMI rejection. If your CAN bus is dropping frames or throwing errors, untwisted wires are a likely culprit before you go hunting for software bugs. +> BUT, NEVER TWIST I2C CABLES TOGETHER. They are not differetnial signals and cause interference/result in the bus not working at all. -## References -- Links to References go here. -- References should be in alphabetical order. -- References should follow IEEE format. -- If you are referencing experimental results, include it in your published report and link to it here. +- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. \ No newline at end of file diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md index d09bc650..9abf0527 100644 --- a/wiki/system-design-development/hardware-design-tips.md +++ b/wiki/system-design-development/hardware-design-tips.md @@ -5,7 +5,7 @@ date: 2026-05-01 # YYYY-MM-DD # This will be displayed at the bottom of the article # You should set the article's title: -title: Hardware Design Tips for Robotics +title: Hardware Design Tips # The 'title' is automatically displayed at the top of the page # and used in other parts of the site. --- From 3c1113f3ec93a1b80c0edbb9854cd1c34516b0b1 Mon Sep 17 00:00:00 2001 From: Nevin Valsaraj Date: Mon, 7 Sep 2026 14:30:04 -0500 Subject: [PATCH 5/6] Address hardware design guide review feedback --- _data/navigation.yml | 2 +- _templates/template.md | 133 ++++++++++-------- .../hardware-design-tips.md | 43 +++--- wiki/system-design-development/index.md | 3 + 4 files changed, 99 insertions(+), 82 deletions(-) diff --git a/_data/navigation.yml b/_data/navigation.yml index 68d63db0..6e9cda30 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -24,7 +24,7 @@ wiki: - title: Subsystem Interface Modeling url: /wiki/system-design-development/subsystem-interface-modeling/ - title: In Loop Testing - url: /wiki/system-design-development/In-Loop-Testing/ + url: /wiki/system-design-development/in-loop-testing/ - title: Hardware Design Tips url: /wiki/system-design-development/hardware-design-tips/ - title: How to design a robotic state machine diff --git a/_templates/template.md b/_templates/template.md index fbf72d3a..482c9d03 100644 --- a/_templates/template.md +++ b/_templates/template.md @@ -2,96 +2,105 @@ # Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be # overwritten except in special circumstances. # You should set the date the article was last updated like this: -date: 2026-05-01 # YYYY-MM-DD +date: 2020-05-11 # YYYY-MM-DD # This will be displayed at the bottom of the article # You should set the article's title: -title: Hardware Design Tips for Robotics +title: Title goes here # The 'title' is automatically displayed at the top of the page # and used in other parts of the site. --- +This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. -## Mechanical Design +This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. -### 1. To learn CAD, Do the ModelMania Problems. +If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. -After you have crossed the tutorials stage, try . **SOLIDWORKS ModelMania** has 26 years worth of problems, free, at different difficulty levels: [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) +In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). -A few personal tips: -- Try following the rule of not exiting the sketch till it is fully constrined. Even better, use parametric variables so that your model's most important dimensions remain editable and independent. -- Try rebuilding the same part a different way after you finish it, it broadens design perspective. -- Open source software will always be the best choice if you know how to use them. Learning [FreeCAD](https://www.freecad.org/) would be a great bulletproofing for the future (not dependant on licenses for CAD software). It also has a free API/CAD kernel if you are interested in exploring generative CAD design using MCP servers and LLMs. +## First subheading +Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. ---- +This section covers the basic syntax and some rules of thumb for writing. -### 2. FEA Simulation +### Basic syntax +A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . -Get the free ANSYS student license through CMU: [CMU Software Access](https://www.cmu.edu/computing/software/access.html) +> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. -ANSYS is what most companies use. It covers structural, thermal, and fluid sim. It shows up on job descriptions constantly. -COMSOL is better for research work where you're coupling multiple physics together (e.g., heat + structure + electrical all at once). More flexible, more common in academic papers. +#### Bullet points and numbered lists +Here are some hints on writing (in no particular order): +- Focus on application knowledge. + - Write tutorials to achieve a specific outcome. + - Relay theory in an intuitive way (especially if you initially struggled). + - It is likely that others are confused in the same way you were. They will benefit from your perspective. + - You do not need to be an expert to produce useful content. + - Document procedures as you learn them. You or others may refine them later. +- Use a professional tone. + - Be non-partisan. + - Characterize technology and practices in a way that assists the reader to make intelligent decisions. + - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. + - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. +- Use American English (for now). + - We made add support for other languages in the future. +- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. -Examples of usage: -- Checking if a robot link will break under load: ANSYS -- Thermal analysis on a motor or PCB: ANSYS -- Piezoelectric actuator or anything multi-physics for a paper: COMSOL -- Airflow around a drone → ANSYS Fluent ---- +Entries in the Wiki should follow this format: +1. Excerpt introducing the entry's contents. + - Be sure to specify if it is a tutorial or an article. + - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. +2. The content of your entry. +3. Summary. +4. See Also Links (relevant articles in the Wiki). +5. Further Reading (relevant articles on other sites). +6. References. -## Electronics & Mechatronics Design +#### Code snippets +There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. -### 1. Drop Eagle. Learn KiCad. +Larger chunks of code should use this format: +``` +def recover_msg(msg): -Autodesk Eagle is being phased out and the free version has a tiny board size limit. KiCad is free, open source, has no restrictions, and is what you'll want if you ever start a company and don't want to pay software licensing fees forever. + // Good coders comment their code for others. -KiCad has everything: hierarchical schematics, 3D board preview, SPICE simulation, custom symbol/footprint editors. It's also what a lot of startups and open hardware projects use now. + pw = ProtocolWrapper() -To get started: -- Do the [DigiKey KiCad 9.0 Tutorials Playlist](https://www.youtube.com/watch?v=0Q6gU7-QqUg&list=PLEBQazB0HUyQ5YJSdCBb79orXaR3Uk5vm&index=2) (<1h play time) to get a really quick jumpstart as it covers the full schematic to layout to gerber to BOM workflow. -- Practice making your own symbols and footprints. You will always have some weird component that's not in any library. -- Always check community footprints against the actual datasheet before trusting them. -- Check your Gerbers in [Tracespace](https://tracespace.io/view/) before submitting to a fab. + // Explanation. -For prototyping boards: JLCPCB and PCBWay both work great with KiCad exports, cheap and fast. + if rec_crc != calc_crc: + return None +``` +This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. ---- +#### LaTex Math Support +Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: +$$ \frac{1}{n^{2}} $$ -### 2. PCB layout tips +#### Images and Video +Images and embedded video are supported. -A board that works in simulation or on paper but has zero test points or indicators is a nightmare to debug in real life. Here are some general PCB design tips: +![Put a relevant caption here](/assets/images/images_Hk47portrait-298x300.jpg) -- **Biforcate the placement of power and signal processing electronics on the board** — This ensures that none of the high EMI/EMC devices like inductors and switching regulators can cause noise on the low-power signal/GPIO traces. -- **Copper thickness** - DO NOT forget to mention the thicknes off copper traces (in oz usually) while placing your PCB order, as this can mean that your circuit can't even take 25% of its designed current load as the traces would be much thinner. -- **Test points** on every power rail and important signal. Just a pad. Saves hours. -- **Status LEDs** on your power rails (3.3V, 5V, 12V etc.) with a current limiting resistor. You want to immediately know if a rail isn't coming up. -- **Current sense resistors** on high-current paths — small value (0.01–0.1Ω), measure voltage across it with your ADC or multimeter. -- **Label your connectors** on the silkscreen. Pin 1 marker, net name, polarity. You will forget this in the lab at 2am one day. +{% include video id="8P9geWwi9e0" provider="youtube" %} ---- +{% include video id="148982525" provider="vimeo" %} -### 3. Simulate Your Power Circuit Before You Spin the Board +The video id can be found at the end of the URL. In this case, the URLs were +`https://www.youtube.com/watch?v=8P9geWwi9e0` +& `https://vimeo.com/148982525`. -Most board failures are catchable before you even order the PCB. - -Use **LTspice** (Analog Devices) as it has models for most common components. Use it to: -- Check your gate drive waveforms -- Verify voltage divider ratios under real load -- Catch oscillation in feedback loops (buck converters especially) -- Test your design at edge cases (min/max input voltage, max current) - ---- +## Summary +Use this space to reinforce key points and to suggest next steps for your readers. -### 4. Wiring and wire management +## See Also: +- Links to relevant material within the Robotics Knowledgebase go here. -- **Use PG Cable Glands and conduits** - Use [PG glands](https://www.mcmaster.com/products/pg-glands/cord-grips-2~/) and [cable conduits/hose cariers](https://www.mcmaster.com/products/cable-conduit/) to provide strain relief on cables that go in/out of enclosures, and also provide water and dirt resistance to the electronics inside the enclosure. -- **Use [DIN rails and DIN-Rail Mount Terminal Blocks](https://www.mcmaster.com/products/din-rails/)** - They are the industrial alternative to breadboards and WAGO connectors. They provide a standardized wire connection interface. -**Use colour coded signal wires** - This is one of the most trivial-seeming tips but the one that gets overlooked the most, resulting in burnt ICs and shorted Jetson Nano's. General colour schemes are given below: - - VCC|GND : RED|BLACK - - SDA|SCL : YELLOW|WHITE - - CAN-H|CAN-L : WHITE|BLUE/BLACK - - UART TX|RX : GREEN|WHITE - - PWM : ORANGE -- **Twist your differential pair wires** - For CAN and RS-485, physically twist the wire pairs together. They cancel out common-mode noise through EMI rejection. If your CAN bus is dropping frames or throwing errors, untwisted wires are a likely culprit before you go hunting for software bugs. -> BUT, NEVER TWIST I2C CABLES TOGETHER. They are not differetnial signals and cause interference/result in the bus not working at all. +## Further Reading +- Links to articles of interest outside the Wiki (that are not references) go here. -- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. \ No newline at end of file +## References +- Links to References go here. +- References should be in alphabetical order. +- References should follow IEEE format. +- If you are referencing experimental results, include it in your published report and link to it here. diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md index 9abf0527..2dc37b44 100644 --- a/wiki/system-design-development/hardware-design-tips.md +++ b/wiki/system-design-development/hardware-design-tips.md @@ -15,28 +15,30 @@ mechanical and electronics/mechatronics design. These are drawn from hands-on experience building robotics systems and are meant to complement formal coursework. Topics include CAD workflows, FEA simulation tool selection, PCB design for debuggability, power circuit simulation, and wiring best practices including -emergency stop wiring, colour coding, and cable management. +emergency-stop wiring, color coding, and cable management. ## Mechanical Design -### 1. To learn CAD, Do the ModelMania Problems. +### 1. Learn CAD with the ModelMania Problems -After you have crossed the tutorials stage, try . **SOLIDWORKS ModelMania** has 26 years worth of problems, free, at different difficulty levels: [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) +After completing introductory tutorials, work through **SOLIDWORKS ModelMania** problems. The archive has 26 years of free problems at different difficulty levels: [SOLIDWORKS ModelMania Archive](https://blogs.solidworks.com/products/solidworks/26-years-of-model-mania/) A few personal tips: -- Try following the rule of not exiting the sketch till it is fully constrined. Even better, use parametric variables so that your model's most important dimensions remain editable and independent. -- Try rebuilding the same part a different way after you finish it, it broadens design perspective. -- Open source software will always be the best choice if you know how to use them. Learning [FreeCAD](https://www.freecad.org/) would be a great bulletproofing for the future (not dependant on licenses for CAD software). It also has a free API/CAD kernel if you are interested in exploring generative CAD design using MCP servers and LLMs. +- Try not to exit a sketch until it is fully constrained. Better yet, use parametric variables so the model's most important dimensions remain editable and independent. +- Try rebuilding the same part in a different way after you finish it; this broadens your design perspective. +- Open-source tools such as [FreeCAD](https://www.freecad.org/) can be a good option when avoiding CAD software license dependencies. It also has a free API and CAD kernel for exploring generative CAD design using MCP servers and LLMs. --- ### 2. FEA Simulation +Finite element analysis (FEA) simulates how a design responds to forces, heat, and other physical effects before it is built. It helps newcomers identify potential structural, thermal, or fluid-related issues early in the design process. + Get the free ANSYS student license through CMU: [CMU Software Access](https://www.cmu.edu/computing/software/access.html) -ANSYS is what most companies use. It covers structural, thermal, and fluid sim. It shows up on job descriptions constantly. +ANSYS is widely used in industry. It covers structural, thermal, and fluid simulations. -COMSOL is better for research work where you're coupling multiple physics together (e.g., heat + structure + electrical all at once). More flexible, more common in academic papers. +COMSOL is useful for research work that couples multiple physics, such as heat, structure, and electrical effects. It is more flexible and common in academic papers. Examples of usage: - Checking if a robot link will break under load: ANSYS @@ -67,8 +69,8 @@ For prototyping boards: JLCPCB and PCBWay both work great with KiCad exports, ch A board that works in simulation or on paper but has zero test points or indicators is a nightmare to debug in real life. Here are some general PCB design tips: -- **Biforcate the placement of power and signal processing electronics on the board** — This ensures that none of the high EMI/EMC devices like inductors and switching regulators can cause noise on the low-power signal/GPIO traces. -- **Copper thickness** - DO NOT forget to mention the thicknes off copper traces (in oz usually) while placing your PCB order, as this can mean that your circuit can't even take 25% of its designed current load as the traces would be much thinner. +- **Separate power and signal-processing electronics on the board** — This helps prevent high-EMI/EMC devices, such as inductors and switching regulators, from introducing noise into low-power signal and GPIO traces. +- **Copper thickness** — Specify copper trace thickness (usually in oz) when placing a PCB order. If the traces are too thin, the circuit may not carry its designed current load. - **Test points** on every power rail and important signal. Just a pad. Saves hours. - **Status LEDs** on your power rails (3.3V, 5V, 12V etc.) with a current limiting resistor. You want to immediately know if a rail isn't coming up. - **Current sense resistors** on high-current paths — small value (0.01–0.1Ω), measure voltage across it with your ADC or multimeter. @@ -89,16 +91,19 @@ Use **LTspice** (Analog Devices) as it has models for most common components. Us ### 4. Wiring and wire management -- **Use PG Cable Glands and conduits** - Use [PG glands](https://www.mcmaster.com/products/pg-glands/cord-grips-2~/) and [cable conduits/hose cariers](https://www.mcmaster.com/products/cable-conduit/) to provide strain relief on cables that go in/out of enclosures, and also provide water and dirt resistance to the electronics inside the enclosure. +- **Use PG cable glands and conduits** — Use [PG glands](https://www.mcmaster.com/products/pg-glands/cord-grips-2~/) and [cable conduits/hose carriers](https://www.mcmaster.com/products/cable-conduit/) to provide strain relief for cables entering and leaving enclosures, while improving water and dirt resistance for the electronics inside. - **Use [DIN rails and DIN-Rail Mount Terminal Blocks](https://www.mcmaster.com/products/din-rails/)** - They are the industrial alternative to breadboards and WAGO connectors. They provide a standardized wire connection interface. -**Use colour coded signal wires** - This is one of the most trivial-seeming tips but the one that gets overlooked the most, resulting in burnt ICs and shorted Jetson Nano's. General colour schemes are given below: - - VCC|GND : RED|BLACK - - SDA|SCL : YELLOW|WHITE - - CAN-H|CAN-L : WHITE|BLUE/BLACK - - UART TX|RX : GREEN|WHITE - - PWM : ORANGE -- **Twist your differential pair wires** - For CAN and RS-485, physically twist the wire pairs together. They cancel out common-mode noise through EMI rejection. If your CAN bus is dropping frames or throwing errors, untwisted wires are a likely culprit before you go hunting for software bugs. BUT, NEVER TWIST I2C CABLES TOGETHER. They are not differetnial signals and cause interference/result in the bus not working at all. -- **Emegency Stop Wiring** - Do not wire the emergency stop directly on the power wire as this may cause spraking between switch contacts due to the high back EMF from a decelrating motor. Use a relay/DC contactor with a flyback diode across the terminals of the input (control circuit) and an RC snubber circuit across the contacts of the relay will prevent voltage spikes when the load is disconnected. +- **Use color-coded signal wires** — This simple practice is often overlooked, but it can prevent burnt ICs and shorted Jetson Nanos. General color schemes are given below: + - VCC|GND: RED|BLACK + - SDA|SCL: YELLOW|WHITE + - CAN-H|CAN-L: WHITE|BLUE/BLACK + - UART TX|RX: GREEN|WHITE + - PWM: ORANGE +- **Twist differential-pair wires** — For CAN and RS-485, physically twist wire pairs together to reject common-mode noise. If a CAN bus drops frames or reports errors, untwisted wires are a likely culprit before software issues. + + Never twist I2C wires together. I2C is not a differential signal, and twisting can introduce interference that prevents the bus from working. + +- **Emergency-stop wiring** — Do not wire an emergency stop directly into a high-current power wire, because a decelerating motor's back EMF can cause sparking at the switch contacts. Use a relay or DC contactor, a flyback diode across the control-circuit terminals, and an RC snubber across the relay contacts to limit voltage spikes when disconnecting the load. ## Summary These are just starting tips, design only comes from experience! diff --git a/wiki/system-design-development/index.md b/wiki/system-design-development/index.md index 2dcbc26b..7eaa8b75 100644 --- a/wiki/system-design-development/index.md +++ b/wiki/system-design-development/index.md @@ -16,6 +16,9 @@ The **System Design and Development** section provides comprehensive resources a - **[Finite State Machine Implementation Guide for Robotics](/wiki/system-design-development/finite-state-machine/)** Provides a structured approach to managing complex robot behaviors through states, transitions, and actions. Covers theoretical foundations and implementation in ROS and embedded systems. +- **[Hardware Design Tips](/wiki/system-design-development/hardware-design-tips/)** + Offers practical guidance on CAD, FEA, PCB layout, circuit simulation, wiring, and cable management for robotics projects. + - **[Hardware-in-Loop and Software-in-Loop Testing](/wiki/system-design-development/in-loop-testing/)** Discusses HIL and SIL methodologies for testing real-time embedded controllers, with specific use cases like ADAS and autonomous vehicles. From 66c8d12650c5b756508916a3522e846dd83e3d0e Mon Sep 17 00:00:00 2001 From: Nevin Valsaraj Date: Mon, 7 Sep 2026 14:31:10 -0500 Subject: [PATCH 6/6] Clean up hardware design guide formatting --- .../hardware-design-tips.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/wiki/system-design-development/hardware-design-tips.md b/wiki/system-design-development/hardware-design-tips.md index 2dc37b44..5040b04b 100644 --- a/wiki/system-design-development/hardware-design-tips.md +++ b/wiki/system-design-development/hardware-design-tips.md @@ -1,6 +1,6 @@ --- # Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be -# overwritten except in special circumstances. +# overwritten except in special circumstances. # You should set the date the article was last updated like this: date: 2026-05-01 # YYYY-MM-DD # This will be displayed at the bottom of the article @@ -10,11 +10,11 @@ title: Hardware Design Tips # and used in other parts of the site. --- -This article covers practical hardware design tips for robotics engineers across -mechanical and electronics/mechatronics design. These are drawn from hands-on -experience building robotics systems and are meant to complement formal coursework. -Topics include CAD workflows, FEA simulation tool selection, PCB design for -debuggability, power circuit simulation, and wiring best practices including +This article covers practical hardware design tips for robotics engineers across +mechanical and electronics/mechatronics design. These are drawn from hands-on +experience building robotics systems and are meant to complement formal coursework. +Topics include CAD workflows, FEA simulation tool selection, PCB design for +debuggability, power circuit simulation, and wiring best practices including emergency-stop wiring, color coding, and cable management. ## Mechanical Design @@ -30,7 +30,7 @@ A few personal tips: --- -### 2. FEA Simulation +### 2. FEA Simulation Finite element analysis (FEA) simulates how a design responds to forces, heat, and other physical effects before it is built. It helps newcomers identify potential structural, thermal, or fluid-related issues early in the design process.