09/24/2019 at 15:51 •
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.
09/22/2019 at 15:06 •
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!
Until then, have fun!
09/14/2019 at 20:21 •
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!
09/10/2019 at 02:35 •
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.
08/24/2019 at 13:46 •
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 :)
08/22/2019 at 03:18 •
It took us long enough, but we have finally converged to a releasable schematic!
Take a look for yourself:
I really don't remember seeing a schematic this complete, clear, complex, and public! Most of the team worked at aerospace and military organizations, so we know a thing or two about these documents and that experience was put into practice here. It is released under a Creative Commons BY-SA license.
Take for example a simple component like any of these capacitors.
Is the capacitance important? Of course! Is the rated voltage important? You bet!
A wrong capacitance value can be harmless, or detune a timing or filtering circuit. But using a 6.3Vdc capacitor on a 15Vdc rail will have dire consequences, hence the need to be verbose when drawing the schematic and be clear about the used ratings. You don't see this often in public schematics.
Resistors power rating present us a similar case. Take for example the CANbus termination resistor:
Can it withstand a continuous bus failure? If we are clear about the power ratings we can see that the termination resistor pair can take 500mW.
5V on a 120 Ohm resistor gives 208mW, so it should be alright. The DC Link discharge circuit needs to pass this continuous bleed check, with some extra safety consideration regarding discharge time.
Then you have the more common practice of drawing the signal flow from left to right, for example in the signal conditioning circuit (there is one of these blocks for each phase):
Many people asked about the FPGA implementation, and its a straightforward one.
It is configured over SPI, pwm signals are level shifted from 3.3V to 5V for better integrity under high EMI. The SPI bus can be used for high speed general purpose communication between MCU and FPGA. The ice40up5k eval board had some errors that were fixed in Axiom schematic regarding PLL supply filtering and power supply sequencing.
So there you have, an earth-shattering, high quality 34 page document meant to bring electric vehicles and high power motor control closer to everyone!
PS: Schematic was first released days ago to our newsletter subscribers. Subscribe now to hear first about Axiom news!
08/17/2019 at 03:41 •
You can have it good, fast, or cheap. Pick any two. Good and fast, it will be reliable but expensive to design. Fast and cheap, probably going to end up with something that causes fires rather than drives an EV. Cheap and Good is possible but it’s going to take some time to deliver. Obviously there are many design decisions made along the way of producing a final schematic and bill of materials for a high performance full up motor controller. But how are those decisions made? That is the focus of this log post.
And it turns out.. it's not that hard. During the initial project meeting EV Power Designs asks the client what are their top three priorities. Cost, weight, volume, performance, reliability, protection from obsolescence, manufacturability, time to market and so on. OK, I lied. It's hard; because after all don’t we want it all? Pick only three? This simple question tends to bring out a lot of discussion about the client’s expectations, desires, goals and general philosophy. The client gets to hear about how each design objective will influence the actual product so there is an appreciation both ways. Client and consultant get an opportunity to better understand the project but more importantly, each other. From this conversation, the three .. yes only three.. top priorities will eventually be ascertained.
Here is an example of how narrowing down the product development philosophy to three key drivers can help with decision making. Let's say the three most important goals are Weight / Volume / Cost (typical for new power electronics design where time to market is not a key factor). How does this impact the decision for torque control, arguably the most important function of a motor drive? Depending on the power level there are a lot of different design paths that will lead to lower weight, volume and cost but at all power levels it's possible to reduce the phase current sensor count from three to two. The motor load is still 3-phase, but the current in only two of three phases is measured for control purposes. The current sensor required for high performance motor drive is relatively expensive because it must be high bandwidth and low error so removing one out of the system saves a lot of cost. And the thing is rather large and heavy because of the internal ferrite core, so weight and volume come down as well. It's a win… win and win. but. As my old professor used to say, you never get a free lunch in engineering. There is a small price to pay to have higher performing op-amps that are now required for adequate design purposes, and with only two sensors the system will never be aware of circulating currents and thus never have the ability to eek out some more performance by nulling out the circulating current. Or in other words… with only two sensors, the system just became lower performance. Thankfully, in this example, performance wasn’t one of the top three design goals.
We applied this same philosophy to the Axiom control board design process. What three top priority goals should we have? Performance, reliability and versatility.
08/06/2019 at 20:21 •
It’s tough to get through hundreds of projects, here is some help!
i. Is this a unique solution to a particular challenge facing the world today?
There are lots of motor controllers out there, good, bad and ugly.
There are few motor controllers capable of moving a car.
There are no open source motor controllers capable of moving a car and pushing the boundaries and reach of electric vehicle technology like Axiom does.
And the world certainly needs to get good at this, motors are driving our civilization and comprise most of the energy usage, we need to accelerate our motor control tech. The best way to drive the technology forward is to open it up to the world, open source, and let all the clever and hyper interested people join together in one reliable, high power, high performance, flexible platform we’ve called Axiom.
ii. How thoroughly documented were the design process & design decisions?
I’m sure you’ve already read the project logs and really appreciate the magnitude of our work. The core work of the Axiom project is the schematic, bill of materials and main processor firmware; all open source. Although it only took a few weeks to generate the schematic and bill of materials, they are based on nearly two decades of intense professional design for high performance electric vehicles as well as commercial and military aircraft. In fact, the team members came together on a side project (managed by Arlin Sansome) to help with some of the motor control technology elements to push the boundary beyond reasonable limits, directly into world record breaking limits. Needless to say there is a wealth of experience on the team which allows for generating working schematics in a short period of time. The design itself is heavily documented. Simulation using Matlab/Simulink and PSpice helps to define circuit functional basics to system integration. MathCAD/Smath was used for much of the advanced analysis such as electrical stress, component sensitivity and tolerance analysis.
iii. How ready is this design be taken to market?
Several individuals, companies and universities are already stretching the muscles of their Axiom drives. We have been selling beta boards and complete controllers for a few months now to get early feedback while simultaneously building up some operational hours to prove out the design. We are expecting to take the product to market in 2020 for turn key 100kW motor drive power.
iv. How complete is the project?
Axiom is a complex convergence of mechanical engineering, electrical engineering, thermals, firmware, software, safety, racing, distributed work, user interface, artwork and the will to meet the most challenging requirements.
The Axiom control board product is already complete, working to control a limited number of high powered motor drives all over the world and will be available with all the bells and whistles in a complete high power, high performance, full up motor drive in 2020.
i. Concept- Is the project creative, original, functional, and pushing boundaries? Does the project benefit society in some way?
Axiom sports a creative assembly to simplify the production, it's been proven by many customers, not to mention the thousands of smaller controllers out there using the same VESC software we use and contribute to, and it is fueling the boldest high power applications not only electric cars but also turbogenerators, bikes, ROVs, big machinery and more.
If Axiom succeeds in its quest, the whole world will become better at spinning motors -one of the major energy consumers-. Pushing the boundaries is exactly where the Axiom product positions itself. An earlier version of the hardware broke the world record for fastest front wheel drive car on the ¼ mile¹. In fact, Arlin is currently working on the next iteration using Axiom to reaching higher and pushing boundaries further²
ii. Design- Is there a depth of design detail available (like a system design, CAD models, project test methods, etc)? Is there base-level planning for the functionality (eg: functional block diagram, list of specifications and how they will be met, etc.)? How user-friendly is the design?
Glad you asked! Block diagram, schematic, enclosure, powerstage validation, safety mechanisms, a datasheet outlining the specifications and application notes describing how it all works in a full up controller. But that’s not all, there’s also an awesome open source graphical user interface (GUI) making motor setup easy and providing tools for deep data analysis.
The electronic bits of the full up motor drive are established. What we are still working on is how to package the product such that it is quick to assemble while remaining visually stunning.
iii. Production- Is the project reproducible (consider materials, skills, and processes)? Are the manufacturing processes detailed? Are those processes realistic for scalability?
Axiom has been designed from the ground up to be easy to assemble, reducing wiring, parts and streamlining the setup of each unit.
A single sided control board, its friendly bill of materials, and very standard manufacturing processes are in place for production. The Axiom control board is already in limited production, populated and tested using automated means. The control board is designed for drop in place into the full up motor drive to be offered by EV Power Designs Inc. Ease of assembly is paramount to long term success as a product. We are currently working on good packaging so that the Axiom control board can be quick ‘drop in’ installed along with all the other components that make up the complete motor drive.
iv. Benchmark- How well is the project impact and viability demonstrated? Are estimated costs realistic? Are direct, indirect, and future competitors clearly identified?
The best way to gauge axiom success is with the sheer amount of requests, multiplied by the fact of being in a premium and high margins market. The Axiom control board has exact pricing for producing in batches of 10, fully populated, firmware loaded and product tested. The full up motor drive, which uses Axiom control board, also has a completed bill of materials with exact pricing, assembly and functional test costs included. The only part of the full of 100kW motor drive that has not yet been confirmed is the mechanical enclosure but we have some promising quotes.
In terms of viability, the best proof is if there are interested buyers in many markets. We get requests for pricing and availability every day from individuals working on a hobby project to large corporations looking to jump start their R&D division. We take this as a positive sign of product viability.
There is really no need to compete with low prices, as Axiom simply delivers better what the market needs: a powerful and reliable motor controller that can be deeply tuned to your needs.
v. Communication- How thoroughly have the final round requirements been completed? How well documented is the project? How “Open” is the design? Is the project marketable?
Documentation is key for our customers so we have a datasheet, a full schematic available, bill of materials, 3D models and 150.000 lines of open source firmware, software and toolchains for our customers to build upon. We have an application note that describes how to include the Axiom control board into a full up motor drive. Furthermore, we also sell the complete full motor drive including our custom made DC link capacitor and Axiom control board. We believe the product is highly marketable for two reasons. The automotive industry is huge and moving into “all electric” at a staggering pace.
The marketing campaign will get shocking when we get to show the sheer power of Arlin's honda CRX powered by 2 Axioms and the list of customers test driving an Axiom in their own unique and interesting applications. We are hopeful to have the opportunity to learn from Supplyframe’s knowledgeable staff and industry contacts to help this marketing and advertising campaign make productive business to business connections.
07/18/2019 at 22:19 •
Because we can have nice things
Consider your regular dayjob (or dayhobby) of using an Axiom-based controller. You are likely dealing with a silly amount of current, or voltage, or both, and you have to *work* with that while being safe. It is also likely that you need to work on more than one motor drive at a time, for example when you have an AWD dual motor honda CRX, or a one-motor-per-wheel setup with torque vectoring, or you are just stress testing 10 drive units in a test facility and you want them in a network.
In those cases, the good'n old USB interface of the vesc platform just doesn't cut it because a compromised isolation barrier in one controller will expose your computer to unsafe voltages.
For those cases we equipped every Axiom board with a couple of isolated CANbus interfaces: its the safest way to interface with a motor drive, providing a second isolation barrier with super low capacitive coupling for highest noise immunity.
And when you need to address several controllers, well, CANbus is the perfect protocol as it allows to send or receive commands from any node in the network. Within milliseconds you can send torque commands to 4 controllers in the bus.
But there was a missing piece in the VESC platform: you couldn't directly connect to a CANbus with the VESC Tool GUI.
Native CANbus support for VESC Tool
See here our Pull Request that adds native support for a can interface. You can discover all VESC's in the network, connect to one and perform firmware updates, realtime data acquisition, high speed sampling, motor detection, parameter config, etc, everything from the GUI.
This works nicely on linux. For windows support you may have to wait, code it, or hire someone to code it for you ;-)
It opens the door for proper instrument clusters
Something we want to address is data display. Whether its a sportsbike, a car, a plane or a jet boat (yes Axiom is already serving all those applications!) the human interface needs to be pretty, with Qt libraries we can do much better than a hacked gauge display
With VESC Tool codebase being capable of accessing the bus, it is now much easier to install a Beaglebone or a RPi in the vehicle with an industrial monitor and run a nice instrument cluster like this example from the internet that I compiled a couple of years ago on my old laptop.
Both VESC Tool and this example are based on Qt5 libraries. We hope to see some nice VESC displays in the future thanks to this
Update: we have a dashboard getting data from the controller:
In-house CANbus<->USB adapter
And here is the icing of the cake: every Axiom controller will come with a compatible CANbus<->USB adapter, using the open source candlelight firmware, and with perhaps the nicest build quality out there:
A few highligths:
- Aluminum shell. We machine it alongside the IGBT phase bars as they are of similar thickness
- UAVCAN compliant CANbus connector (SM04B-GHS). Its also the same used by Axiom
- Nicely embedded dipswitch to enable 5V bus supply, bus termination resistors and bootloader mode. This replaces the sloppy pin header jumpers.
- All the performance and features of candlelight firmware that now works out of the box with VESC Tool
I ordered some boards to assemble in-house, if they turn out good we can send a batch for mfg. Being the coolest CAN<->USB converter out there it should sell well, not only to Axiom users.
Note that the boards are panelized, with tooling strips that provide fiducials and alignment holes for the stencil and production line. By panelizing myself I make sure the long edges will not be V-grooved, I want them routed for a smooth finish. Also note the proper contact between pcb GND and the aluminum shell for better shielding.
UPDATE: Working prototypes!
As usual... stay tuned!
07/15/2019 at 02:50 •
“Shoot-through” is the name given to a failure event when two adjacent switches in a voltage source inverter are ON simultaneously thus short-circuiting the supply, as shown in Figure 1. This failure mode can easily become catastrophic especially in motor drive application where the DC link capacity is rather large and has more than enough stored energy to cause a fire if the shoot-through event is not extinguished within a very short time, typically 10µs for a rugged IGBT (other switch technology can be more sensitive and require even faster response times).
Figure 1: Shoot-through Event
It is interesting to note that the vast majority of the short-circuit current does not come from the traction battery back but rather the inverter’s DC link capacitor which has a very low impedance path between it and the power switches. This means that any current sensor between traction pack and the capacitor will not “see” the fault current and therefore cannot detect the fault. In fact, since there are no current sensors at all in the short-circuit path it makes detecting this type of fault challenging.
To detect a shoot-through event the gate driver (external to Axiom control board) employs a power switch “desaturation detection” circuit. The gate driver will immediately shut down the local IGBT when a desat fault is detected. When this first IGBT is shutdown the high fault current is extinguished before it becomes catastrophic and the Axiom control board will be notified so that its firmware can work to immediately shut down the other five switches, thus disabling the drive completely. Desaturation detection is a simple circuit, but its simplicity can often be mistaken for simple to design. The circuit must be 100% reliable in a high noise environment, be extremely fast acting and sufficiently stable over a very wide temperature range. Each component in a desaturation detection circuit is carefully considered and the PCB layout is similarly critically analyzed.
Now that the shoot-through event has been summarized, along with detection and shut down method, the next question is why would a shoot-through event even happen in the first place? Surely the control scheme is such that the processor would never issue ‘ON’ command simultaneously to two adjacent switches. No doubt this is the case.. but for unproven firmware, with well over 100,000 lines of code, its possible that a firmware bug may exist .. and its possible that such a bug could lead to errant command signals. More likely however is that noise from high voltage and high current switching gets coupled back into the control board causing unpredictable erratic behaviour, including causing a shoot-through.
Since the shoot-through event has the capability to be destructive it is well worth the designers time to invest an effort to prevent, however possible, the mis-firing of PWM signals. Axiom accomplishes this goal in several ways. The microcontroller firmware is based on proven code, used by thousands of users in a wide variety of applications. Despite this, Axiom makes use of an FPGA which monitors the IGBT gating commands to ensure, double ensure that the microcontroller does not issue errant PWM signals.
Figure 2: Overlap Protection Logic Circuit
The idea of this circuit is to allow the microcontroller to turn on its associated gate driver, either the top or the bottom, but never the top and the bottom simultaneously (shoot-through!).
The logic truth table is deciphered as:
Figure 3: Overlap Protection Logic Circuit Truth Table
In earlier revisions of Axiom the PWM overlap protection circuit really was implemented like this using discrete hardware. More recently the simplistic logic diagram is implemented in an FPGA (see previous log HERE)
Once the PWM has been checked by the overlap protection logic, it heads off to the Gate Driver board whose job is to turn digital PWM into a power pulsed equivalent to drive the IGBT. The Gate Driver board sits right at the interface between noise high power IGBT and sensitive digital and therefore becomes the most critical component to overall function. Members of EV Power Designs have been designing Gate Driver boards for high performance application for over 15 years, a version of which went into a World Record Breaking race down the 1/4 mile track. Hard experience has taught that a rock solid, highly fault tolerant, excellent common-mode rejection capability, desaturation detection, two-step turn OFF and other built in features are required for high power high performance motor drive application. Besides our own custom design which have these features, EV Power Designs also recommends gate drivers by Power Integrations (formally IGBT-Concepts).
With digital voltage on one side, high switching voltage on the other and a dielectric in between (plastic case of the opto-isolator) suddenly you have an effective capacitor injecting noise current through it (from switching high voltage gate driver to digital, noise current crawling over the plastic case. For lower power applications this is practically a non-issue, but high power its a real concern. Not all opto-coupler, gate drive IC’s or PCB layouts are up to the challenge. This concept, also applies to the gate driver power supply, specifically the transformer. Noise can travel through the parasitic capacitance here too, so less than 5pF input-to-output capacitance is desired.
Is the story done? There’s still one more major failure mode to be considered. It was previously mentioned the shoot-through current is extremely high and lasts only a short period of time (desat protection opens the circuit in less than 10µs), but that time is enough to charge the stray inductance of the fault current path shown in Figure 1. This could be represented schematically by placing the inductor symbol for the DC link capacitor (internal inductance + connection to IGBT) and the internal inductance + connection of the IGBT itself.. both of them, like so:
Figure 4: Stray Inductance in Shoot-through Path
The high current flows through the stray inductance(es) and then the desat protection circuit opens one of the switches to protect the system. As is well known to Electrical Engineers, the current in an inductor wants to continue to flow and when an inductor is suddenly open circuited, a voltage will spike to very high values in an attempt to keep the current flowing. At the power levels typical to Axiom, the stored energy is significant and the voltage spike can be destructive. The irony of the situation, the desat protection circuit worked but it caused another problem! Therefore the system has to be designed to mitigate this potential hazard as well. EV Power Designs has three solutions to contain the voltage spike within tolerable limits. Firstly, the Axiom control board was intentionally designed to mount directly to a gate driver from Power Integration (formally IGBT-Concepts) which was specifically chosen for its rugged construction and reliable fault management and that direct mounts on a very stray low inductance IGBT from Infineon. Secondly, EV Power Designs contracted a capacitor manufacturer to specially design a DC Link capacitor with very low internal self inductance. Thirdly, the proposed connection between DC link capacitor and IGBT switch is maintained at absolute minimal length with no need for external copper busing or snubber capacitor.
Figure 5: Full Up Controller Designed and Assembled for Minimal Stray Inductance
Multiple levels of protection have been designed into the motor drive full up controller to properly manage the threat of a shoot-through, or the voltage spike which occurs after a shoot-through event.
Deep Dive over, lets resurface shall we?