changes requested

Author: atiravseth

_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 <http://ri.cmu.edu/>.
+### 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.  

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