Beta CA build for R/C controllers

I just read in Dogati's thread about a V3 Cycle Analyst bursting with new features...for RC.

Where can I find out more about this??
 
lostrack said:
I just read in Dogati's thread about a V3 Cycle Analyst bursting with new features...for RC.

Where can I find out more about this??

If you are referring to this post. I think he is just talking about features he would like from a Cycle Analyst, not the actual CA.

But Justin did mention he is working on the next version see this post.
 
I have now performed extensive testing of the RC CA beta 3 unit with the CC HV160 ESC and Astro 3215 motor. It works well. The throttle is touchy.

Justin - If there was some was to make the throttle ramp asymptotic rather than linear that would help a bunch.

Also, when the throttle is moved suddenly, rather than just hitting the amperage selected by that throttle setting, the CA seems to oscillate until the throttle is backed off and then ramped up slower. I think this is do to a feedback loop between the sensed current and the signal sent to the ESC.

Throttle -> go fast
CA senses ->not enough current increase current
ESC goes faster
CA senses -> too much current back off current
ESC slows down
CA senses -> not enough current increase current
ESC goes faster
CA senses -> too much current back off current
ESC slows down
CA senses -> not enough current increase current
ESC goes faster
Rider backs off throttle a bit to resolve

Can you speed up the feedback loop or dampen the oscillation? Hmm maybe it makes more sense for me just to resolve this by slowing the throttle ramp up speed in the CC HV160 ESC. I'll give that a try.

-Warren.
 
I found this thread where methods explains in more detail how to adjust the CA settings. This is not specifically for the RC version but I think it's still applicable.

http://endless-sphere.com/forums/viewtopic.php?f=3&t=35031&p=549991#p549991

I'll give it a try, thank you methods.

-Warren.
 
www.recumbents.com said:
Can you speed up the feedback loop or dampen the oscillation? Hmm maybe it makes more sense for me just to resolve this by slowing the throttle ramp up speed in the CC HV160 ESC. I'll give that a try.

-Warren.

I ran into the same issue with my analog version. The basic problem is the latency, or delay time between when an input change happens and when an output change happens. This is going to be inherent in an RC setup due to the servo input PWM frequency, which we can't change. Any change is going to take at least 1/50 of a second to happen.

In theory, dialing in the right parameters to a PID control loop can handle this, but one issue is we need the throttle to respond quickly to a decrease in input.

One possible approach is to make the throttle respond quickly during decreases but slowly during increases such that it reduces the oscillation but still gives a fast response to letting off the throttle (look out for that truck!).

Dialing in a PID loop is no easy task. Just ask Luke. The parameters will depend on the motor, controller, and vehicle weight. in general, reducing loop gain and response speed will give more stable output. The existing CA loop may work OK if the parameters are set right. What we might need is a better tuning procedure (not easy).
 
The quadcopter guys run modify the ESC firmware to allow more rapid response to throttle changes which greatly improves the stability in responding to the gyro signals. I am sure we could also do this. Here is an example: http://airhacks.org/?p=445

I have implement PID control for my throttle interface using the Arduino PID code. It has some pretty cool features that allow you to change PID parameters on the fly, and manages to avoid issue as a result of the step change. Here is an example written by the author of the library showing what he calls adaptive tuning, which is pretty close to what your describing in having different attack rates in different scenarios.
http://arduino.cc/playground/Code/PIDLibraryAdaptiveTuningsExample

Also looks like he has recently included some sort of autotune. Check out his blog here: http://brettbeauregard.com/blog/tag/pid/
 
Kepler said:
I have tried all sorts of tuning strategies to try and get around this and have managed to improve things. However, its still not perfect and at this point, due to its intermittent nature feel it may be an issue that needs to be fixed at code level.

Observations:
=> On first startup, the surge never occurs. I believe this is due to the ESC's inbuilt ramp is dampening it out.
=> If you coast at zero throttle for more then 5 seconds, then apply throttle, the surge does not occur. I believe this because the ESC ramp has reset within this timeframe and again is used to dampen the throttle up.
=> Most likely time to see the surge is if you come to a quick stop and then throttle back up again. This when I can see a surge voilent enough to lose motor sync.
=>Throttle up surges if you coast at zero throttle then throttle backup while the bike is still coasting. With my 1500W setup, its not too bad, but should be better.

Hey guys, and sorry to disappear from this thread for so long but thank you all for keeping it alive! In any case, I just had a chance to really dig through what could be going on and the intermittent surge that Kepler is talking about here is indeed related to a software issue. Basically, if you are riding along and then abruptly release the throttle, then the CA's output will go to the minimum pulse width right away, but the integral feedback windup doesn't get a chance to wind down to zero. Once you reapply a bit of throttle, the output starts off where it left off previously, so you get an initial surge. However, if you back off more slowly, then the feedback term will have wound down before the throttle is off, and when you reapply the throttle it will come on from a smaller width. I think this is why the surging seemed unpredictable.

This _should_ be fixed this with a Beta4 version of the firmware. I don't have a system to try it out on but if any RC-CA users have a pic microchip programmer, let me know by email (info@ebikes.ca) and we'll send you the .hex file right away to program in the device.

As others have mentioned, much work has been going into a V3 CA board that has the RC functionality included as part of the standard offering, in addition to more input lines (ebrake, temperature probe, torque sensor, RPM sensor etc). I'll start a new thread on that one in just a day or two.

-Justin
 
That's great news, Justin. Thanks again for your continued work on supporting these applications. We'll be soon placing an order and we'd be happy to share feedback on the new software as we get a couple trikes running on it.

It's awesome to imagine all the possibilities for the new inputs as well. Nice work.

-Tommy
 
Since I'm finally getting more comfortable with the acceleration abilities of my bike, I'm able to pay more attention to what the bike's doing instead of using all my attention to hold on and keep the bike going straight. The explanation for the surge when modulating the throttle makes perfect sense but there's another surge issue when accelerating really hard. At first, I thought it was just the slipper clutch finally catching but I've tightened it up enough now that it won't slip under motor power alone and the surge is still there. When you accelerate at full throttle, the bike takes off like a beast from 3-30mph. At around 30mph, without any modulation of the throttle, there is a big surge at a seemingly much higher power level than the initial acceleration. It's enough to lift the front wheel with a 250lb rider leaning over the bars. I got to observe the phenomenon from off the bike with my boss riding it and it looks just as scary as it feels when on the bike. He described it like a turbo coming into boost or maybe grabbing a different gear.

I'd really like to get mine reprogrammed with the new software so if anyone in the US is geared up to do it, I'd happily pay a small fee to get mine updated. I just searched for pic programmers and got a headache just trying to find a cheap one that I can figure out how to use. I know it's probably very easy but I'm so overwhelmed with everything else going on in my life that I'd rather just send my CA off and pay someone to reflash it. Would anyone consider doing this for me?
 
www.recumbents.com said:
I hope Justin has a plan for upgrades for us beta testers. Otherwise it's going to be a choice between paying for sending the CA somewhere and paying to have it flashed with the new code revision and then sent back, buying a $40 gizmo to do ourselves, or just living with it.

-Warren.
Justin never did a bootloader in the chip? If he did ypou might only need usb-serial adapter to change it. But if you need to change major things then it might be a full reflash.
 
Since I got it knowing that it was a beta program, I'd be totally fine with paying someone to reflash it and ship it back to me. I want Justin to spend his time getting the new model rolled out instead of spending too much time on our stuff. :wink:
 
Kepler said:
Thanks Justin.

I should have my programmer in the next few days and look forward to testing the new code.

Hey Kepler, so let us know when you get a chance to try and if this resolves the occasional surge situation OK.

Tommy at FFR has offered to reflash the device for people in the US who have a beta device and no PIC programmer so that they don't need to ship it across the border, and that should make it a lot cheaper and faster for everyone to get the upgrade. Once we've confirmed that the B4 code is good then we can sort the upgrade logistics.

Arlo1 said:
Justin never did a bootloader in the chip? If he did ypou might only need usb-serial adapter to change it. But if you need to change major things then it might be a full reflash.

I wanted to, but quite literally had no room left in memory to fit a bootloader by the time all the V2.2 features were added to the firmware! In the V3 units this was first order of action to implement, so going forwards everything will be upgradeable just with a serial->USB cable.

-Justin
 
justin_le said:
I wanted to, but quite literally had no room left in memory to fit a bootloader by the time all the V2.2 features were added to the firmware! In the V3 units this was first order of action to implement, so going forwards everything will be upgradeable just with a serial->USB cable.

-Justin
Awesome! I would offer to reflash anyones CA if they need but Its proly the same price or cheeper (for shipping) and quicker to send them strait to Justin.
 
the bug you describe Justin is definitly what I have experienced, sometimes a gentle take off while other times its that abusive it hits the current limiting of the HV160. If this is sorted its a definite win.

Feature request : maybe a 2 or 3 speed switch by holding both buttons to cycle thru them or external switch....I dunno something like that, then in advanced setup have amp limit 1/ amp limit 2 / amp limit 3. I find it a real breeze to cruise along with it set on 30A (appart from the abusive start ups sometimes) and it sure takes care of my inability to modulate a throttle for efficiency :lol: . But then you have to stop and change the settings and power cycle to get going again. Anyway just a suggestion, works perfectly for my needs as it is.

Kepler are you able to flash us aussie beta testererers if all goes well with yours and the update? for a fee of course.

Rodger
 
No problems, I am happy re flash any AUS based CA's after I have completed testing. I am still waiting for my Pickit-3 but hopefully will have it by the end of the week. Justin has already sent be the update file so hopefully I can do some real world testing this weekend.
 
Kepler said:
Good news is I have my PICkit-3 and have uploaded the updated firmware into my CA. Looking forward to some serious testing in the morning. 8)

Kepler - what software did you use? I couldn't find any!
 
Kepler,

How did you interface the pickit3 to the CA board? I don't see any header pins on the CA. Did you have to solder pins to it? Closeup picture perhaps?

Nice quick work, and Thanks much,

H3D
 
Back
Top