Is there any ongoing discussion on improving autorouting and autoplacing in kicad? Even just gradual incremental improvements strike me as saving a lot of time and effort from manual work.
I keep hearing that autorouters aren’t as good as routing by hand. I’m trying to find where people are trying to change that.
There is no autorouter in KiCad. There is an external program called freeRouting that is not part of KiCad. I don’t know if it has a forum.
There are a lot of forum posts on autorouters. The general feeling is that for most cases autorouters need careful setting up and the results are often rather unsatisfactory.
KiCad used to have a very basic autorouter in versions 3/4. This was removed as it was not of very good quality.
It is possible to export a .dsn file to an external router and read the routed results back in. Usually, Freerouting is the router of choice. There was some issues about this and legal challenges were made against the author. Unsurprisingly it wasn’t maintained although there are a number of spin off versions now available.
KiCad has a very good push and shove router. It is worth trying out. Good placement takes longer than the routing.
They’re not. And if you don’t understand why
autorouters aren’t as good as routing by hand
you won’t be able to contribute anything.
What is a .dsn file and how do you make one ?
Wherever it is, it’s not here! Because “real engineers do not eat quiche” 
Pcbnew: Export > DSN
later:
Pcbnew: Import > SES
.dsn - Spectra file. Export from pcbnew.
Surely the existing autoplacer could use some improvement?
Again that is problematic. How do you indicate placement in your schematic? For instance you want your decoupling caps near a microcontroller. You can draw them in close proximity in the schematic but that then clutters the schematic. Oftentimes you put the decoupling caps on a separate sheet, maybe with the power supply - how do you then associate them with the microcontroller?
There is this script that can be used to place components according to the eeschema layout.
There’s a plugin that mirrors the schematic placement on the PCB which is better than the random pileup as a starting point. This assumes also that the user generates sensible schematics. But autoplacement is hard because there are factors that cannot be expressed mathematically, e.g. external constraints on component position, and so forth. Try placement on a board of yours and you’ll see why it takes the lion’s share of the effort.
As near as I can tell, the easiest thing is to place the externally limited parts first, then select the rest and press the “autoplace” button. The current results aren’t great, but maybe with better heuristics?
Well Pcbnew has Python bindings for plugins so feel free to have at it. But I think you’ll need to pass it more metadata so that it knows this is a connector, this component is symmetrical and can be rotated, etc.
The benefit of an autoplacer wouldn’t be that it would find final or correct places for footprints.
It should help keeping the mental connection between what I see in the schematic and what’s in the layout so that I can find quickly what I need to find in the layout when I start placing the footprints, hopefully putting together footprints which will be close together in the final layout. Often the functional blocks in the schematic are reflected in the blocks in the board. At the moment KiCad utilizes hierarchical sheets, but if one sheet has many blocks it doesn’t work. Therefore “place like schematic” plugins can be good.
At least for the sort term, I see the most benefits in extending the Interactive Router with (possibly scriptable) autorouting functions.
For example, you start to route a track manually to break out from a BGA, then route it a bit to a side, and then use a funtion to "autoroute it to the nearest pad.
This does a few things.
Routing and traveling salesman problems have nothing in common except that they both can be expressed as graph problems.
I’m trying to find where people are trying to change that.
You have to change minds.
Autorouter software couldn’t possibly route a PCB correctly, identifying and placing decoupling caps next to microcontrollers and avoiding all kinds of rules-based engineering problems. Meanwhile SpaceX is vertically landing rockets on floating barges, Google has self-driving cars with tens of thousands of miles on them, and we can tell a computer to replace Jack Nicholson’s face with Jim Carrey’s in The Shining and it just does it. But Autorouters will never work. Sure, Jan.
Call me when the computer
see where I’m going with this?
it’s certainly possible a deep learning approach will improve autorouters substantially. but you HAVE to recognize that if you put an expert human layout engineer in front of kicad with an unknown project open, they’d be stuck. because there is SO MUCH KNOWLEDGE about the design and constraints of the system that isn’t and never will be contained in the pcb layout file.
Not only that, the complexity of tasks is often completely misuderstood by laymen
Writing software to land a rocket vertically on a dime? Couple of students can do that. Engineering a rocket that is capable of doing that? Takes billions of dollars and years for a team of pros.
Autorouters are the same. Generate tracks to connect the netlist? Relatively easy, done already. Place components in an efficient manner? Virtually impossible because information is not there. Can it be improved with machine learning or other advanced techniques? Sure. Will it ever be as good as experienced EE? Not in the next 20 years.
Not sure if “never”, but if eventyually you’ll succeed making an autorouter that outperforms an experienced PCB designer (without any prior knowledge/preplacement/rule definition), let me know, I might be interested in working for you
PS. I can’t understand why people complaining the most about the lack of autorouter are usually those who place an atmega with a few LEDs and have troubles routing this by hand