2WD trike pulling left when accelerating

The speedo input on the CA just has a diode to a weak pullup to 5V so it's hard to believe this is causing the issue. This is more likely a side effect of a GND problem with the CA than the actual SPD input. The exact points you GND everything can have a pronounced impact for 2WD - - just because all GND points are wired together doesn't make them at the same voltage when big currents are in play.

Without a wiring diagram (not a schematic), it's hard to tell what's going on. Your other build thread lacked a wiring diagram but it seemed you had gotten the common GND thing figured out. Maybe that's in play here...

Did you also change or remove a GND connection when you fiddled the SPD input?
 
teklektik said:
The speedo input on the CA just has a diode to a weak pullup to 5V so it's hard to believe this is causing the issue.

Yup. I just edited my prior post. It was totally a false reading. I had the throttle wire to the passenger side controller disconnected during that road test. So that's why it pulled right instead of left. I did a follow up with the throttle wire connected correctly and the hall copy signal disconnected and we are back to pulling left. Sorry for sending us down that rabbit hole.
 
Some different testing and troubleshooting

These all are in the "grasping at straws" category but here goes.

1) Removed both rear brake calipers - no change, pulls left
2) Tried the "Read Zero" button on the Kelly programming screen
It brings up this screen
read-zero.jpg


I then clicked the "read" button for the Passenger side controller and got these results

read-zero-screen-2-pass.jpg


On the driver's side I got these results

read-zero-driver.jpg


I have no idea if these readings can be used to reset the controller somehow but after taking the reading on each side I went through the "write" routine just in cast they are supposed to be used to update the program. Went for test ride. No change, pulls left. I'd still like to understand the "read zero" function a bit more and why it is even included on the screen. Possibly it is just a read out for some diagnostic purpose rather than a way to reset of adjust the zero value. BTW, from what I can tell that "update" button just does the "read" again. I don't think it updates or changes the programming in any way. When I click it, nothing happens that I can see.

3) I then tried a "blip" test". All of the diagnostic testing and Kelly monitor checking so are have been done with no load or very little load on the motors. My gut feeling is that the problem only shows itself under relatively heavy load (road resistance and acceleration). So I'm trying to figure out how to test under those conditions. For the "blip test" I disconnected one controller from throttle input. I then got the bike in the driveway ready to test. I then hit the trip reset on the CA3. Then I hit the throttle as hard as I could (I think I went to WOP for each test but can't be sure) and let off a second or two later. I then checked the CA3 for the screen which shows Maximum amperage. Here are the results:

Driver side connected (passenger side disconnected) Max Amps 29.7 - pulled right

Passenger side connected (driver side disconnected) Max Amps 25.9 - pulled left

Not sure if this is at all significant and I can't vouch for absolute accuracy do to having a human involved (twisting the throttle) But if these readings MIGHT be saying something I could do it a half dozen times or so on each said and get and average. That would be a more reliable number. At first blush the results seem to say that assuming these are the readings we would get with BOTH controllers powered up, under hard acceleration the driver side is drawing about 15% more amps while delivering far less torque (enough less to cause the bike to pull hard left). Again, I have no idea if this is significant.

Next I'm going to start testing the "phase current percent limit" on the passenger side wheel to see if/when we reach balanced acceleration.
 
cboy said:
Driver side connected (passenger side disconnected) Max Amps 29.7 - pulled right
Passenger side connected (driver side disconnected) Max Amps 25.9 - pulled left

Kinda busy today, but looking at this quick, this is in keeping with earlier observations regarding motor differences - interesting test. To get the best numbers set your ramping to the max V/sec value so the CA really slams the controller.

These are way low numbers and it wouldn't be unreasonable if your phase currents don't exceed 150A - probably more like 100A or less. If correct that would mean you could reduce your max phase amps % to something like (150/380 *100) = 40% or even (100/380 * 100) = 26% and your blip test would accelerate the same.... that would be a place to start your balancing excercise.
 
I was going to start noodling around with the phase current limits next but decided to go a different direction. I set up my go-pro camera on my laptop screen to film, in slow motion, the Kelly monitor. By doing this I was able to capture on one screen the throttle input, motor speed, phase current and hall sensor contact points being made (i.e. A, B, C or a combination of any two of them as they rotate from one contact point to the next). This first attempt at filming and then reading the frames on the film is a bit tedious and far less than ideal but I thought it was interesting. I'll be doing this over again to try to improve on the technique, get a little clearer shot with my camera and make the tests as equal as possible. But here is the first round of results:

Phase-current-test-1.jpg


A couple obvious points. I cut the throttle quicker on the passenger side test than the driver side. So I need to do future tests a little more evenly. Also the hall sensor notations may not be of any particular use but I included them anyhow.

The things I found of interest are the possible latency in controller D and the driver side wheel. Note that the wheel does not appear to begin turning until the throttle is at 74 and amperage has been flowing for at least 5 hall sensor phases. Controller P shows wheel rotation in just one phase after current begins to appear. This may be an anomaly due to the test procedure but something to watch in further testing.

The second observation is that it appears the driver side wheel is drawing more phase current relative to throttle input. For example at a throttle input of 127 the passenger wheel is drawing 13 amps while the driver side wheel is drawing 21.

The third thing that may be of import is that when the driver side throttle reading goes above 130 the amps really start to spike upward. Maybe this is normal as throttle input increases. But it looked suspect to me. Unfortunately I cut off the passenger wheel test at 127 so I don't have comparable data for the two wheels at the higher throttle levels. But I'll be doing that next.
 
You are nothing if not tenacious... :D
This was a PITA experimental technique that I never would have done, which is too bad since the results are pretty interesting...

I OCR'd your data into Excel and did some quick plots hoping some relationships would be more obvious. For the time plot (only) I assumed the data was some even multiple of frame rate so the data was evenly spaced to get a relative time axis - so that plot could be incorrect. The last two have no time component and so show only the actual raw data w/o assumptions:


TrikeTest-time-1.png


TrikeTest-Speed+Throttle-1.png



View attachment TrikeTest-1.xlsx.txt


In all plots I am struck by the more or less linear relationship between throttle and speed with phase amps appearing to fluctuate to maintain that relationship. Also - the last two plots show throttle/speed not only have similar relationships but result in similar values for both controllers.
Here it appears that controllers are manipulating the phase current to achieve identical speeds and actually doing a pretty good job of it.

Based on the data, this looks like speed not torque control -- at least for the bulk of the curve.

This may be the effect of the 'balanced' control strategy they call out for other controllers (this one has no control type claimed). There is at least one PI controller in there but there are only two accessible tuning parameters "Torque Speed Kp" and "Torque Speed Ki". The names themselves suggest some kind of mixed interpretation or use...

So - not committing to any strong conclusions on such sketchy data, but it seems:
  1. If the throttles were cranked up at the same rate, the phase amp differences seem to indicate a differnce in the motors.
  2. The controllers appear to be mapping throttle rotation to speed not torque.

Other comments are welcome here - this seems an unexpected turn of events...
 
teklektik said:
So - not committing to any strong conclusions on such sketchy data, but it seems:

I'm right now in the process of trying to make the data a little less sketchy. On your suggestion I downloaded a video screen capture program last night (not all that each to find a free one for an old, clunky Windows xp laptop. But I found one that seems to work well...CamStudio. I had to spend a little time learning the program and then had to clean out and defrag the laptop to get everything running smooth but I'm in business this morning. I'm still testing out frame rates and playback rates to try to get the most accurate data but it is far far easier with the screen capture than with my go pro. Anyhow, I should have some decent data in a bit. I'm also going to put the screen videos up on my Youtube channel so you and others can take a look at them if interested.
 
These are the results I got from doing a video screen capture of the kelly monitoring software for each wheel. I added a column on the left which shows the video time designation whenever there was a change in one or more of the data boxes and then the corresponding readings for throttle, speed, amps and hall position.

Passenger side wheel/controller

Passenger-side-phase-current-test-2.jpg


Driver side wheel/controller

Driver-side-phase-current-test-2.jpg


It seems that the better I get at capturing the data the fewer discrepancies jump out in the results. I'm not sure what this tells us but I do think it pretty accurately shows what the two controllers and motors are doing as they accelerate. One thing I noticed is I don't believe the kelly monitoring program is streaming the data continuously. It appears it sends out a data point approximately every 0.2 seconds (if I am reading everything correctly). So I think "plotting" the data on a graph is far more informative than just looking at these data points. We don't know what is happening between the points but a graph gives us a very good hint. If nothing else, I have now learned how to use video screen capture. So all is not lost.
 
I've seen no indication of torque throttles here, with no load they would go instantly to full speed at any throttle setting. These appear to be speed throttles. No wonder it pulls to one side on hard throttle.

The controller documentation talks about torque throttle, perhaps the mode can be changed and they are just not in that mode yet.
 
Alan B said:
The controller documentation talks about torque throttle, perhaps the mode can be changed and they are just not in that mode yet.

There is mention of torque throttle settings in the manual but Fany has indicated to me that the KLS series does not provide for a torque mode.
 
cboy said:
Alan B said:
The controller documentation talks about torque throttle, perhaps the mode can be changed and they are just not in that mode yet.

There is mention of torque throttle settings in the manual but Fany has indicated to me that the KLS series does not provide for a torque mode.

Then their website is misleading. They clearly claim it, or did when I looked some time back (current control, which is torque). They also say FOC, and hall sensors required. FOC doesn't need hall sensors, except possibly for startup. Their description is a bit of a collection of buzzwords rather than being clear.

For this application you need torque throttle control, then the controllers would automatically balance the torque. If these don't have it then get different controllers.
 
Alan B said:
Then their website lies. They clearly claim it, or did when I looked.

Here is the current description of my Kelly KLS controller It does not mention a torque mode from what I can see. Who knows, maybe it was claimed earlier and then taken out of the description. For me, whether torque mode is in the description or not does not matter. The KLS series was recommended for my settup (dual rear hub motors) by both QSMotors and Kelly Controller. I conferred with both prior to ordering to insure the motor and controllers were compatable. [Edit: I've checked my emails and I conferred with Kelly about a compatable contactor, not controller. So I only relied on QSMotors for this combination, not on Kelly.] I purchased the controllers through QSMotors as a part of one of their "package deals". I have been in contact with both QSMotors and Kelly regarding the torque situation and we shall see how that evolves. I think what I am trying to do at this point is assemble as much hard data as I can to demonstrate if this was not a good match to recommend.

Alan B said:
For this application you need torque throttle control, then the controllers would automatically balance the torque. If these don't have it then get different controllers.

I think that is the where all this troubleshooting may point in the event the two companies can not come up with a viable solution through some other means.
 
I fell into the same trap - I've looked at so many different Kelly manuals that I assumed (bad word) that this was a torque controller. However, the KLS-S manual makes no such claim. I'm thinking at this point that the 'S' stands for sine or maybe speed.

Here's the plot of the latest data - there is zero doubt this is a speed controller and the phase current is being manipulated to achieve the target speed. (The time offset between sides was subtracted out (0.4sec) to align the datasets.) As in the first tests, the controllers are actually doing very well at regulating speed - they're just designed to do the wrong thing for this application.






cboy said:
Alan B said:
For this application you need torque throttle control, then the controllers would automatically balance the torque. If these don't have it then get different controllers.

I think that is the where all this troubleshooting may point in the event the two companies can not come up with a viable solution through some other means.

What alan B said.
There is little doubt these are the wrong controllers for the job. There is no good workaround. What is needed here is a controller swap by Kelly. If they knew in discussions this was a trike, they should have stepped up about the controller type.

Anyhow - this discovery was a long time coming (largely because of misunderstanding of the control algorithm) but cboy's data removes all doubt. That data collection was a really valuable effort. :D
 
teklektik said:
What is needed here is a controller swap by Kelly. If they knew in discussions this was a trike, they should have stepped up about the controller type.

Just to clarify, I edited my post above to indicate that after searching through my emails it was only QSMotors who recommended the KLS series controllers with the dual QSMotors wheels. I did confer with Kelly at the time but it was only seeking a recommendation for the contactor...not the controller. So my post was in error in that regard. I purchased the motors and controllers together as part of a package that QSMotors put together. And they clearly knew from our email exchanges it was a trike with side by side motors. Unfortunately I am not hearing back from them after their initial response which indicated they felt this was a "wheel" issue not a "controller issue". Turns out it was a compatibility issue. I just sent them another email in hopes of rattling their cage.

This may sort of draw this part of the discussion to a close as I pursue a solution with the seller. So I just wanted to give a big shout out to everyone who pitched in with thoughts, ideas and troubleshooting. And a special thanks the teklektik for wading though mounds of data and test results. Much appreciated.
 
No problemmo - glad things are moving along again on this project.

With regard to QS: There is still an issue of differences in the motors which hopefully can be balanced out later. Hopefully, they will exchange the controllers for you for another Kelly model. Kelly is clearly one of their suppliers and even if they need to do a special one-off order to make this right it shouldn't be too painful at their end. Alternatively, you might ask just them to allow a return, and you could order from Kelly directly.

There are many theories on dealing with companies, but I'm a believer in just proposing a solution that will make you happy. This simplifies their end and turns it into a yes or no situation. If it doesn't work out, it's your problem - simple and the possibility of comebacks for them is reduced.

So - I might recommend you survey the Kelly landscape for a candidate, then propose return and/or replace options to QS. They are after all a motor company, so there's a fair chance they may just want to slip away from this controller issue and take the return.

Just a thought...
 
teklektik said:
So - I might recommend you survey the Kelly landscape for a candidate..

Ha, was just searching around for that very thing when your post popped up.

One other loose end...you talked a bit about the Torque speed Kp setting and the Torque speed Ki setting. The manual says these are for PID adjustment. Is that something worth trying to tweak? I have no idea what PID is.
 
cboy said:
you talked a bit about the Torque speed Kp setting and the Torque speed Ki setting. The manual says these are for PID adjustment. Is that something worth trying to tweak? I have no idea what PID is.

I wouldn't - this doesn't go to the core problem. The problem isn't tweaking the PID gains, it's that the PID is controlling the wrong thing. You can adjust the faucet flow all day, but it won't make a water tap give you beer (which is probably what you need just now...)

Wikipedia has a very good treatment albeit a little mathematical. I wrote a simplified version for the PID controllers in the CA which is simpler and focuses on effects of adjustments to the three parameters - see the Guide section "Appendix E. PID Controllers and Gain Parameters". There are also YouTube treatments... pick your poison. :D
 
hey cboy-
I don't want to discourage you from messing with the PID parameters as an experiment or to make the trike somewhat more rideable - it's just not a final solution to your pickle. I think you are at a place when it's clear no damage will result from riding it -- it just can't ride right.

So - if you look at the last plot, you can see that the controller is burping the phase current in an attempt to modulate the speed. Why the burps? One problem with speed control is that the control loop involves actually moving the physical mass of the bike so there is a tendency to pour on a lot of current before there is any visible effect and then to over-zealously remove current when things overshoot. We can see this above in the spiky phase current overshoots. Ideally, we would like to see that smoothed down.

If you look at the PID references, you will see that you can damp this response by reducing the Kp and Ki parameters. These control the Proportional and Integral gains of the controller (yep - looks like a PI not PID controller - no Derivative term). Since you have a big-ass heavy trike, I would start by reducing Ki which builds error correction with time. This will tend to prevent the phase current from rapidly building because 'the darn thing isn't moving yet - more current!'. This will also make it take lonqer to get moving, so the Kp parameter will likely need some messing to compensate. PID tuning is an art form, so.... (The are some hints on PID tuning in the CA3 Guide that you might try if your other attempts are not successful. This is presented in terms of the CA parameters, but the underlying approach for adjusting Kp and Ki should more or less work.)

The speed controller is never going to be super good at turning corners and tuning speed PID controllers is frustrating, but you could probably make this behave somewhat better than now although with crappier acceleration and a laggy or mushy throttle.

Anyhow, just a thought if you hear the trike calling your name...
 
teklektik said:
This is presented in terms of the CA parameters, but the underlying approach for adjusting Kp and Ki should more or less work.)

Thanks for the short course on Kp and Ki. Very helpful. I'll also check out that section in your CA manual. I'm going to tinker a bit with the max speed settings as suggested by Fany. I think we've agreed this probably won't do much of anything but I want to exhaust all the options. Also, I did hear back from QSMotors this morning...but only to report that they have an engineer looking into it.
 
I started an email conversation with Fany about this controller model. Interaction is ongoing, but so far it appears that although the controller cannot be switched between modes by the user, they can shoot it up with different control algorithms when ordered. More to follow, but this is taking an unexpected turn...
 
teklektik said:
...they can shoot it up with different control algorithms when ordered. More to follow, but this is taking an unexpected turn...

Interesting. I'm glad you are talking with her because I'm not always sure she understands my questions and/or the descriptions I send her. I think you and she are much more on the same wavelength in terms of understanding how all this stuff works (it is just a mystery to me).
 
So I got a couple of prompt email responses from Fany at Kelly. Most of this is pretty to the point, but the details of the torque mode are a little unclear.

Fany @ Kelly Controls said:
The KLS-S can not support to choose speed mode,torque mode and balanced mode in the user program.
By default,the controller worked with torque mode.
KLS-S can support pure current mode or speed closed loop mode also.
But it only can be added before shipment.The controller also can not support proggramming to choose the different modes.

Fany @ Kelly Controls said:
  1. Torque mode is the controller will output current to the motor quickly even if the throttle signal is not at full position.
  2. The pure current mode is the output current is based on throttle voltage signal.
  3. The speed closed mode is the output speed will not be changed if the throttle signal is not changed regardless of variable loading.

The current and speed controller descriptions seem plain enough, but I don't quite get the torque mode - largely due to these being operational rather than design descriptions. That probably comes from Support dealing with non-technical queries. Although pressing this to get a bit more engineering description of the torque mode is might lead to some clarification, my knee-jerk reaction is that the best (safest) choice is the pure current mode controller as the one with the simplest torque control and the fewest ancillary behaviors that might conceivably differ in time or magnitude between controllers - which is a prime consideration for the trike. If the mode is as it sounds, it would essentially be a big Phaserunner which is ideal for this application (e.g. see JLE's Solar Trike with dual PRs and Grin motors up front).

FWIW: I have to say that I am pleased with the brisk response from Kelly and the clear responses in just one try for the bulk of the questions. Their KLS-S manual is thin on this mode information, but their Support seems ready to take up the slack.

UPDATE:
I decided to ask Fany about torque mode and got back this response:

Fany @ Kelly Controls said:
torque throttle is just output the current to the motor as soon as possible.It is aggressive acceleration.
There is no formula relationship between output and throttle voltage.
This describes an open-loop PWM sine controller where the throttle control the percentage of PWM - essentially the sine version of a common trap controller where torque and rpm depend not only on throttle but on load.

So - to summarize - the KLS-S can be ordered with one of three control modes. The Kelly mode names in bold/underline are slightly different than commonly used here on ES:

  1. Torque Mode - this is open loop PWM mode - fast response, no feedback loop, rpm+torque not directly related to throttle setting
  2. Pure Current Mode - closed loop mode where the phase current is directly proportional to throttle voltage. This is the same as a Phaserunner and is often referred to as 'Torque' mode because torque is directly proportion to phase current and so the throttle directly controls torque.
  3. Speed Mode - a closed loop mode where rpm is proportional to throttle voltage.
 
teklektik said:
So I got a couple of prompt email responses from Fany at Kelly. Most of this is pretty to the point, but the details of the torque mode are a little unclear.

Fany @ Kelly Controls said:
The KLS-S can not support to choose speed mode,torque mode and balanced mode in the user program.
By default,the controller worked with torque mode.
KLS-S can support pure current mode or speed closed loop mode also.
But it only can be added before shipment.The controller also can not support proggramming to choose the different modes.

Fany @ Kelly Controls said:
  1. Torque mode is the controller will output current to the motor quickly even if the throttle signal is not at full position.
  2. The pure current mode is the output current is based on throttle voltage signal.
  3. The speed closed mode is the output speed will not be changed if the throttle signal is not changed regardless of variable loading.

The current and speed controller descriptions seem plain enough, but I don't quite get the torque mode - largely due to these being operational rather than design descriptions. That probably comes from Support dealing with non-technical queries. Although pressing this to get a bit more engineering clarification on the torque mode is might lead to some clarification, my knee-jerk reaction is that the best (safest) choice is the pure current mode controller as the one with the simplest torque control and the fewest ancillary behaviors that might conceivably differ in time or magnitude between controllers - which is a prime consideration for the trike. If the mode is as it sounds, it would essentially be a big Phaserunner which is ideal for this application (e.g. see JLE's Solar Trike with dual PRs and Grin motors up front).

FWIW: I have to say that I am pleased with the brisk response from Kelly and the clear responses in just one try for the bulk of the questions. Their KLS-S manual is thin on this mode information, but their Support seems ready to take up the slack.

That's good info here. A lot of people think you can change the modes but apparently not on KLS
 
Back
Top