AXIOM is still in development but every day it gets closer to realization. The enclosure with integrated liquid cooled heatsink has been fabricated. Revision 2 PCB has been created and assembled. We are getting ready to build up the first 5 units and put them on the dyno. Exciting!
reach out to us at sales@powerdesigns.ca for more information
Another performance contribution to VESC from powerdesigns!
Now that we earned some deep insights about the inner workings of IPM machines, lets recap what is MTPA about.
MTPA stands for Maximum Torque Per Amp, which means that for a given current flowing into the motor phases it produces the maximum torque possible. We'll find out the benefits doesn't stop there.
Typical FOC implementations will drive flux-producing current (id) to zero and map the user throttle directly to the "torque generating current", (iq). This works great for cheap, non-salient SMPM motors that have a constant inductance throughout a complete revolution, but its not the complete picture.
Motors commonly found in automotive applications (Nissan Leaf, Tesla M3, BMW's, etc) are IPM motors with large reluctance that need a special algorithm to maximize the potential of the machine. Lower power IPM motors are also seen in high reliability and high dynamic range applications because the magnets aren't just glued to a surface and because they have a nice and extended constant power range.
So, will this improve my ebike or skateboard? Well, probably not much, cheap motors have usually very low saliency.
The torque equation
From the torque equation you can draw a few conclusions:
iq=0 will always produce zero torque
id doesn't produce any torque if (Ld-Lq) is zero (an outrunner motor for example)
There is an optimum id,iq setpoint that maximizes the torque
The end result is something like this that shows each torque component.
Because id,iq are 90° apart from each other, if id=0, the resulting vector angle is 0°, meaning no reluctance torque is produced. When we start adding id the reluctance torque increases, and the total produced torque becomes the sum of both traces.
The most valuable part
By far the best thing we got out of this is understanding better the motor control theory. We developed math and reproduced equations and tools to produce a d-q axis plot of any IPM machine.
This is for example a customer's IPM motor for a custom-made extreme density motor controller we made for them.
On a quick glance you can see at once:
the ideal MTPA trajectory (red)
how salient the machine is (how tilted the red trajectory is)
the current limit you are operating on (green)
the voltage/speed limit ellipses (blue)
the torque profile of the machine (orange)
and once you understand it you can easily see the exact id,iq currents needed to operate at any allowed speed/current target.
We also found the limitations of conventional Field Weakening algorithms and why they need to be improved if we want a linear throttle response on an IPM motor.
Side benefits!
MTPA is not only about increasing torque. The addition of id current also increases the full load base speed of the machine in the same way Field Weakening does. So you have more torque, more speed, and hence, more power!
In the Nissan Leaf motor, the improvement is huge. You can see the peak power operating point shifting from the right circle to the left towards a smaller (higher speed) ellipse while intersecting a higher torque torque curve.
That's right, this algorithm provides:
25% extra speed
38% extra torque
73% extra power
Implementing the optimization
You can search in the literature the details of the math to find the optimum id, iq (involves derivatives). In order to find the peak torque it boils down to this equation:
So the firmware will take the current reference is and separate it into the optimized id,iq components.
We added to the GUI the single parameter that controls the MTPA algorithm:
The Ld-Lq parameter can be measured from the vesc command line or by manually searching the peak torque on a dyno.
Besides that there were a couple of errors in both VESC firmware and in Texas Instruments app notes that had to be fixed in order for MTPA to work.
You can see the code details in the pull request to merge the new feature
The pull request comes after long testing sessions. Let's see the algorithm in action:
In this real time plot you care about Q current (red) and D current (blue). A simpler FOC controller would keep D current at zero, but we can see how D current increases to increase the net torque in the MTPA region.
That's a light testing at 400 phase Amps, but we are regularly testing all our firmware improvements at 800A and have well exceeded the 100kW target even at lower than rated battery voltage.
A typical 800A dyno run looks like this:
And a sneak peak at a dyno run, with the motor under test on the right side:
So that's it, VESC can now make a better use of IPM motors
This is a fun video, arlin giving a once over of his dyno setup used to test AXIOM at 100kW! We have lots of testing to do yet, but thought you might like to see an update from us and to know this project is alive and well. Cheers!
If there is something we can't complain about is a lack of demand and kind words!
Since we presented Axiom we got a constant flux of requests from individuals, about 200 direct requests were handled (9 in the last 7 days for example) and our newsletter has 300+ subscribers which is impressive because we are talking about a high end piece of hardware.
Let's see more details:
Most requests came from individuals looking for converting their own vehicles to electric, from old hondas like Arlin's to Beetles, BMW's and even an Audi R8 supercar.
Some were companies in very niche markets
Big underwater robots and vessels
Jet boats
Vehicles for mining
EV conversion shops
Aircraft startups
Sportsbikes startups
Wind generation
Glider launchers
There are Axiom controllers already in the (slow) order queue of a couple of billion $ marketcap companies diving into the future of electrification.
Research teams are also keen to have an Axiom as a tool
2 formula SAE teams got their Axioms
R&D departments at universities
Electric motor manufacturer
And there is the community, which makes it possible that a fleet of thousands of small VESC controllers in the field are piling up miles of continuous firmware testing. Those may lack a fancy and expensive LTE network, but the VESC platform has a ton of users happily reporting issues in the forums.
The Axiom development and documentation in the hackaday platform also made possible to get our team in sight of other big companies that need some very special motor controllers with specs and qualifications that Axiom is not meant to meet. If we actually land one of those contracts I would bet that the experience will influence Axiom development to make it even better.
Enough words, let's see a couple of beta testers in action:
VESC Tool has built-in functions to program and plot load tests like this one performed in California
Abricosvw testing and learning (we all learned from his experience).
300V 300A flowing somewhere in Europe
I lost some cool videos from pymco.fr with my phone, but PYMCO was the early partner of Axiom and I personally handed them control boards in both vacations and honeymoon! They were the first ones to drive a REMY motor with a VESC.
Axioms has been sent for prototyping and R&D to Turbotech in France
700Amps somewhere in India
Somewhere in Africa there are mining machines needing an Axiom on each wheel! This customer is waiting for the control boards to ship and they are ready to start testing.
This CRX is Arlin's, but very similar to another car that is powered by an Axiom. (note the motor reaches max speed for that battery in 60 milliseconds)
And this is in our bench showing a somewhat representative testing like a customer would do, they only should add a mechanical load. This was filmed last year when automated tests were not yet coded into VESC Tool.
A critical customer, or should I say partner, is Benjamin, the VESC architect itself who is planning to jump on board of an Axiom next week to turn the power to eleven.
So far the beta test stage covered all 5 continents! And these are actual markers:
Besides technical feedback and some bugs discovered during the beta program, we found that some of the customers really want to have HALL position sensors. That feature was purposely excluded from the schematic because we consider it not safe for a high power application, but we listened so a plug-in extension with safety isolation was tested and shipped to provide hall sensor inputs at their own risk.
Another lesson learned is that when the customer makes its own DC Link capacitor it doesn't end well, so we have been offering a DC Link custom designed and mechanically matched to Axiom, the second small batch is getting shipped to us tomorrow.
Surprisingly so far no one cares about an enclosure. Most applications either don't need an enclosure (the electronics are already in a safe place) or the enclosure is so special that it has to be custom made by the customer. We are designing one anyways, but it was an interesting note.
Its hard work but we love it and it feels good to know we are in the right path doing the right thing.
Our last episode covering the FPGA capabilities deserved a quick followup to shed some light into what's coming next in the hopefully near future:
Icestudio GUI getting huge improvements
Hardcore developers will handle any problem with any fpga using any language to get things done. For the rest of us, its neat when the user interface is friendlier than a bunch of HDL files.
Several updates happened to the icestudio.io project, with massive speedups showing up in the nighties. This speedup is allowing to work with really large FPGA projects.
Lets see a couple of examples from the developers mailing list. The list is in Spanish so its good to unearth that huge effort and show a bit what's going on there.
Z80 processor + peripherals
This is not just a drawing, this is the actual view in the ice40 Icestudio editor. You can actually drop a Z80 CPU, UART, RAM, Bootloader and GPIO blocks into icestudio. Verify, synthesise, and upload to the target is a breeze.
Yes, this is really happening, in a fully open source FPGA toolchain! It was about time, after all we were promised 2019 was the year of the FPGAs!
RISC-V + peripherals
Z80 not cool enough for you?
There is a RISC-V core available and passing tests on the ice40 devices, together with a UART, RAM and external flash management ready for you to discover and try out. Kudos to Obijuan for sharing this demo!
The coolest bit of this is that you can use gcc to compile C code that runs in this softcore, and the code example is awesome, directly accessing your custom "peripheral" from the address map:
You can see it doesn't need any fancy include, and when you consider it was you who built the whole cpu logic, its just mindblowing.
An actual motor control application
Alright alright, that toolchain is very cool, but how does it benefit my motor control application? The main point of Axiom having an FPGA is to digitize earlier the analog signals. These digitizers are footprint compatible with the AMC1302 iso-amps currently installed which are actually delta sigma converters but they convert the signal back to analog domain. By swapping them you can digitize right at the High Voltage domain, and it stays digital until it reaches the microcontroller for field oriented control calculations.
What's the benefit?
First you can ditch all these analog signal processing components, they are a big chunk of the BOM and pcb area!
All these components can be removed if Axiom goes digital
Not only they add cost to the BOM, but most importantly they add ageing, temperature and tolerance drifts; supply rail variations and EMI will creep up into the measurements, and in these critical applications, every parameter drift has to be studied to perform the design assurance our big customers are already requesting. For example if the signal chain has x2 opamps, x7 1% resistors and x4 10% capacitors, you can calculate the worst case scenario in which the signal chain will have 10% of error. That's likely unacceptable, so you run a Monte Carlo analysis that tells you that 99.8% of the boards will meet <5% tolerance, but now you need to test every board under various conditions looking for the 0.2% that needs to be scrapped or somehow tuned.
Enter the digital signal path
Everything we did in the analog domain we can do it in its digital counterpart. Drop a delta sigma demodulator block, a sinc filter, a decimation filter and you are ready to go. This takes only a few hundred logic blocks.
This signal chain and its benefits are well documented in this article by Analog Devices
For the hardware overcurrent/overvoltage comparators there are methods that will detect the incoming fault within 4 us with a few logic gates. That's usually done by branching off another filter from the 1-bit stream but with quicker response time. So for example if you get seven "1" in a row that can be enough to indicate a fault condition and shut down the drive, and for safety standards this count as "hardware-based protection".
Repeat the signal chain 7 times (x3 currents and x4 voltages), send the data over high speed SPI and you're done. Most current sensors have analog outputs, but we already developed a current sensor with delta sigma output that is actually lower cost than its HALL counterparts.
You can sync the sampling exactly on the center of the PMW activity like the MCU does, and by tweaking a bit the OSR you can place notch exactly at your pwm freq, removing a lot of noise from your signal.
Analog's article goes in depth explaining how the impulse response attenuates the weight of the samples taken at the switching times.
Noise near switching events weigh less after going through the impulse response of the sinc3 filter
We have run our own math to produce the correct combination of modulation frequency, oversampling and decimation to locate the notches in the digital filter chain at exactly 18kHz which is our target switching frequency. Need a different frequency? Tune a few parameters and you're ready to go.
The response plot you get is nothing short of amazing:
Not only you get a notch in your 18kHz, but all the harmonics in the green plot get notched-out
Basic tests and results were promising - no one got hurt! -
Yellow channel: Delta Sigma output of a 100Hz sine
Sinc3 filter and decimation was developed in verilog, ready to be replicated in the system:
Icestudio makes testbenching easier, and results are shown in gtkwave
Testbench of Axiom delta sigma demodulator+sinc3 using real data from a sensor
If we really go down this path we can drop in the 144 pin STM32F4 that can expose the full bus on the pins and gain instant access to the data as a directly memory-mapped area instead of SPI.
So this is a peek into the future of Axiom, the groundwork is ready but its a steep development effort that requires quite a bit of funding, and right now we are really busy with documentation for the future users as the current embodiment is already earth-shattering!
Even if the VESC platform was born in the green and thriving lands of Sweden, the Axiom project found its roots in much less fertile soil.
This particular log is likely going to go over the heads of the folks living in developed countries -even my newfound Canadian mates-, but I think it can resonate a lot on the rest of us.
There are many great stories about large companies being born in a garage near Silicon Valley, but for many of us a garage in a developed country is a dream, you can't help but feeling hopelessly excluded from the aspiration of achieving such great feats.
Like most people in this community, I started working with my mate Maxi in my dad's garage. But our garages come with some extra handicaps, they are located in a ̶d̶e̶v̶e̶l̶o̶p̶i̶n̶g̶ collapsing country that has been edging populism for years. Argentina has been home of brutal customs paperwork and requirements to deter people from ordering stuff from other countries (think digikey, a pcb, or a fancy oscilloscope), plus 50% of import taxes and the recent come back of the immediate "pesification" of the income we get from international jobs (it means that if you charge $100 for a prototype, it gets converted to a devaluating AR$, you never get to hold USD, even if you need to order stuff in USD to do the job). The concept is to take money from the productive sector to fund government affairs, so being productive here takes way more effort and willingness.
After we got our engineering degrees we started the search for contracts and good ideas. We landed a nation-wide award for a top 5 most innovative product and all that $ was invested in setting up our current Palta Tech lab and a corporation figure that can import stuff. You may imagine a sci-fi lab... and you would be right!
Meet our Batcave in Argentina
That's the current google street view, It took us an entire summer of sanding the old paint, preparing and painting the inside, the award couldn't afford the paintjob (much less pavement!). The lab outside is nicer looking now, but google won't notice for years because they don't come here often.
Having a workplace we focused on the actual work, contributing to VESC, earning some traction in the forums, and meeting amazing people like our canadian mates Arlin and Sonny, and the oh so fulfilling development of Axiom, which made our team an international, far reaching endeavor. We still ship boards from Argentina, but with a new company in canadian jurisdiction we are trying to leave behind the struggles.
It takes years of (extra) effort to get you this far when you live in a poor country, and this log has 2 purposes:
To serve as inspiration to all those hackers and makers that keep creating despite adversity.
To raise some awareness about how awesome and valuable it is to have a makerspace near you and same-day tax-free no-BS shipping! Makers around the world don't take these resources for granted, many have to build labs from the ground up, design their own CNCs and deal with customs and government BS to stay competitive.
I don't know if there are other hackaday prize finalists emerging from a non-developed country this year, certainly not many. Hopefully this will help more outsiders getting into the business!
Many times we designers face an unassuming challenge. Pick the latest and greatest part... or go the old way and pick a less fancy part that gets the job done.
In this design the design for manufacture is important, and that includes the analysis of potential supply chain shortcomings.
In particular, the neverending issue of parts getting out of stock right before you hit the big red "MFG" button.
This could be less of a concern if the board had 10 or 15 types of parts, but with 100+ lines in the BOM, the odds are against you.
We can classify the risk of a non-stock line according to the damage it creates to the production schedule. For example if a resistor goes out of stock you can easily change the part#... but if suddenly your microcontroller goes unobtanium you are screwed. What's the cost and time required for software migration, testing, and pcb update and re-tooling? Hint: its very non-zero.
So for Axiom there are only a few dangerous components in this regard, and we can show the countermeasures we have taken:
MCU: A shortage of STM32F405 would be a disaster for a product like this, as the firmware despite making extensive use of ChibiOS its still heavily interwinded with low level peripheral access for max performance, so no easy migration.
Luckily we have a viable replacement that is the STM32F407, which is pretty much the same die with an ethernet peripheral. It can be more expensive but you don't care when you're against the ropes handling a shortage. Also, these ST oldies are ubiquitous and heavily stocked, it would be super odd to see a shortage.
FPGA: In general I find most HDL design software to be full of crap, so going for an open source toolchain gives some peace of mind here, as you could be locked away due to licensing for example. Then there is regular part# issue, which is actually what triggered this log.
Right now the super cool and amazing FPGA Axiom uses is non stocked in the major suppliers, so one would have to start poking the manufacturers or the shady suppliers that apparently have the part but you never heard of them. But here is where the strategy shines, we have already identified this as a possible issue and early in the game we developed the verilog code for a different family of fpga that happens to be pin compatible, and I assembled, tested and validated the board with the alternative part, so we were always ready for a shortage.
Connectors: Here's the weak point in our supply chain. Even if JST connectors, and Amphenol RJ45 - 4 port assemblies are common, there are no alternatives in the current design, so in case of a shortage its likely that we will need to update the pcb design and have a talk with the assembler about the change. This little deviation can easily translate to a $200 fee. At least there is no software development involved and likely no need to update the user manual.
IGBT's: This is another example of a part that can become difficult to source. The IGBT listed in the BOM is currently out of stock, but this is where the choice of using EconoDual becomes evident: we can easily use another part with the same package! So for now we upped the part voltage from 650V to 1200V, but there are many options, even a 1200V 1000A part is available (more about that in a future episode)
Power supply: You'll see that the LDO has non populated feedback resistors, thats because it allows to use the adjustable version in case the fixed 3.3V version goes dark. It also allows to run the MCU domain at a bit higher voltage, like 3.45V to have a bit better signal/noise ratio on the analog frontend (this has been validated on consumer grade boards but not for the high power builds).
The DC/DC supply already went through alternative mosfets, thanks to the common footprint used and the switcher IC comes in both Automotive qualified and industrial grade variants.
CANbus circuit: We had a few comments about that part of the schematic, like why did you choose discrete isolator+CAN phy? The answer is... supply shortages! We don't want to tie ourselves to fancy parts like the ISO1050, we use easily replaceable discretes.
So I hope you see where is this going, we really care about the present and future of this product and the platform it represents, and we want it to be relevant for many many decades. This kind of documentation is not something you will see in a product datasheet or in a user manual, and represents real value to our customers. It's no joke when we say its meant to be the next-gen motor controller.
As our project followers already know, Arlin Sansome has started re-building his world record breaking Honda CRX for higher power, higher performance with Axiom Motor Control. In this video Arlin shares the motivation for this project, describes the Axiom Hackaday project and shows a sneak peak at our first full up motor controller prototype (more on that later). For now, please enjoy the video and be sure to ask your questions and leave your comments here :)
Marcos
This signal chain and its benefits are well documented in this 
Analog's article goes in depth explaining how the impulse response attenuates the weight of the samples taken at the switching times.
