So I’m an embarrassingly poor guy. My wage is $20/h for studying retirement 
.
Donations welcome
$250/hr is a price for the people who thinks they are “clients”, like @jonhp who seems to consider himself a “client” because he downloaded KiCad (although I doubt he would’ve ever chipped in for the development). As many people already remarked here, most of KiCad devs work for free (myself included) and we are happy to fix bugs, add new features and generally improve KiCad - but some users seem to expect us to do exactly what they desire, disregarding our personal goals. This is not how open source software works, at least not community-driven open source.
Back to the autorouter - this is not something that can be coded in spare time for free to have satisfactory results. We don’t want to have a poor quality autorouter making a big mess of wires just because some other tools have one. Not to mention that - at least to me - investing my personal time for autorouter development is not really a goal I would like to pursue, I design PCBs (sometimes quite complex) for my living and quite frankly, never needed to autoroute anything. There are cooler things to work on, like improving the push&shove or guided routing which IMHO are much more useful and also bring fun and fulfilment to the devs.
Tom
PS. If somebody wants to contribute a quality autorouter to KiCad - our doors are always open, but please, write it in C++ (GPL or LGPL), without a ton of external dependencies and without patent/copyright issues or generally ‘shady’ legal status (like Freerouting).
PS2: Since we started talking about prices, here’s an example price list:
9 Likes
Hillarious price list 
…and pad stacks, and a decent symbol/footprint/library management, and a property inspector, and tracks & zones in footprints, and … (fill in the blank).
I totally agree with what you say. Not that that would effect anything, but anyways…
@twl first I need to apologize for the use of the word “client”. I use it interchangeably with “user”. I will, in the future only use the term “user” when referring to KiCad. And your assumptions are incorrect. I have contributed (USD) to the KiCad develop several times; although not lately I am embarrassed to admit (I will correct that ASAP).
But I am confused about your view of “user” input. In your view, is it of no value?
Is an autorouter not a “…new feature…”?
There are current “features” that I have no use of; but I haven’t asked that they be removed or abandon. Since you don’t need an autorouter, then by your argument we should all fall inline even though some of us have such a need.
This discussion seems to confuse what the developers personally want to work on and what features are wanted by some subset of users. But I am getting a better sense about the ultimate future of KiCad.
And one more thing about this dialog. I thought it was a technical discussion about autorouters but it has unfortunately devolved. I feel badly about that.
Jon
PS I would also remind everyone that not all “users” are code developers!
1 Like
I love auto routers. Doesn’t mean I can’t route. Just means I love auto routers. Personal attacks have absolutely no place here.
We really hate to close threads which is why I added the edit to the title. I can appreciate everyone’s input, BUT, auto route isn’t going to happen anytime soon and the reasons have been given numerous times.
3 Likes
Great, thanks for contributing (and my apologies for the wrong assumption).
I think every input has value, but its actual merit depends on the viewpoint. We (the Kicad devs) have to consider various factors when choosing what to code, e.g. time it will take to develop a particular feature, the cost of manpower, the technical complexity of the feature, maintenance burden, etc. Also adding new features means a lot of changes “under the hood” which the end users rarely see and often take most of the development time.
Yes, it’s technically a new feature, but its cost (in the terms of hours spent coding and testing, maintaining, fixing bugs) does not justify the benefits. I believe the features mentioned by @straubm (inspector, pad stacks, etc) would have more impact and will cost less to develop and maintain. Convince me if you think I’m wrong
I’m only trying to explain why KiCad doesn’t have (yet) an autorouter. It’s a matter of managing priorities given the resources we have.
Well, I’m both a user and a developer. It’s sometimes good to see how things look like from both sides. As a dev, I understand how complex is the task of designing a moderate quality autorouter, as a user I don’t see much added value compared to e.g. property inspector or guided/push&shove routing
Tom
1 Like
some times ago someone started an interesting project, using kicad_pcb as a base for an autorouter…
The-OpenROAD-Project/PcbRouter
We are working on a (for now) standalone placer, router, DRC checker (for advanced constraints), and a decompactor. The idea is to be able to autoplace and autoroute a BeagleBone Black type design within six months. This means 6+ layers, BGA microprocessor, DDR3L memory, USB, HDMI, eMMC, and so on.
The tool is written in C++ with a Python API and is available to play with here (GitHub - The-OpenROAD-Project/PCB-PR-App
If I recall correctly, @Seth_h tried to be in contact with them…
Yeah, the openROAD project is interesting. They are focused on chip layout/design. The spin-off of their research into a pcb layout autorouter was potentially useful. But it was just a PhD project that never got picked up by anyone after the lead author graduated.
As @twl mentioned, Autorouters are highly technical and involve an enormously complex set of mathematical skills to correctly implement. If KiCad can grow to the point where we can hire PhDs out of school to build/maintain this, then autorouters become a possibility. Until then… well, others have answered.
I think the difference between cost and benefit of the autorouter vs. other features is not very clear to those who aren’t familiar with the problem area.
The technical complexity of developing an autorouter that is good enough that (some) people would actually want to use it is likely greater than the complexity of all the new features planned for V7 and beyond, combined.
Autorouting is seen by most people as a convenience feature rather than a “must-have”. When you consider that we do have a number of “must-have” features (as considered by a number of users) on the roadmap, and we could implement all of them with less effort than an autorouter, maybe it makes more sense why we do not prioritize working on an autorouter.
6 Likes
Obligatory xkcd
1 Like
An auto-router is a large undertaking. Obviously depends how far you take it though.
Push and shove aside takes a lot of work.
I dont use Kicad but do use an auto-router then spend next half hour fixing what it did !
I did find a “route track segment” function useful so I can step through track segments one by one and route them then fix them if necasary. Short tracks tend to get routed well but long tracks can often end up too complicated and long. So I just autoroute the short tracks.
The main problem is that an autorouter is actually worse than useless until it gets REALLY good. And I have yet to meet a really good PCB router (VLSI routers are a different story).
The big problem is that PCB routing is a quite unbounded space. Routing can be anywhere from completely rectilinearly orthogonal to totally weird angles for signal integrity reasons (ultra high-speed lines have to worry about intersecting the PCB weave for too long as it changes the electrical permittivity). Most PCBs have through vias so a via is an obstacle on most layers. However, blind or buried vias are normally not obstacles on uninvolved layers.
I can go on and on ad nauseam.
I’m really happy the developers of KiCad have punted on an autorouter. It’s a useless development time sink on every PCB program I’ve ever used that had one. The only downside is that it’s a “marketing bullet point” that the competition will use to beat KiCad up when people try to adopt it in professional settings.
4 Likes
For me it would be much more helpful to route “parallel” tracks, for example to route SPI you need 4 wires that start and end in almost same locations. If Kicad could follow 3 wires where I place one that would be a great help and decrease routing time 3x.
6 Likes
This kind of bus routing isn’t autorouting, it has even been in developer plans, but nothing has yet come out of it.
Yes, semi-auto. There are even some rudiments of this: differential pair routing. So it’s not as huge in terms of development to extend this feature to multiple tracks (with relaxed length requirements) from just two strictly equal tracks.
Some time ago (several months) I saw someone developing a KiCad plugin for lenght tuning of mutiple tracks, like data/address buses, SPI etc.
It’s not in the main development, but a step towards the kind of functionality, I would think.
1 Like
CircuitMaker is apparently now supporting KiCad 6 import and has updated documentation:
CircuitMaker 2.2
Released: 15 June 2022 - Version: 2.2.1 (build 6)
Released: 6 April 2022 - Version: 2.2.0 (build 5)
KiCAD Importer
Among other importers available, CircuitMaker includes the KiCAD® importer and supports importing the following design files:
- KiCAD Project files (*.pro, *.kicad_pro)
- KiCAD Schematic files (*.sch, *.kicad_sch)
- KiCAD PCB files (*.kicad_pcb)
1 Like
But it’s with Altium thus has costs. Am I wrong?