[Benjie Holson] is an experienced roboticist and wrote an interesting article published on IEEE Spectrum about how the idea most people have of non-roboticists is a myth, and efforts to target this group with simplified robotic frameworks tend to be doomed.
Now, let’s make a couple things absolutely clear right up front: He is not saying robots shouldn’t be easier to program, nor is he saying that non-roboticists literally do not exist (of course they do.) The issues he’s highlighting really come down to product design.
[Benjie] points out that programming robots is super hard, but it’s also hard in more than one way and for more than one reason. And when people try to create a product to make it easier, they tend to commit two big product design no-no’s: they focus on the wrong hard parts, and they design their product for a vaguely-defined audience that doesn’t really exist. That group is the mythical non-roboticist.
These are actually very solid points to make in terms of product design in general. Designing a product that solves the wrong problems for a poorly-defined group isn’t exactly a recipe for success. [Benjie]’s advice on making a truly effective and useful API framework that genuinely lowers the bar of complexity in a useful way is similarly applicable to product design in general.
His first piece of advice is not to design for poorly-defined amorphous groups. Your product should serve actual needs of actual users. If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.
The second is to design as though your users are just as smart as you are, just less tolerant of problems stemming from rough edges like compatibility and configuration issues. Remove those so that your users can get useful work done without having to re-invent the wheel, or resort to workarounds.
Robotic frameworks like ROS are useful and extensible, but whenever someone attempts to focus on creating a simplified framework, [Benjie] says they tend to step on the same rakes. It’s a mistake [Benjie] has committed himself, and see repeated by others. We think his advice is good product design advice in general, whether for designing APIs or something else.
This article was prompted by a friend of mine asking for help on a board with an ESP32 heart. The board outputs 2.1 V instead of 3.3 V, and it doesn’t seem like incorrectly calculated feedback resistors are to blame – let’s take a look at the layout. Then, let’s also take a look at a recently sent in design review entry, based on an IC that looks perfect for all your portable Raspberry Pi needs!
Here’s the board in all its two-layer glory. This is the kind of board you can use to drive 5 V or 12 V Neopixel strips with a firmware like WLED – exactly the kind of gadget you’ll want to use for LED strip experiments! 3.3 V power is provided by a Texas Instruments TPS54308 IC, and it’s the one misfiring, so let’s take a look.
The design has an ESP32 on the opposite side of the switching regulator. For review purposes, let’s pull the regulator circuit out – disable all front layers (copper, silk, mask, courtyard and paste), hide vias, then box select the regulator circuit and move it out. I’ve also added net labels to the circuit – here’s a screenshot.
There are things done right here, for sure, and a few things that could be the culprit in improper regulation. If you want hints, you can see TPS54308 datasheet, page 22, for layout recommendations. Both SW and FB nodes are pretty long, and the FB trace goes right next to VOUT – before regulation.
Furthermore, from the pinout and also the layout recommendations, it appears this regulator is designed in a way that all switching circuitry can be. Yet, this design has the inductor go all the way to supposedly sensitive side. Thankfully, this is easy to fix.
Refresher – FB and SW traces have to be as short as possible, inductor as close to SW as possible, and the VOUT to FB connection can be a separate tracks on the other layer. With that in mind, let’s move the inductor to the other side of the regulator, move the FB resistors to the FB pin, and see how far we get.
This is my take. FB resistors moved to one side, switching components to the other, VOUT track on another layer. Add capacitors and vias as necessary, and pull tracks under components to get extra ground connections if needed. Of course, ideally, SW would be a copper polygon, and so would be VOUT. I’m also showing how EN could be pulled out, in case you needed that – in this particular schematic, EN can be safely left floating, but most regulators will want you to pull it either to VIN or to GND.
Since this is a TI chip, it also has a diagram for the layout recommendation! Let’s take a look how far off the mark we are, and it appears we aren’t that far. Curiously, it wants us to put SW onto another layer. Having switching current pass through extra inductance doesn’t sit right with me, personally, but my guess is that they want to minimize switching current flowing under the regulator, as the recommendation suggests.
Another part that’s curious to me, is a suggestion for a Kelvin connection for the FB net’s GND pin. TI also publishes data for evaluation boards, and the TPS54308 has such a board indeed. Seeing on the page 13 of the evaluation board datasheet, I’m not quite seeing a Kelvin connection, unless Kelvin is the name of the engineer involved in designing the board. I do see that GND is tapped with a via far away from the area where switching happens, so it might just be that.
At this point, I’m curious whether my take is a dealbreaker, but since TI’s recommendations are available, I might just end up implementing exactly that and sending the files back. So, we take this circuit, implant it back into the board, order a new revision, and keep our fingers crossed.
A week ago, [Lukilukeskywalker] has shared a board with us, asking for a design review. The board is a stamp that houses a LTC4040 chip, and the chip itself is a treat. It takes 5 V, outputs 5 V, and when connected, it generates 5 V from a battery. It supports both regular LiIon, can do up to 2.5 A, and appears to be a perfect option if you want to power a Raspberry Pi or any other 5 V-powered SBC on the go.
There are a few small nits to pick on this board. For instance, the connector for the battery is JST-SH, 3-pin, with one pin for BATT+. 2.5 A at 5 V means 12.5 W means up to 4 A at 3.5 V battery level, which might just melt a JST-SH connector or the gauge of wire you can attach to a JST-SH-sized metal contact. However, it’s switching regulator time, so let’s take a look at that specifically.
Here’s another thing you might notice immediately – lack of ground path from the IC’s ground connections, all the way under the switching path. In particular, the switching path is broken by a few traces, and it doesn’t appear that these traces must be there! Page 22 in the LTC4040 datasheet, which lists the layout recommendations, also stresses upon this, elaborating that “High frequency currents in the hot loop tend to flow along a mirror path on the ground plane which is directly beneath the incident path on the top plane of the board”.
Well, there are only two tracks that really interrupt the switching path above them, and both could be moved to the left. One of them is for a resistor that sets the charging current limit, and another goes to a castellated pad. Moving the latter is going to break the symmetry, but remember – it’s okay for a stamp to be asymmetric, that helps you ensure it’s mounted on your board correctly!
Sadly, while Linear Tech makes fancy tech, their evaluation board data isn’t as available as TI’s – there’s a PDF with schematics, but no layout data I could find. However, comparing to the pictures, you can see that the general layout of the switching area is correct, our hacker correctly uses polygons, the feedback circuit is pretty nice – it’s just these two tracks that are a bit uncouth when it comes to the switching regulator part of it. As for reviewing the rest of the board, you can read this article!
Got switching regulator designs that didn’t quite work right when you put them to test, or that you’re yet to order and feel cautious about? Show them to us down below in the comments, and let’s take a look; your circuits deserve to operate at their best capacity possible.
And, as usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.
Our PCBs greatly benefit from cases – what’s with all the pins that can be accidentally shorted, connectors that stick out of the outline, and cables pulling the board into different directions. Designing a case for your PCB might feel like a fair bit of effort – but it likely isn’t, thanks to projects like turbocase from [Martijn Braam].
This script generates simple and elegant OpenSCAD cases for your KiCad PCBs – you only need to draw a few extra lines in the PCB Editor, that’s it. It makes connector openings, too – add a “Height” property to your connector footprints to have them be handled automatically. Oh, and there’s a few quality-of-life features – if your project has mounting holes, the script will add threaded-insert-friendly standoffs to the case; yet another argument for adding mounting holes to your boards, in case you needed more.
Installing the script is a single line, running it is merely another, and that will cover an overwhelming majority of boards out there; the code is all open too, of course. Want some more customization? Here’s some general project enclosure tutorials for OpenSCAD, and a KiCad-friendly StepUp tutorial. Oh, and of course, there’s many more ways to enclose PCBs – our own [Bob Baddeley] has written a guide to project enclosures that you are bound to learn new things from.
We thank [adistuder] for sharing this with us!
For plenty of computer users, the operating system of choice is largely a middleman on the way to the browser, which hosts the tools that are most important. There are even entire operating systems with little more than browser support, under the assumption that everything will be done in the browser eventually. We may be one step closer to that type of utopia as well with this software tool called CADmium which runs exclusively in a browser.
As the name implies, this is a computer-aided design (CAD) package which looks to build everything one would need for designing project models in a traditional CAD program like AutoCAD or FreeCAD, but without the burden of needing to carry local files around on a specific computer. [Matt], one of the creators of this ambitious project, lays out the basic structure of a CAD program from the constraint solver, boundary representation (in this case, a modern one built in Rust), the history tracker, and various other underpinnings of a program like this. The group hopes to standardize around JSON files as well, making it easy to make changes to designs on the fly in whatever browser the user happens to have on hand.
While this project is extremely early in the design stage, it looks like they have a fairly solid framework going to get this developed. That said, they are looking for some more help getting it off the ground. If you’ve ever wanted something like this in the browser, or maybe if you’ve ever contributed to the FreeCAD project and have some experience, this might be worth taking a look at.
Conectar