One thing i hate about the original vesc BOM, is that if a fault occurs, that make the vesc reboote, all your faults gets erased, so you dont have a change to figure out, what happen. Thats why data logging got my attention
Yes, I do agree that is an annoying behavior. I could do something like log the last 10 recorded faults to eeprom. Only tricky part would be no reference for when they occurred outside the session time since the unity does not have a real-time clock. Could also easily log them on the app-side but then you’d only have record of them when your app is tethered. Perhaps this is fine since normally people won’t be experiencing faults, and they can tether their phone and log data when they are trying to track a specific issue.
I like that you’re open minded regarding this issue…
Keep up the good work,
@Deodand Thank you for the video! I think it provided the information that we needed (for now ) ! Perhaps we could see a future Metr Collaboration or just a future Metr product that would fit in place of the Bluetooth module for seamless integration! That would be pretty cool! But that’s the future, for now, I think all of us just want the damn unity’s to start shipping! Thanks again!
@totalgeek9224 Couldn’t agree more. Can’t wait for these units to get in your guys hands. FYI @Blasto, @onloop and I all have flights booked for shenzen on the 9th of November to Shenzen, when we will go to make sure Unity production goes smoothly and also iron out any potential issues with raptor 2.1 production.
Let me tease one last feature for you guys that I’m super excited about implementing (disclaimer: currently it’s a concept with clear path for implementation). Probably only something nerds will enjoy. What’s exceptionally cool about this is it is something you can only do easily when running two motors from the same MCU since clock drift between two seperate MCUs would cause synchronous drive to not work. Vedder in the past has focused alot on bulk capacitance of the VESC and made some tools to analyze ripple current. Here is a video where he is demoing the tool to compute ripple current. In the video he states that the worst case loading is when the motor is being driven at 50% duty cycle (AKA half the max speed of your board). So the idea is… what if we drove each motor FOC phase 180 degrees out of phase. I.E. the peak turn on times occur perfectly out of phase between motor 1 & 2. At 50% duty cycle this would effectively eliminate most of the incoming ripple current. So I downloaded his open-source tool (Thanks again Vedder!) And modified it to see how this concept works. Let me show you some plots demoing this concept:
25% duty cycle:
50% duty cycle:
75% duty cycle:
(Note that I added 1 amp offset to total bus current for easier visibility of seperate lines)
By offsetting phases we can nearly halve ripple current for a dual motor setup, eliminating losses within the motor driver capacitors due to ESR, and battery leads from peak pulsed current. It should also reduce the likelihood of voltage dips since each motor essentially gets twice the bulk capacitance. Can’t wait till I have a spare moment to implement and test this feature.
That’s really cool, but wouldn’t the motors have to spinning at the exact same ERPM for this to work?
Nope! thats the cool part. the base frequency of pwm is always 20kHz (max 30 kHz for unity) regardless of erpm. Doesn’t change much if the motors aren’t in phase with one another. On a skateboard both motors duty cycle should be roughly similar since they will be spinning close to the same speed. The two motors pwms are actually already synchronized right now but they are currently in phase, one motor is in v7 while the other is in v0. Just need to fix adc triggering.
In the plots you can see the lower frquency waveform on top of the pwm frequency that’s the motor driving frequency.
I thought of that now and came back to edit
That’s only for FOC right? Since BLDC has variable pwm frequency?
Correct. But if your aiming for power efficiency you should be running FOC anyways.
Question, probably already asked, if i plug a metr module into the unity, will it just be two bt modules running on the unity? I imagine it’ll make the unity run slightly more
Will the final silicone cover be black or orange? I think black looks way cooler
hey so what’s the latest anticipated ship date? I’ve got a few builds that I’d like to complete and am holding out for the unity.
That is new hardware? Or firmware changes? Or just configuration?
Firmware changes, no delays here.
We pushed back our shenzen trip by a week to accomadate a slight delay, we will be there November 9th. The plan is to get Unities out the door by the time we are leaving around mid November.
Awesome, thanks for the update! Also helpful for me to time the sale of about 6 Focboxes lol
dope ! keep me posted so I can get them on my shop in EU !
By the way, I dedicate this video to the unity hard workers that made this possible. It’s a blast.
Just curious is the Unity effected by the current tariff schedule imposed by US on China goods?
Is the primary heatsink the aluminum casing or the top mounted finned aluminum piece? (ie if we need more heatsinking capability for hill climbs, do we add heat sinking to the top or bottom).
Probably about 75% of the heat is coming out of the bottom currently since there’s more direct thermal contact there. Probably increasing the heat sinking on either side would be effective as the whole case heats up pretty uniformly during prolonged peak current draw.