Oh, well then, (cough) nevermind. 
Go to know.
1 Like
They are currently reworking it. They released it for a while but it has motor detection issues among other things so they are reworking it and the pre-order is now for the reworked model. Iâd definitely wait until someone has the new one in their hands before ordering or getting some good info from @YUTW123
2 Likes
Check out the Axiom project. A 100kW vesc based controller. Yes you read it right 100KW
2 Likes
Great project! I hope it materializes!
Yeah they sent an email update about 2 weeks ago and they will soon start selling it⊠Its gonna cost a pretty penny thoughâŠ
2 Likes
Yeah, thatâs to be expected, but if it is competitive with proprietary EV motor controllers, it should be fine.
Compete more or less with a sevcon gen 4 size 6
2 Likes
Proprietary EV controllers will more or less work better unless the axiom makers addressed the glaring firmware issues.
It wouldnt work with certain (perhaps many) motors too; the observer is meant for SPMSM, larger EV motors are IPMSM and exploit reluctance effects. So if they wanted it to work with IPMSM they would need to do a firmware rewrite anyway.
If anything, Axiom should have forked the Odrive instead, imho. That codebase has precision servo control and trajectory planning.
3 Likes
I believe with Marcos and Arlin on board and already multiple iterations of the controller successfully running in Arlinâs Honda CRX and keeping on ever making higher power on it (100kw is only the conservative rating for this controller), everything will be fine.
They made their own sensing logic too to avoid sensign errors we currently face with âsmallâ VESCs and on top are working on bypassing the whole ADC sensing scheme with their FPGA⊠Power stage is golden too.
Axiom is on another level, period !
5 Likes
FPGAs are not analog front ends and most do not have very powerful analog front ends, do you mean they replaced the entire computation with an FPGA? If thats the case, then I donât understand why even fork the VESC. Just use TI instaspin or something if you canât be bothered to implement FOC yourself. Bigger motors donât need faster computation to run, so there isnt really much to gain moving to FPGA unless you really need to prove deterministic behavior. Cant use switching frequencies higher than 25Khz with igbts.
In fact Xilinx has IPs for motor control as well.
Power stage is usually typical igbt array. You have to reduce the switching frequency because igbts dont play nice at high frequencies.
This post will summarize better than me what theyâre doing with the analog signals processing. I cannot tell in details what theyâve altered in the commutation process, however theyâre planning on cleansing most of the ADC circuitry currently used by direct digitalization almost from the phases, so there would be minimal to non relevant drift between power stage and the STM32 proc.
FPGA would handle most of that âdirect digital stageâ, on top of already being used for extra safeties.
Ok, they are using a sigma delta modulator as the data acquisition stage.
And emulating a RISC-V core in the FPGA to implement SINC low pass filters.
This make me shake my head honestly, itâs pointless. If youâre going as far to implement a CPU in the FPGA just implement your own FOC algorithm!
And if youâre going this far, ditch the VESC and either use an industry proven (and honestly much more robust and reliable) algorithm like Texas Instruments Instaspin, or write your own. The extra $10 for TI instaspin is a drop in the bucket at this point.
I literally implemented an accurate and QUIET signal injection algorithm with a data acquisition stage whose SNR is less than 1! nevermind the fact that it starts up backwards half the time
Iâm using lowside shunts and instrumentation amplifiers, that good enough for implementing a 17khz signal injection algorithm and standard FOC control. There is no switching noise in the measurement, because if there were, signal injection would scream at me.
I am asking myself
why, why, why.
I think SAR ADCs sampling in zero vectors works fine, but if theyre going this far, just use the FPGA for everything.
The new MCUs like the H7 and the G4 have zero vector insertion, for sampling at the switching frequency.
There are fast slew rate instrumentation amplifiers, but you donât need anything above 90% duty cycle for EV anyway, so that opens the door to many instrumentation amplifiers.
You can use two, three, or more current shunts in parallel, with their kelvin connections tied with 1k ohm resistors so that the difference is averaged when fed into the instrumentation amplifier.
Because the sensing is lowside, you can use larger resistance and/or lower power rated current sense resistors because their power dissipation is now halved.
The accuracy of the resistors is irrelevant because they carry no current.
Thatâs all your error problems gone. offset errors can be compensated for in software at boot.
As an example
Heck, they donât even need to average multiple shunts.
500uohm shunt with MCP6N11-010 with gain set to 10 gives a ±330A sensing range.
We donât care about common mode rejection because the common mode is 0V in a lowside configuration.
input filter of 220ohm and 100pf will reject any switching noise that makes it into the shunt, because switching noise is on the order of MHz and this input filter rejects everything above 500KHz.
Worst case input offset is 350uV, less than 1A worth, and can be compensated for easily.
The zero vector insertion feature of the STM32G4 and STM32H7 PWM timers allows for sampling at the switching frequency. I am sampling at 34KHz. They switch at 18KHz. max duty cycle of 90% (it doesnât even need to be that high even) gives 2.5uS for the input filter and amplifiers to settle, and another 2.5uS to collect samples. You can even delay sampling to give the amplifier more time to settle. The amplifierâs worst case small signal settling time from the graphs in the datasheet, extrapolating for 3.3V supply, is around 2uS.
Error chain. Shunt accuracy 1% + Amplifier Gain error (use 0.1% resistors, theyâre not even that expensive, sheesh) ~0.5%. + input offset error (uncompensated) + 12 LSB + ADC uncompensated error (they still have this) ~10 LSB (or whatever from the datasheet)
The accuracy of the input filter is irrelevant because itâs an instrumentation amplifier.
Itâs under 5%.
Their solution will work.
In my opinion, it is not the best solution, but others will disagree with me.
I have to detect a ± 1A swing at 17KHz, and do some black magic on it, not sure how, but it works.
TL:DR if youre going to go as far as implementing the entire digital section of a sigma delta ADC in an FPGA, just implement the entire control algorithm in the FPGA. FPGAs can generate PWM with complementary output and just about everything else you find on an MCU. Chances are your own implementation will work much better.
Otherwise, SAR ADC with lowside sensing works just fine, especially since newer MCUs allow for zero vector insertion for updates at the saming frequency. Switching noise is either blocked by the input filter of the amplifier, or beyond the bandwidth of the ADC.
The sigma delta modulation basically gives you flexibility in when you want to execute the control loop and how to handle data, but I honestly donât see the benefit of such increased comexity.
I actually deal with the issue of having to send raw data through different filters for different parts of the control algorithm.
Raw data is fed to observer, a cascaded set of filters are used for signal injection, and a single order low pass filter is used for the current regulation.
4 Likes
Reading this made me get coronavirus. Srsly I feel so dumb rn 
2 Likes
Learn a little at a time and eventually stuff starts to make sense. I would say I am about 3% knowledgable with so much to learn. Instead of studying and building I go out and ride instead in my free time.
1 Like