That is the same thing. You choose the application and certain suitable pre-sets are made according to your application. In other applications other pre-sets would make more sense. There is simply no one solution that defines a safe basic standard for all environments. It all depends on the point of view. As @NuRxG stated: For mono-wheels things look completely different. In future we might see even new inventions that would hate a 85% pre-set or that would face safety issues with that pre-set. Before mono wheels existed, we did not think about them… Let’s see what the future brings us and what settings are required then.
4 Likes
It’s not the same thing at all.
One is having a default that has more physical safety for users of Type A and doesn’t perform as well for users of Type B. The other – is having a default which includes high risk of personal injury for users of Type A, and slightly better performance for users of Type B.
Defaulting to “less risk of personal injury” and then increasing the performance if the user isn’t Type A — is totally different (and better) than defaulting to “more risk of personal injury” and then reducing it if the user is Type A, which is what you are suggesting.
If the user doesn’t use the wizard or any other thing happens, the default should be less personal injury risk.
10 Likes
Aside from that, this is merely a “default default” than can even be overridden for each different hardware if they choose to, and even then it’s only a default and can easily be changed by the user or by a wizard.
It’s a no-brainer. Less personal injury risk is better than more personal injury risk. Convince me otherwise
1 Like
What you consider less risk can be more risk for others. That’s my point. So it’s best to have risk eliminating choices for each application. There are so many points of views and yours is only one of many. A monowheel that stalls because of 85% pre-set is not nice for the rider…
1 Like
While I can’t speak for other riders, I’d personally prefer stalling over supermanning.
Give your customers a survey and see what they actually want.
6 Likes
Fantastic you bring this up.
- Default to 85% Duty Cycle Current Limit Start and offer a way to increase/decrease it
- Default to 100% Duty Cycle Current Limit Start and offer a way to increase/decrease it
0 voters
8 Likes
Hmm,
where’s the “do a circuit analysis to identify minimum necessary sampling window and hard limit the maximum duty cycle to accommodate that value” option?
This is ESPECIALLY important on lowside shunt configurations.
2 Likes
ever heard of idiotproofing? an invention should always implement a way(s) of preventing injury or death, even if it means of reducing ones performance. not saying that any of us is idiot, but it should be considered in the first place, u never know who is using the software and also how they are using it
5 Likes
If you know the exact use case it would be simple…
Unfortunately you don’t know what those devices will be used for, so a setup wizard with the minimum of questions to answer is the way forward.
3 Likes
So then if you’re using a wizard there is even less reason to keep the unsafe defaults, not more.
But should someone configure it without the wizard, maximum safety over a marginal performance increase seems like a no-brainer. And those can all be changed anyway. But forgetting to change it should default to safest way possible.
2 Likes
What you consider unsafe is the safety for others and VS. Each application differs and there is simply no golden idiot standard. Your view is skate biased. This single setting is just one of many! Which combination do you personally prefer and which do others prefer in other applications? There is no golden standard that defines a perfect idiot safe base for everyone. The best way forward is to define a most idiot safe basic setup for each application And forget about a single biased point of view. You ask some questions and the most idiot base standard of settings is then loaded. And the point to start with is application neutral.
1 Like
Ask your customers, put up a survey on your website.
3 Likes
Our customers range from space to deep see applications.
3 Likes
yes, that’s why
4 Likes
Set a lowest common denominator
The “configurability” is a selling point for a reason
1 Like
BTW if you’re actually selling to space,
Then you should be using a rad hardened MCU like the SAMV71Q21
3 Likes
Depending on whom you ask, you get different answers and there is no one shoe fits all answer.
Even in skateboarding the opinions differ big time.
Lowest common denominator is non existent in motor control. It is a very complex topic and the VESC environment is the first OS solution that allows many different people and startups to control their motors the way they want things to be. So wizards and pre-sets will become more important in future. This way we can define a good starting point and speed up the setup process and make things safer for the user.
4 Likes
Idk dude, Texas Instruments figured it out.
https://www.ti.com/microcontrollers/c2000-real-time-control-mcus/applications/instaspin.html
It’s the industry standard, you can find it from power tools to tesla model 3 inverters.
7 Likes
@Trampa
The issue for me with high duty cycle limit is not the sudden loss of torque when reaching full RPM (you seem to think this is the one and only issue)… It’s “the wiggles” throwing you of the board during acceleration.
The wiggles that is caused by the motors going into some oscillating mode… which for some people happens during full accelerations with fw5… BEFORE any significant high RPM is reached.
It’s possible you cant experience this using Vedders escs (or maybe you dont push the throttle enough) but other HW has reported this issue with fw5.
So… This is the main issue with having 100% as default in vesc tool… its not safe. At least according to me an my dual motor submarine.
Q: What risks to human have been seen from other areas than eskate when using a value lower than 100%?
7 Likes
Could be that some hardware has issues with oscillation. Hard to tell without having a direct comparison in between different HW. On our units we can push full throttle at any time without any issues. Full acceleration tests are what we do as standard. Our team riders love to hold down the throttle…
If you experience wobbles on certain HW, you can try to play a bit with the time constant value during detection.
2 Likes