10S custom skate ESC: testers wanted!

Thanks. I tried the current .apk, but it fails to start properly (a message indicates "BLDCApp stopped" after a couple of seconds). The previous version (ui only) did work on the same device (Wiko kite) - I tried several thing with and without activating bluetooth initially.
 
Playing around with the VESC settings a bit, trying to understand what is what. Got rid of the little stutter, that was noticeable when crawling up the little slope in the test video I posted earlier, by increasing start-up boost from .01 to .03. Also changed the timing advance to map from 0-12 deg ("phase advance at BR ERPM" set to 0.6) between 0-30k RPM (60k ERPM), which is about the full RPM range the motor should be able to reach. For reference, here's the settings I now use with the APS 4092-1380 kv inrunner:

Code:
<?xml version="1.0" encoding="UTF-8"?>

-<MCConfiguration>

<pwm_mode>1</pwm_mode>

<comm_mode>0</comm_mode>

<motor_type>0</motor_type>

<sensor_mode>0</sensor_mode>

<l_current_max>80</l_current_max>

<l_current_min>-80</l_current_min>

<l_in_current_max>80</l_in_current_max>

<l_in_current_min>-20</l_in_current_min>

<l_abs_current_max>130</l_abs_current_max>

<l_min_erpm>-100000</l_min_erpm>

<l_max_erpm>100000</l_max_erpm>

<l_max_erpm_fbrake>250</l_max_erpm_fbrake>

<l_max_erpm_fbrake_cc>1500</l_max_erpm_fbrake_cc>

<l_min_vin>8</l_min_vin>

<l_max_vin>50</l_max_vin>

<l_slow_abs_current>1</l_slow_abs_current>

<l_rpm_lim_neg_torque>1</l_rpm_lim_neg_torque>

<l_temp_fet_start>80</l_temp_fet_start>

<l_temp_fet_end>100</l_temp_fet_end>

<l_temp_motor_start>80</l_temp_motor_start>

<l_temp_motor_end>100</l_temp_motor_end>

<l_min_duty>0.005</l_min_duty>

<l_max_duty>0.95</l_max_duty>

<sl_min_erpm>100</sl_min_erpm>

<sl_min_erpm_cycle_int_limit>1100</sl_min_erpm_cycle_int_limit>

<sl_max_fullbreak_current_dir_change>10</sl_max_fullbreak_current_dir_change>

<sl_cycle_int_limit>65</sl_cycle_int_limit>

<sl_cycle_int_limit_high_fac>0.6</sl_cycle_int_limit_high_fac>

<sl_cycle_int_rpm_br>60000</sl_cycle_int_rpm_br>

<sl_bemf_coupling_k>800</sl_bemf_coupling_k>

<hall_table_0>-1</hall_table_0>

<hall_table_1>1</hall_table_1>

<hall_table_2>3</hall_table_2>

<hall_table_3>2</hall_table_3>

<hall_table_4>5</hall_table_4>

<hall_table_5>6</hall_table_5>

<hall_table_6>4</hall_table_6>

<hall_table_7>-1</hall_table_7>

<hall_sl_erpm>2000</hall_sl_erpm>

<s_pid_kp>0.0001</s_pid_kp>

<s_pid_ki>0.002</s_pid_ki>

<s_pid_kd>0</s_pid_kd>

<s_pid_min_rpm>900</s_pid_min_rpm>

<p_pid_kp>0.0001</p_pid_kp>

<p_pid_ki>0.002</p_pid_ki>

<p_pid_kd>0</p_pid_kd>

<cc_startup_boost_duty>0.03</cc_startup_boost_duty>

<cc_min_current>1</cc_min_current>

<cc_gain>0.0046</cc_gain>

<cc_ramp_step_max>0.04</cc_ramp_step_max>

<m_fault_stop_time_ms>2000</m_fault_stop_time_ms>

<meta_description><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:8.25pt; font-weight:400; font-style:normal;"> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Configuration loaded from the motor controller.</p></body></html></meta_description>

</MCConfiguration>

Also got two more questions:

  • Is there a reason the default max duty cycle is .95? Would it harm to put it at 1, so it is really full throttle?
  • Is the soft RPM limit (current mode) working in the App Config / PPM tab? Should this be called ERPM, like all the other RPM related settings? What would be a good setting to keep the VESC in its happy ERPM range?
 
pf26 said:
Thanks. I tried the current .apk, but it fails to start properly (a message indicates "BLDCApp stopped" after a couple of seconds). The previous version (ui only) did work on the same device (Wiko kite) - I tried several thing with and without activating bluetooth initially.

Thanks make! I'll address this see what I can do!
 
Dr_T said:
Playing around with the VESC settings a bit, trying to understand what is what. Got rid of the little stutter, that was noticeable when crawling up the little slope in the test video I posted earlier, by increasing start-up boost from .01 to .03. Also changed the timing advance to map from 0-12 deg ("phase advance at BR ERPM" set to 0.6) between 0-30k RPM (60k ERPM), which is about the full RPM range the motor should be able to reach. For reference, here's the settings I now use with the APS 4092-1380 kv inrunner:
I think you understand the timing advance very well :)

Dr_T said:
Also got two more questions:

  • Is there a reason the default max duty cycle is .95? Would it harm to put it at 1, so it is really full throttle?

  • The reason is that the current sampling only can be done when the FETs are off since the shunts are on the low side and there only are two of them. With some tricks this could be increased a bit (97-98% maybe).

    Dr_T said:
    [*]Is the soft RPM limit (current mode) working in the App Config / PPM tab? Should this be called ERPM, like all the other RPM related settings? What would be a good setting to keep the VESC in its happy ERPM range?
Correct, they should be called ERPM, I will change that. You can keep them as they are unless you have a reason for using a soft speed limit. The reason I added them is in case I, for example, let someone else try my RC car/longboard/ebike and want to limit the maximum speed for safety.

All weekend and yesterday after work I have spent a lot of time on making the current sampling better, which is difficult. At some duty cycles the samples are affected by noise and aliasing that causes offsets, so getting the correct current is difficult. What I have right now that works best is a VESC where I changed two capacitors to filter the current more heavily. This reduces the offsets and noise, which most likely cause the faults you are seeing, but it slows down the slew rate so that the current samples on the positive phase become too low when the duty cycle increases. To deal with that I use the current from the negative side where possible (4 out of 6 commutations since there are two shunts only) and use slew rate compensation based on the sample time for the remaining two commutations. I also used some tricks on the sample time to reduce the problem with the default shunts. In a few days I should have a firmware that works better for your motor using the VESC as it is and possibly another firmware that works even better if you replace two capacitors. This has taken more time than I expected, but the improvements should benefit all applications for the VESC.

For the future, there are some hardware changes that I could make on the VESC to get good current samples and be able to run at 100% duty cycle:
* Use three low side shunts. Then I need another amplifier for the third shunt since the DRV only has two.
- Advantages: better current samples, 100% duty, still FOC compatible
- Disadvantages: Added cost, more space required

* Use two high-side shunts. This needs two extra amplifiers that have very good CMRR, which could be expensive (maybe 5 to 10€ extra on the whole VESC)
- Advantages: better current samples, 100% duty, still FOC compatible
- Disadvantages: Added cost, more space required

* Use two hall sensor based current measurement ICs on the high side.
- Advantages: Very good current samples, 100% duty, still FOC compatible
- Disadvantages: These things are quite expensive (10 to 15€ extra) and HUGE. Much more PCB space will be required.

* Use only one shunt on the minus input.
- Advantages: 100% duty, possibly better current samples, less space required, less cost because only one shunt is used
- Disadvantages: Removes the possibility to use sensorless FOC (sine wave control) in the future.

In general, I think the current hardware is a good compromise between features, space and cost. The difference with the above changes won't be huge and most users will not even notice that the current measurement is better. Having the last 5% extra duty cycle can sometimes be nice though. However, I think I can increase the duty cycle a few % with the current hardware if everything goes well.
 
Would like to repeat the below question since it got lost within the last posts. Anyone having an idea?

Vulthor said:
elkick said:
Maybe a stupid question, but nevertheless: I'd like to adjust some of my boards to make them usable for my kids (in secure environment of course, not for the streets!). Ideally it should be possible to program one of the nunchuk buttons (for example Z) with the capability to limit speed/acceleration and remain in that mode even after switching of.

How to achieve this for the nunchuk? Or a more simple attempt: what are the values I'd have to change in the BLDC tool to implement a general power limit?

There is no stupid questions then it's about safety, especialy for your kids.

Even I am interested in this question, i'm a new builder (work in progress) so can't help you but the question is legit :)
 
elkick said:
Would like to repeat the below question since it got lost within the last posts. Anyone having an idea?

Vulthor said:
elkick said:
Maybe a stupid question, but nevertheless: I'd like to adjust some of my boards to make them usable for my kids (in secure environment of course, not for the streets!). Ideally it should be possible to program one of the nunchuk buttons (for example Z) with the capability to limit speed/acceleration and remain in that mode even after switching of.

How to achieve this for the nunchuk? Or a more simple attempt: what are the values I'd have to change in the BLDC tool to implement a general power limit?

There is no stupid questions then it's about safety, especialy for your kids.

Even I am interested in this question, i'm a new builder (work in progress) so can't help you but the question is legit :)

Part of the answer actually is in Benjamin's response: you can limit max speed directly with the soft RPM limits we talked about above (sorry, typing on my phone and hard to browse to check how the tabs were called exactly, but theyre mentioned above). If you calculate the ERPM that corresponds to your desired speed, you can use that to directly set the top speed limit.

The motor and battery Current limits can be used to directly limit Torque and thus acceleration, and resulting top speed indirectly. I don't know how this works with a nunchuck controller, but if you are using a regular RC transmitter, I'm guessing limiting throttle end-points will do exactly the same if you are in current control mode.
 
vedder said:
I think you understand the timing advance very well :)

I really like the idea of RPM dependent timing, should be great for high speed applications. I think some new SkyRC ESCs were released that also allow setting RPM dependent timing, but most (all?) other sensor-less hobby ESCs I know of don't have it.

vedder said:
Correct, they should be called ERPM, I will change that. You can keep them as they are unless you have a reason for using a soft speed limit. The reason I added them is in case I, for example, let someone else try my RC car/longboard/ebike and want to limit the maximum speed for safety.

One of the reasons I mentioned the soft (E)RPM limits is that I thought it could be beneficial to slightly limit ERPM for the guys running the 270kv motors on 12S, assuming it was indeed the high ERPM killing the DRVs, as was speculated earlier. I'm thinking of setting my soft ERPM limits to start at 80k when using 7S on the 4092, just to be sure it does not rev up too high under low loads. With higher loads it won't ever see 80k ERPM anyway, so real-life performance would not be degraded.

vedder said:
All weekend and yesterday after work I have spent a lot of time on making the current sampling better, which is difficult. At some duty cycles the samples are affected by noise and aliasing that causes offsets, so getting the correct current is difficult. What I have right now that works best is a VESC where I changed two capacitors to filter the current more heavily. This reduces the offsets and noise, which most likely cause the faults you are seeing, but it slows down the slew rate so that the current samples on the positive phase become too low when the duty cycle increases. To deal with that I use the current from the negative side where possible (4 out of 6 commutations since there are two shunts only) and use slew rate compensation based on the sample time for the remaining two commutations. I also used some tricks on the sample time to reduce the problem with the default shunts. In a few days I should have a firmware that works better for your motor using the VESC as it is and possibly another firmware that works even better if you replace two capacitors. This has taken more time than I expected, but the improvements should benefit all applications for the VESC.

Your knowledge and drive to improve on your ESC are very admirable; thanks for all the efforts and responding so quickly to found issues! Looking forward to the new firmware :). Did you end up driving your buggy with Lizard's 1717 motor at high speeds? How did it go?

Some other questions I'm wondering about:

  • Do you think the Current sampling offsets and noise issue is also the cause of what seems to be the restricted Current draw / RPM I'm seeing with my set-up? It is hard to believe the motor drops ~30% RPM under only 40A load, compared to no load, and without melting down. As a comparison, my TP4070 only drops 5% RPM at ~120A load: http://www.rctech.net/forum/members/dr_t-albums-8t-pt-vi-picture30083-8t-27-35-expl.jpg. Also, the lower than expected RPM I'm seeing does correlate a bit with the <80% duty cycle registered at the logged faults.
  • Why do you think you and Lizard went through so many DRVs? Is it because of the high gearing, higher set Current limits, or is the 1717 motor harder to drive (lower inductance, higher performance?) than my 4092? Did you also get a TP4070 to test? I asked similar question in your blog, but do you think there is a difference in Current behavior / ease of being driven by VESC between Y and D winds for same motor/copper content and comaprable kv? What is the fragile part about the DRV you think and if so, how does that relate to high demand motor properties?
  • I admit I haven't checked the help in the terminal yet, so maybe it's already there, but if not: is it a lot of work / possible to add logging "events", such as running into soft limits (RPM, Current), in the firmware in the same way how the faults are being logged? I'm especially interested in data on the Current limits, which would help in understanding some of the behavior I am seeing with my set-up. Would also be a nice way to see how much abuse (in the form of high rate charging) the batteries see during braking.
  • Finally, is it still helpful / useful if I try the adjusting the cc_gain and cc_ramp_step_max with the firmware you are working on?

Edit:
Forgot to ask one more thing: is it possible to damage the VESC by setting sl_min_erpm, l_max_erpm_fbrake and l_max_erpm_fbrake_cc too low (as long as sl_min_erpm is the lowest of the three)?

Edit2:
Might seem a bit trivial, but to try and understand the high ERPM discussion, and speculation of it causing VESC/DRV failures, I made a little overview of some motor/voltage combos I've seen being discussed here and added some inrunners that I'm interested in. Overview below lists the no-load ERPMs at a theoretical 100% duty cycle for max Voltage (4.2V/cell) and nominal Voltage (3.7V/Cell). Under load and with 95% duty cycle, ERPM will be a bit lower; how much lower depends on magnitude of load, and motor and battery strength.

Red cells are combos that exceed the listed 100k ERPM specs of VESC. The blue line is the 6-pole TP motor Benjamin said should work up to 6S, a few pages back in response to a post of Lizard. Green is what I have been running, so far without real issues other than abs over-current faults (knock on wood :)). At low (Io+load=~6A) load (pinion installed but no load on wheels, so only load is drivetrain friction) my APS 4092 has logged ~60k ERPM on the VESC @ 22.7 V (bottom pic), which is an effective kv of ~1320 at the 95% duty cycle (so around 1390 kv at 100% duty cycle).

Looking only at the ERPM and listed VESC specs, I do not really understand how the 270 kv is too much on 12S, especially under load and given the 5% "head-room" resulting from the max duty cycle, even if the actual kv of the motor would exceed specs a bit, or increases a bit due to higher motor temperature. Any thoughts?

dr_t-albums-various-picture32155-motor-erpm.jpg


dr_t-albums-kyosho-scorpion-xxl-picture32156-4092-no-load-2.jpg
 
vedder said:
* Use only one shunt on the minus input.
- Disadvantages: Removes the possibility to use sensorless FOC (sine wave control) in the future.
I like the idea of using one shunt only. I don't think it removes the FOC possibility since you can reconstruct the 3 phase currents as in Microchip note AN1299 :
http://ww1.microchip.com/downloads/en/AppNotes/01299A.pdf

Otherwise, probably taking 3 samples each time, and using a median filter could reduce noise.
I had issues with hall sensors from Allegro, they have relatively slow response time (not suitable for single current measurement) and are so bulky..

I am also willing to understand what kills the DRV8302. I wonder if it comes from the gate drive max current, from overvoltage on power supply or something else ?
DRV datasheet states it supports up to 200kHz switching frequency with Qg(TOT)=25nC and the Qg for the VESCs FET is 236nC, so there might be issues at high frequencies (the VESC goes up to 35kHz, but only drives 2 FETs at a time I think) ?
As for overvoltage, I think the spikes occuring upon FETs turning OFF could reach the DRV8302 power supply pins, even if filtered by a few capacitors. (Maybe a small inductor could be added on the pcb track leading to DRV8302 positive power supply pins, before the capacitors) ?
 
Dr_T said:
One of the reasons I mentioned the soft (E)RPM limits is that I thought it could be beneficial to slightly limit ERPM for the guys running the 270kv motors on 12S, assuming it was indeed the high ERPM killing the DRVs, as was speculated earlier. I'm thinking of setting my soft ERPM limits to start at 80k when using 7S on the 4092, just to be sure it does not rev up too high under low loads. With higher loads it won't ever see 80k ERPM anyway, so real-life performance would not be degraded.
Since the switching frequency is adaptive and the problem is when there are to few samples per commutation cycle, decreasing the maximum RPM would not help much. Increasing the switching frequency would help though. I will make a fault code that stops the motor if the KV is too high for the voltage soon.

Dr_T said:
Your knowledge and drive to improve on your ESC are very admirable; thanks for all the efforts and responding so quickly to found issues! Looking forward to the new firmware :). Did you end up driving your buggy with Lizard's 1717 motor at high speeds? How did it go?
Yes I was testing it outdoors at probably over 100 km/h, which was scary. The current limit is at 120A and I almost don't get overcurrent faults. I want to make it perfect though, so I will do some more testing and adjusting. I also had to repair my buggy twice since the bearings around the center diff failed.

[youtube]cnkrGPJvTj4[/youtube]

Dr_T said:
Do you think the Current sampling offsets and noise issue is also the cause of what seems to be the restricted Current draw / RPM I'm seeing with my set-up? It is hard to believe the motor drops ~30% RPM under only 40A load, compared to no load, and without melting down. As a comparison, my TP4070 only drops 5% RPM at ~120A load: http://www.rctech.net/forum/members/dr_t-albums-8t-pt-vi-picture30083-8t-27-35-expl.jpg. Also, the lower than expected RPM I'm seeing does correlate a bit with the <80% duty cycle registered at the logged faults.
This could be a problem, but the motor should accelerate as long as there is current. The best thing would be if you could do video overlay logging over bluetooth, which I will try on my buggy. I have to update the video logger first though to work with the latest firmware. Then you can record a video and overlay it with the current graphs that the VESC sees, as I did here:

[youtube]inj75Ku7KXU[/youtube]

Connecting a bluetooth module is fairly easy.

Dr_T said:
[*]Why do you think you and Lizard went through so many DRVs? Is it because of the high gearing, higher set Current limits, or is the 1717 motor harder to drive (lower inductance, higher performance?) than my 4092? Did you also get a TP4070 to test? I asked similar question in your blog, but do you think there is a difference in Current behavior / ease of being driven by VESC between Y and D winds for same motor/copper content and comaprable kv? What is the fragile part about the DRV you think and if so, how does that relate to high demand motor properties?

The first DRV lizard killed is still a mystery to me since he didn't even run the motor. The second one was because there wasn't enough decoupling for the 1717 motor to work. Most of the DRVs I killed the past days were because I made mistakes when updating the current sampling code which made the current loop go out of control.

I also tried the tp4070, and it is very difficult but it runs on my desk. I cannot test it under load though since I have no setup for that yet.

I don't really know why the DRVs die so easily, but I think it is because there are current spikes that make the ground shift between the FETs and the DRV. I have also killed a MOSFET without killing the DRV once, so these motors are really pushing the limits of the VESC. Other ESCs use brute force with lots and lots of MOSFETs and peak at over 300 to 400A with these motors because they have no current limiting, which would kill the VESC in an instant. Better would be to use these motors with double the voltage and half the kv/current for the VESC. The losses come from current and doubling the current makes the losses four times higher, so running an ESC on half the voltage it is designed for is far from optimal. However, even on 6s, I think I can make the VESC work well with these motors. Running them on 400A does not help much and causes lots of losses and stress on the electronics.

Dr_T said:
I admit I haven't checked the help in the terminal yet, so maybe it's already there, but if not: is it a lot of work / possible to add logging "events", such as running into soft limits (RPM, Current), in the firmware in the same way how the faults are being logged? I'm especially interested in data on the Current limits, which would help in understanding some of the behavior I am seeing with my set-up. Would also be a nice way to see how much abuse (in the form of high rate charging) the batteries see during braking.

Logging that is difficult since it happens at such a high rate. What I usually do is that I run a full acceleration on my bench (the motor goes from zero to full speed in less than 0.1seconds) and log all current samples during that time in BLDC Tool. This really shows what is going on, and is what I have been doing the past days. I have spent a lot of time on making the current sampling better now, so it is going in the right direction. If you have time, here is another experimental firmware that you can test:

http://home.vedder.se/public/tmp/VESC_experimental_2.bin

This one has significant changes in the current sampling compared to the previous one. What you also can do is set the abs max current to 145A.

Dr_T said:
Finally, is it still helpful / useful if I try the adjusting the cc_gain and cc_ramp_step_max with the firmware you are working on?

It helps a bit, but if you test the experimental firmware with the default values helps a bit more.

Dr_T said:
Edit:
Forgot to ask one more thing: is it possible to damage the VESC by setting sl_min_erpm, l_max_erpm_fbrake and l_max_erpm_fbrake_cc too low (as long as sl_min_erpm is the lowest of the three)?
[/quote]

Not really, you can set them as low as you'd like if you want to do rock climbing :) Starting the motor can become a bit delayed if they are too low and you can get cogging if you give dull throttle at once without load.
 
Thanks for the video, hope you had some fun. Don't worry, you'll get used to those speeds after a while :D

I also tried the tp4070, and it is very difficult but it runs on my desk. I cannot test it under load though since I have no setup for that yet.
Oh cool, you have such a motor already? what kv/winding?
 
Awesome Benjamin! The speeding in the video looks good :).

Yes, I'm very interested in making some video with logging overlay, if you have the software ready, let me know what I need hardware-wise and I'll give it a try.

vedder said:
I also tried the tp4070, and it is very difficult but it runs on my desk. I cannot test it under load though since I have no setup for that yet.

I don't really know why the DRVs die so easily, but I think it is because there are current spikes that make the ground shift between the FETs and the DRV. I have also killed a MOSFET without killing the DRV once, so these motors are really pushing the limits of the VESC. Other ESCs use brute force with lots and lots of MOSFETs and peak at over 300 to 400A with these motors because they have no current limiting, which would kill the VESC in an instant. Better would be to use these motors with double the voltage and half the kv/current for the VESC. The losses come from current and doubling the current makes the losses four times higher, so running an ESC on half the voltage it is designed for is far from optimal. However, even on 6s, I think I can make the VESC work well with these motors. Running them on 400A does not help much and causes lots of losses and stress on the electronics.

Yeah, and on top of all the mechanical and electrical stress, there's no real use in pulling those extreme 300-400 A Currents anyway, as most of it will be wasted on making the drivetrain/wheels spin up faster than traction can accommodate; that's why I like your Current control implementation so much. Would be cool to see what a low kv TP4070 is capable of on 10S with the VESC though :). Is there any way to "predict" how difficult a certain motor is to drive, based on the motor properties such as kv, wind, Rm, Io?

Thanks for the new firmware! I'll try it out asap. It's my son's birthday today, so I won't be able to report back tonight already, but I should be able to do some testing by tomorrow night.

I rearranged my battery tray to fit a 5.0 Ah 7S 60C pack. Wanted to go up in Voltage a bit to see what that does to my RPM and total power throughput (I'll leave gears the same). Motor is rated 25V max though, so I'll use the soft RPM limits with 60k-70k ERPM (limit start - limit end), to make sure motor stays under the specced 25V*1380kv =~35k RPM (79 km/h wheel-speed) to keep the rotor happy. You think that's a good plan, or better test on 6S again to keep things as similar as possible?

vedder said:
Not really, you can set them as low as you'd like if you want to do rock climbing :) Starting the motor can become a bit delayed if they are too low and you can get cogging if you give dull throttle at once without load.

Yeah, sorry, I wasn't thinking; the default 150 ERPM is 5 cm/s at my gearing, that's slow enough :). Good to know it won't damage anything though.
 
I stacked the eight capacitors like vedder recommended. No issues with my 270kv and 12s battery. Before it would cut out and give a drv8302 error if I gave it too much throttle at start, now no problems! I even WOT with the motor stalled and no issue's. This is only up to 10 mph in my home until I mount the battery to the scooter and fully test it outside though. But I think it is ok since before I would only have issue's at low speed, high speed was fine.


IMG_4238.jpg
 
Very cool Silviasol! having extra capacitors can't hurt even if not using >200kv on 12s right? Besides cost and complexity. Is there room to replace with a single higher capacity cap?

Motor configuration question for you all. Got two new VESC's from Jamesonotc and configured for two new Enertion 63mm "RSpec" 190kv motors - oddly they have a different Integrator limit and mostly the same BEMF Coupling. One was 622.xx and the other varied (high around 800-850, lowest around 750). Not understanding what those actually do, curious if this is an issue w/ the motors or normal?
 
Posted this earlier in an other thread. What do you think about implementing this, Vedder?

bose said:
vedder said:
My idea was to simply make a current controlled boost converter using one or two FETs (depending on if it is synchronous or not), an inductor and a MCU to run the control loop. Then the whole charger logic can be implemented in the MCU. It might be a bit more work for coding than using an off-the-shelf chip, but it is not that difficult and the configurability makes up for that
.

VESC consists of:
MOSFETs
MCU

Use motor coils as inductor or connect external inductor together with input power cable.

Some reconnections will be necessary when charging but with smart designing of cables it shouldn't be an issue. See also the Russian adappto (spelling?) e-bike controller. They have a setup like this.
 
sl33py said:
Very cool Silviasol! having extra capacitors can't hurt even if not using >200kv on 12s right? Besides cost and complexity. Is there room to replace with a single higher capacity cap?

Motor configuration question for you all. Got two new VESC's from Jamesonotc and configured for two new Enertion 63mm "RSpec" 190kv motors - oddly they have a different Integrator limit and mostly the same BEMF Coupling. One was 622.xx and the other varied (high around 800-850, lowest around 750). Not understanding what those actually do, curious if this is an issue w/ the motors or normal?

I don't think it will matter, I though of that also and it seems to run the same on my 6s pack as it did before adding the extra caps doing a bench test with my rear brake, I will know for sure when I take a ride with it and the 6s packs. There is not much room on a few of the contacts for a larger cap, on one of them I was able to put them side by side, the others there was only room to stack them on top of each other. Buy anyways since a few have little to no extra room it is probably best to stick to the same capacitor stacked in two.

The readings from the motor detection should be the same with any vesc, I always get the same reading on each vesc. The readings will change a bit if you have a load on them, like if you have them hooked up to the wheels/gears but not by that much.
 
Thanks Silviasol.

The motors vary but they read the same on both VESC's. So i don't think it's the VESC, but one motor has different Integrator limit readings than the other, regardless of VESC it's connected to. So i'm concerned about mixing motor/VESC (keeping them paired as one is configured w/ higher IL settings). I'm just curious if i should worry about the higher IL one?

Another random VESC Q. I've seen max amps mentioned above re: the 1/8 RC buggies. Does anyone adjust those for their boards? I seem to max out (or did on old setup) at 65A pretty consistently (on 8s). If there is a set Amp limit, should i set higher to get more power from newer 63mm motors?

Appreciate the VESC 101 help!
 
bose said:
Posted this earlier in an other thread. What do you think about implementing this, Vedder?

bose said:
vedder said:
My idea was to simply make a current controlled boost converter using one or two FETs (depending on if it is synchronous or not), an inductor and a MCU to run the control loop. Then the whole charger logic can be implemented in the MCU. It might be a bit more work for coding than using an off-the-shelf chip, but it is not that difficult and the configurability makes up for that
.

VESC consists of:
MOSFETs
MCU

Use motor coils as inductor or connect external inductor together with input power cable.

Some reconnections will be necessary when charging but with smart designing of cables it shouldn't be an issue. See also the Russian adappto (spelling?) e-bike controller. They have a setup like this.

I have an adaptto and have to say this is one of the best features you can have in a motor controller. Combined with a BMS interface it makes charging batteries so easy. No need to muck around with series/parallel harness for charging with the 6S RC chargers. Would be awesome to see that in the VESC!
 
silviasol said:
I stacked the eight capacitors like vedder recommended. No issues with my 270kv and 12s battery. Before it would cut out and give a drv8302 error if I gave it too much throttle at start, now no problems! I even WOT with the motor stalled and no issue's. This is only up to 10 mph in my home until I mount the battery to the scooter and fully test it outside though. But I think it is ok since before I would only have issue's at low speed, high speed was fine.


IMG_4238.jpg

That's awesome, how did you do this? (My noob eyes can't understand everything they see yet) :p
 
Tested the VESC_experimental_2.bin FW with settings below (145 A abs_max, 80 A soft limits, 60-70k ERPM soft limits), on 7S Voltage. Firmware works very nicely! Average peaks were a bit over 60A, but it seems that this time that was because of set RPM limit (see below). I did have 3-4 faults (I think abs_over_current, all occured at max throttle), but unfortunately I forgot to read out the faults before unplugging the ESC, so can't provide more details :(... Motor went up to a bit over 70°C, hottest I saw on VESC FETs was 62°C.

I increased logger's sample rate to 50 Hz this time to see if it gives some more info how Current fluctuates. I think it shows in the log snip that VESC nicely limits the Current in order to keep RPM limited to the values I had set to keep the motor happy. You can see the RPM topping out at 35k max (79 km/h wheel-speed), as set. I also added a 10 Hz GPS and you can see how much wheel slip there is plowing through the long grass: max recorded GPS speed was ~52 km/h. The Kyosho differential didn't like the 7S drive so much (known flaw), and I need to replace it with something stronger. I have a better diff ready for it, but found out I'm missing one of the sun-gears of it... ordered that, but will take a bit to arrive (closest I found one was in Italy...) and I can continue testing.

@ Lizard: you happen to have a spare CEN diff sungear (MX070) I can borrow? You'll get back a new one as soon as I have mine of course.

Settings used:
Code:
<?xml version="1.0" encoding="UTF-8"?>

-<MCConfiguration>

<pwm_mode>1</pwm_mode>

<comm_mode>0</comm_mode>

<motor_type>0</motor_type>

<sensor_mode>0</sensor_mode>

<l_current_max>80</l_current_max>

<l_current_min>-80</l_current_min>

<l_in_current_max>80</l_in_current_max>

<l_in_current_min>-20</l_in_current_min>

<l_abs_current_max>145</l_abs_current_max>

<l_min_erpm>-100000</l_min_erpm>

<l_max_erpm>100000</l_max_erpm>

<l_max_erpm_fbrake>300</l_max_erpm_fbrake>

<l_max_erpm_fbrake_cc>1500</l_max_erpm_fbrake_cc>

<l_min_vin>8</l_min_vin>

<l_max_vin>50</l_max_vin>

<l_slow_abs_current>1</l_slow_abs_current>

<l_rpm_lim_neg_torque>1</l_rpm_lim_neg_torque>

<l_temp_fet_start>80</l_temp_fet_start>

<l_temp_fet_end>100</l_temp_fet_end>

<l_temp_motor_start>80</l_temp_motor_start>

<l_temp_motor_end>100</l_temp_motor_end>

<l_min_duty>0.005</l_min_duty>

<l_max_duty>0.95</l_max_duty>

<sl_min_erpm>150</sl_min_erpm>

<sl_min_erpm_cycle_int_limit>1100</sl_min_erpm_cycle_int_limit>

<sl_max_fullbreak_current_dir_change>10</sl_max_fullbreak_current_dir_change>

<sl_cycle_int_limit>65</sl_cycle_int_limit>

<sl_cycle_int_limit_high_fac>0.6</sl_cycle_int_limit_high_fac>

<sl_cycle_int_rpm_br>60000</sl_cycle_int_rpm_br>

<sl_bemf_coupling_k>800</sl_bemf_coupling_k>

<hall_table_0>-1</hall_table_0>

<hall_table_1>1</hall_table_1>

<hall_table_2>3</hall_table_2>

<hall_table_3>2</hall_table_3>

<hall_table_4>5</hall_table_4>

<hall_table_5>6</hall_table_5>

<hall_table_6>4</hall_table_6>

<hall_table_7>-1</hall_table_7>

<hall_sl_erpm>2000</hall_sl_erpm>

<s_pid_kp>0.0001</s_pid_kp>

<s_pid_ki>0.002</s_pid_ki>

<s_pid_kd>0</s_pid_kd>

<s_pid_min_rpm>900</s_pid_min_rpm>

<p_pid_kp>0.0001</p_pid_kp>

<p_pid_ki>0.002</p_pid_ki>

<p_pid_kd>0</p_pid_kd>

<cc_startup_boost_duty>0.03</cc_startup_boost_duty>

<cc_min_current>1</cc_min_current>

<cc_gain>0.0046</cc_gain>

<cc_ramp_step_max>0.04</cc_ramp_step_max>

<m_fault_stop_time_ms>2000</m_fault_stop_time_ms>

<meta_description><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'MS Shell Dlg 2'; font-size:8.25pt; font-weight:400; font-style:normal;"> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Configuration loaded from the motor controller.</p></body></html></meta_description>

</MCConfiguration>

Video (uploading):
[youtube]g8K9sn5u4Ps[/youtube]

Log:
dr_t-albums-kyosho-scorpion-xxl-picture32218-vesc-145a-kyo-xxl-150813-all.jpg


Snip:
dr_t-albums-kyosho-scorpion-xxl-picture32219-vesc-145a-kyo-xxl-150813-snip.jpg
 
Vanarian said:
That's awesome, how did you do this? (My noob eyes can't understand everything they see yet) :p

All the caps that are the same size as the ones circled have two total stacked on eachother instead of the normal one cap.

sl33py said:
Very cool Silviasol! having extra capacitors can't hurt even if not using >200kv on 12s right?

I tested it last night with my 6s pack and it ran just the same.

IMG_4238_1.jpg
 
I just finished hand-soldering my first 2 VESCs, and one actually works and runs a motor fine :)

View attachment 1
vesc_back.jpg

The second one doesn't work properly. The duty cycle always shows up at around 30% at 30Volt, and 95% at 8Volt, even though no motor is connected, and no command is given. Once you press the keyboard in BLDC-tool, the DRV8302 shows up, but it disappears after a few seconds.

How is the duty cycle computed? I would like to re-work the hardware components involved with the duty cycle computation. Does anyone have an idea how to track down the issue?
Thanks!
Erwin
 
Everything looks soldered well other then the the one larger capacitor being off centered, but as long as that isn't touching any other contacts it should be fine. Did you double check that all components have both sides soldered? That happened to me a few times. If everything is soldered well I would assume it is the drv8302. What are you using when you attach the ground plate? What temps do you have the hot air at?

erwincoumans said:
I just finished hand-soldering my first 2 VESCs, and one actually works and runs a motor fine :)

View attachment 1


The second one doesn't work properly. The duty cycle always shows up at around 30% at 30Volt, and 95% at 8Volt, even though no motor is connected, and no command is given. Once you press the keyboard in BLDC-tool, the DRV8302 shows up, but it disappears after a few seconds.

How is the duty cycle computed? I would like to re-work the hardware components involved with the duty cycle computation. Does anyone have an idea how to track down the issue?
Thanks!
Erwin
 


Pad c37 seems to be torn off... there actually needs to be made some small contact to the mosfet in the corner and you may just be missing it..


this is a CAP for the DRV8302 which as you probably already know is in control of your duty cycle output. It also appears to be making some contact, but it hard to tell to pad c26 which is not to have anything on it. Benjamin clearly states on the schematic.

"Do not mount C26, because having the buck converter start up as fast as possible in case of a power dip is better."

This CAP on pad c37 is apart of the V_Supply which you can trace back via the schematic provided by Benjamin. Also there is a high volume of flux remaining on your boards. I suggest cleaning them in a 99% Isopropyl alcohol bath and a tooth brush to brush away any flux from the crevices. Allow to dry on paper towel before testing.



 
Silviasol and James, it is nice that you are helping out and you have good tips. I missed this post, but I replied to two of Erwins mails about this.

Silviasol, the extra capacitors you soldered are what I meant. Putting the electrolytic capacitor closer if possible can also help.

I just published this post with a tutorial about how to write custom applications for the VESC if anyone is interested:
http://vedder.se/2015/08/vesc-writing-custom-applications/
 
There is no need for a solder bridge there, they are connected thru the board copper. The drv8302 is the most fragile part due to thermal stress from the high heat needed to attach the ground pad. This is because when applying heat to the top of the drv8302 you are basically using the drv8302 chip to send heat thru to the board, while the board soaks up the heat from the drv8302 it creates lower heat at the bottom of the chip while the top of the chip is very hot(300c drv8302 temp vs room temp pcb board). This will damage the chip due to thermal shock. To keep thermal shock from happening you need to have the board heated to some amount. When I attach them with hot air only I monitor the board temp with a thermocouple, I heat the board up to about 120c first by circling around the drv8302 then apply heat to the drv8302 until the board temp is around 160c, this way the board/drv8302 are at similar enough temps and can safely be installed.

jamesonotc said:


Pad c37 seems to be torn off... there actually needs to be made some small contact to the mosfet in the corner and you may just be missing it..


this is a CAP for the DRV8302 which as you probably already know is in control of your duty cycle output. It also appears to be making some contact, but it hard to tell to pad c26 which is not to have anything on it. Benjamin clearly states on the schematic.

"Do not mount C26, because having the buck converter start up as fast as possible in case of a power dip is better."

This CAP on pad c37 is apart of the V_Supply which you can trace back via the schematic provided by Benjamin. Also there is a high volume of flux remaining on your boards. I suggest cleaning them in a 99% Isopropyl alcohol bath and a tooth brush to brush away any flux from the crevices. Allow to dry on paper towel before testing.



 
Back
Top