Giter VIP home page Giter VIP logo

rp2040-motor-controller's People

Contributors

tlalexander avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rp2040-motor-controller's Issues

Subscribe to this issue to be notified of board availability.

When the layout is completed and boards are available, I will update this issue. I will update once when we have finalized things and ordered the first batch of boards to test, and subsequently as we make progress on verification and order more boards to be distributed to community members to help with firmware development. We may sell boards in the future, or encourage someone else in the community to take on that work, after we have verified the design.

Improvement idea: CAN bus

Great board! CAN bus is commonly used with industrial motor drives and is robust to noise inevitably produced in robotic systems. Consider the MCP2515 SPI CAN controller and a 3.3V CAN transceiver. Perhaps this is suitable for a small daughter card using the 3.3V on the SPI header.

With a dual core MCU, you might consider running CANopen device code on one core while the other is tasked with controlling the motor.

Fast design review

At first glance, the design looks really clean!

Note that this review isn't exhaustive.

Schematic

Readability

  • I'd add documentation in the schematic on what the max voltage and current for VMOT is.

  • There's no consistent flow to the schematic and a lot of things are unclear. For example:

    • there's an "IO" label floating in space with a single cap (C29).
    • It's unclear if J21 is sourcing or sinking VMOT.
    • Regulators should be grouped together. U24 is nowhere near U11.
    • There are 2 net labels for 3.3V: +3V3 and +3.3V. This is inconsistent and KiCad picks one to use (disregarding the other).
  • I'd add a block diagram (or make the schematic more hierarchical) to make it easier to understand what's going on.

  • I'd change your page-size/title block size to fit everything, or break it into more pages. The title block isn't doing anything as it is.

  • I'd add the voltage rating to C73.

  • Was this part accidentally deleted? If it was intentional, I'd delete these leftover wires.
    image

  • The U3 RefDes is hard to read, and the symbol doesn't have a filled background. It makes the schematic more readable if all symbols look self-consistent. If these were stock library parts, disregard, haha. That's a lib-team problem.

  • You may want to add more TVS diodes, specifically for RJ45 and USB ports (unless they're only for development).

  • Net classes should be used to enforce high-voltage and high-current rules. Currently, high-voltage traces have the same DRC rules for spacing as I/O, and high-current traces have the same thickness requirements as I/O. This leaves a lot of room for human error in the design.

Layout

DFM

  • I don't see any fiducials for SMT assembly. There should be at least 3.

  • Beware of the potential for counterfeit/grey-market parts from LCSC. I've purchased from them before, but only for hobby-projects. For a commercial product, it incurs some risk.

  • There are a lot of DRC errors. They should either be fixed or waived to indicate that they've been reviewed and acknowledged as OK.

  • These large capacitors might not have enough solder-paste to get a good joint. Spacing them further apart would allow for solder-paste stencil expansion (larger than the pad).
    image
    image

  • These annular rings are really thin, and have close spacing. This'll make them really tough to solder.
    image

  • If screw-heads are going to make contact with the PCB, there should be no copper underneath. Soldermask isn't a reliable insulator.
    image

  • These traces between pins might appear to AOI as a short. I'd remove them.
    image

  • The aspect ratio of 8:1 (1.6mm PCB thickness : 0.2mm drill hit) is expensive. Your PCB will be cheaper if you can tolerate a larger min. drill hit.

  • Is the physical stack-up correctly defined? I assume not, since all the dielectrics are set to the same thickness. Pre-preg is usually a lot thinner than core.

  • VMOT will be a lot harder to solder than GND on this connector. They should be the same: either both having thermal relief, or both having direct-connect.
    image

  • Having so many testpoints near the TH pins will make selective-soldering or wave-soldering impractical.
    image

  • All of the bigger mounting holes are currently set up as PTH with no annular ring. The board-fab will complain about this. They should either be NPTH (mechanical) or PTH with a suitable annular ring.

Signal Integrity

  • In a perfect world, there should be a reference plane for the bottom-layer traces. As it is, the bottom-layer references the GND plane, which is far away (weaker coupling) and has a signal layer (layer-3) in between. This creates the opportunity for cross-talk/EMI problems, so it needs to be looked at carefully. Here are some areas where cross-talk could occur (parallel traces on bottom-layer/layer-3). Eliminating parallel runs doesn't guarantee that cross-talk won't occur (adding a good ref-plane is the proper solution), but it'll help.
    image

  • You can also get cross-talk between traces on the same layer. I'd consider spacing out sensitive signals (like these ADC lines) away from power traces.
    image

  • The USB diff-pair transitions from top-layer (with a good ref-plane on layer-2) to the bottom-layer (with no local ref-plane on layer-3 and no transition vias) and back to the top. This creates two gnarly impedance discontinuities. For USB FS, this might be tolerable, but for HS, it might create problems.

  • Assuming that the physical stack-up data is correct, the differential impedance of the USB diff-pairs are way off: approximately 130-150 Ω versus a target of 90 Ω. There are many simple calculators that you can use to get close: KiCad's built-in calculator (left) and Saturn PCB Toolkit (right) are two options.
    image

  • Having 3V3 near your diff-pair will impact the impedance. If you don't want to worry about modelling that, you can increase the clearance between planes and diff-pairs.

  • CAN is differential and expects a target differential impedance of 120 Ω. I see a lot of variance in the diff-pair spacing and poor reference planes. CAN is pretty tolerant, but I'd check against the CAN spec you're designing to and plan to test the signal integrity/packet error rate.

  • I'd check if CAN can tolerate using CATxx and RJ45 connectors (100 Ω differential).

Power Integrity

  • Joining the 3V3 rail in the following places would make it more continuous (less loop inductance). This can be accomplished by shuffling vias and traces.
    image

  • Ideally, there shouldn't be large "fingers" of planes connected at one end, as they could act as antennas. I'd look for parts of 3V3 pour that aren't serving a purpose (don't connect to anything) and remove them.
    image

Thermal

  • If either of these packages generate much heat, I'd remove the thermal reliefs from the vias connecting to their GND pads.
    image

  • Arrays of smaller vias definitely help share the load of high-current, but without careful planning, you can get uneven sharing of current. The first rows of vias may get the lion's share of the current, and the further away ones may barely make any difference. This can lead to premature failure (vias heat up, thermally-cycle, or worst case actually blow open). The gold-standard way to design around this is with simulation of the copper structures (2D or 3D) to check for current distributions. A few open source options are Elmer FEM or FEMM. Otherwise, the next-best-thing is to over-design the vias so that they can handle multiple factors of the expected current, but this might be impractical for the density.
    image

Safety

  • I noticed that your schematic calls out 100V caps or the VMOT rail. As such, I'd carefully review the creepage/clearance requirements (IPC-2221B is a reasonable place to start, but you can also consult a test-lab like UL) and set up appropriate net classes and DRC rules to get correct spacing. For example, the spacing between GND and VMOT here is only 0.3mm. I don't know if this is OK.
    image

Cheers!

Noob question gerber files

Hi, I found your design interesting and would like to try it out, but Im not able to order boards as I cant seem to find how to order. Im missing gerber files zip jlcpcb requires.
Could you add this file for users like me who havent used to pcb design?

Thank you for you help.
Edmundas

BOM upload

I was curious about getting some boards made up by JLPCB.

I opened the project in Kicad and used this plugin https://github.com/Bouni/kicad-jlcpcb-tools to generate Gerbers & BOM. eg BOM-RP2040_motor.csv

When I upload these files to JLPCB 56 of the components are not automatically detected.
56
I guess this plugin may be buggy/incomplete? Is there a better way to do this?

Could you upload a BOM where JLPCB auto-detects all the components?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.