CAv3 Torque PAS + dual throttles 2WD for SB Cruiser

[amberwolf]

Ok, so...first some info on how SB Cruiser
https://endless-sphere.com/forums/viewtopic.php?f=2&t=67833&start=625#p1355631

works now, and then how I'd like it to work, once the new equipment is installed. Note that I havent' yet gone thru the latest CAv3.1 beta / etc firmware features to see if what I want is even completely possible yet, but we'll get there later. Apologies for the length of this post; there's a lot to cover, and didn't want to split it up into separate posts yet, but for those replying to just one part at a time, it is probably better split taht way. For now, basic ideas are sectioned off with rows of ******* .




I will shortly have a functional Cycle Analyst v3 (vs the one I have that was killed by the short at the wire-exit area of the SA shunt between B+ and SPD years back), and I already have a THUN BB, and I think this CA is coming to me with a TDCM BB, so I can use whichever one works better for my purposes--either one will fit the SB Cruiser's BB shell. (if not, I can change the BB shell out).

I'm going to use this to add Torque PAS control to the trike so I can control speed via pedalling, without using the throttles at all, but still be able to use independent left/right throttles.


The system is 14s NMC, so AFAICR I'll need a separate power supply for the torque-sensing BB, so the CA doesn't fry it's internal one from overcurrent. (I did that to my original CA v3; the first thing I blew up on it). I already have a "12v" lighting system that runs on 4s NMC, which I can run a regulator off of for the 10v (IIRC) the BB will need. I might have to connect the systems' grounds to a common point, as I think I disconnected them completely from each other back when I redid all the main battery-to-controller wiring. I could also use a 10VDC wallwart powered off the main traction pack (14s) if I have one that will operate at that low a voltage reliably.

The CA will use an external shunt, whcih is two of the regular Grin SA shunts wired in parallel, for half the shunt resistance (because this system draws over 100A peak at startup from a stop, and can draw 120-130A sometimes in those situations, eventually I'll have better controllers that can do even more). Less voltage drop everywhere along the line is better for more power to the wheels.



**********************************************
I will also use it to be able to have a speed limiter if I want it (so I don't have to constantly keep an eye on the speedometer, which takes my eyes off the road, to be sure I don't exceed the 20MPH limit we have here). However, I need to have an instant-override button on that, somewhere right on the throttle body or thumb tab, so that if I end up in a traffic situation in which the only safe way out is to accelerate quickly, I can still do that. (it has happened a few times over the years with CrazyBike2, and a couple of times with the trike, where brakign would have gotten me squished, and only accelerating momentarily out of the situation made a happy ending. Years back on plain-old-pedal-bikes I could do that with my legs but nowadays I couldn't even if my bikes were light enough).

Whether the override uses a CA function, or simply directly connects the throttle to the contrller and bypasses the CA's throttle output completely doesn't matter--whatever works and works reliably in all situations.



*****************************************************
Presently, I have a "generic" controller and DD hub on each side of the rear of the trike, each with it's own independent throttle, and common ebrake connection. Like most of my stuff, it's all a hodgepodge of parts, so the two motors are different (even once I have two of teh same motors on there, they'll still be different winds), and the controllers are different. (someday I'll get a pair of Lebowski's finished, but I don't know when that will happen).

Independent throttle is very useful for steering, by having extra power on the outside wheel, and no or minimal power on the inside wheel, and I'm very used to doing this myself automatically. I can make pretty sharp turns (considering the trike design) at almost cruising speed (20MPH) depending on road conditions.

It's also handy to be able to use just one motor if something has gone wrong with one side or the other, without having to get down there and cut wires (or install switches to disconnect oen or the other, even though I may do that too eventually).

It's also useful when backing up, since I have reverse on each motor (wired to switch both to reverse with a single button) and can use each one at the speed needed to back up in a particular direction, really useful with a heavy trailer full of cargo (or dog).

So I don't want that to go away; in a turn I'd stop pedalling (to stop Torque PAS from controlling the system while I do the throttle thing), and just use each throttle as needed. Obviously since the CA only has one throttle input and output, these throttles will not go thru the CA, but instead will go straight to the controllers. That's where one other problem will crop up I haven't figured out a solution for, to be discussed later: I'd like the CA to be able to limit speed to 20MPH, but it has to have control of the throttle to do that--it won't be able to do this the way I need to wire up throttle-to-controller..



**********************************************************
At some point, I'd like to develop a little box that is a steering-controlled "differential throttle", where it senses the steering position (and possibly how quickly I am turning the steering into that direction) and wheelspeed, and uses that info to alter the throttle input to each controller to do this kind of steering for me, without independent throttles. (I have throttles to take apart for the sensors and magnets to do the steering detection experiments). But that's a separate thing for later, only mentioned now in case anyone has ideas on doing that in hardware since I'm not a programmer and hardware is easier for me. I already have a basic idea for it, will post that up later on once I get it out of my head and onto paper. This box would also solve the above problem of limiting, as it would "handle" all the throttle voltage sources and outputs as two independent but interactive channels.


**********************************************************
I also actually have a glimmer of an idea on how to feed the two throttles into the CA via an external "router" box, and "split" them back out to two controllers, so that in the case of me using the left throttle as override to the PAS, it detects a voltage out from the left throttle, then disconnects the CA's throttle output from the righthand controller, and feeds it only ot the left. And similarly for the right. And if I am using both throttles, it feeds the voltage to both controllers. I dont' know the exact circuit to do this, but I can probably do it with transistors or op-amps, messy as that might be. (an MCU would be better but someone else would have to write the code and whatnot; I have very little idea how to do that).


**********************************************************

Back to the main throttle control function: each of the throttles on the separate controllers would override the Torque PAS throttle output from the CA, meaning:

-- if I was pedalling hard enough to get say, 15MPH out of the system, then if I push both throttles up to full, the voltage from them will be higher than that from the CA so the system will slam on max power.

-- If I was pedalling for that 15MPH and used just the left throttle, then the righthand motor and controller will keep doing whatever the CA / PAS was telling it to, but the lefthand one would be doing whatever the throttle was telling it, once it's voltage was higher than the CA's output. And vice-versa right vs left.

The throttle mode may change, but at first I'll probably have it be speed mode; later I'll experiment with other modes, which may change how everything else is setup and works depending on how it changes the feel/operation.



**************************************************
Braking will remain common, both motors engaged at teh same time (avoids brake-steer, which is a PITA and makes for some unpredictability in sudden stops in traffic). Note taht the left motor has on/off EABS, where it actively powers the motor to a stop, while the rigth motor has on/off regen, of a bit less capability than the lefthand EABS but I'm used to it and compensate steering as I brake. This braking assymetry stuff is one reason I want to change to the Lebowski controllers. Proportional EABS is another big one.



********************************************************
At this time I'm not really thinking about mulitple presets of different setups, but I might want that too eventually.

Also not going to limit power, as I need all the power I have (and more) as it is. There's no power limit presently in AZ, so no need to do so (except for extending range, and I might want a "preset" that does it for that reason). I do want the *option* to add a power limit, in case someone someday gets picky about it if they ever actually do change the law to include one, *and* it is strictly enforced (the day before they do that is the last day it'll be as safe as it is now to ride in traffic hauling cargo/dogs, and I"ll probably have to move to sidewalks where it's actually more dangerous for a number of reasons--but that's outside the scope of this thread).



I'm pretty tired so I probably forgot stuff or lost train of thought in some of what's above, so questions and thoughts are welcome; I'll answer as thoroughly as I can.

 

[amberwolf]

This is the basic wiring as things are now, except there's not yet any PAS sensor (and it's a CA v2.3 not a v3).

Blocks are labelled, wires represent about how it's actually wired on teh trike, includig relative placment of items. Some tings like fuses and breakers/switches are not shown. At some point I'll make a better drawing on paper (suck at the paint drawing).

NOw have to draw connections for CA v3 to be able to control the system (as well as the independent throttles)

had to leave it large to read it, so it doesnt show up in line just as a link.

 

[amberwolf]

I've got the CAv3.1 and TDCM installed with basic wiring and functionality.

https://endless-sphere.com/forums/viewtopic.php?f=2&t=67833&start=675#p1361845

I haven't yet worked out the independent trhottles overriding the CA's throttle output, but still having the CA control both controllers via PAS (and hopefully either throttle by itself as 2wd control).

 

[amberwolf]

Still working out settings, a few issues cropping up with how the CA appears to work vs how I need it to work.

https://endless-sphere.com/forums/viewtopic.php?f=2&t=67833&p=1362085#p1362085

Couple posts down is today's pre-work-commute experiments that show behavior I don't quite understand, and will have to reread the manual / UUG to see if there's an explanation, of the PAS Start and Stop Thresholds, as they don't appear to do quite what their names imply.

 

[amberwolf]

Below is the results of today's experiments and research on the CAv3 settings. Not what I wanted to find out.


So,unless I've missed several somethings, the only way to do what I need with it is to build some external electronics, at least five functions, which might be in one module, if possible. By the time I'm done I won't even really need a CA to do anything for me; if I added speed limiting to my module(s) I could just use any wattmeter for the power usage/range/etc data.


The first piece has to take the torque signal from the PAS unit and convert it into a throttle signal that bypasses the CA until the wheels start moving a bit, then lets the CA do it's thing. (this is because the CA cannot startup from torque alone, but has to detect some pedal rotation, but I need it to startup from just the torque, so I don't have to move the whole trike from a stop by pedals alone).


The second piece has to determine if the CA is limiting due to speed or not, and if it's not limiting due to speed it overrides the CA's throttle output and passes my throttle straight thru to the controller. (this is because no matter what I do, the CA is limiting my power (W limit flag) at startup from a stop, the absolute one time I cannot allow it to do this). The most difficult part of this is converting the TorquePAS sensor data into a complete throttle signal based both on torque and crank rotation (a different thing than what the first one has to do), so that this function will also work with PAS as well as my hand throttles. (otherwise, the PAS is as useless for startup in traffic due to lack of full power as it would be for startup due to having to pedal a distance first before getting any power)


The third piece overrides the speed limit only if I am at full throttle on both hand throttles at the same time, which means that I am trying to get out of someone's way and absolutely have to have max power and speed to do it, for however many seconds it takes.


The fourth piece overrides the CA's throttle output only if I am at full throttle (maybe if I am nearly there; have to play with it once built) on one of the hand throttles. This gets me the independent throttle control of each motor, whle still letting the CA do it's thing for the rest of the time and the TorquePAS control. (this is so I can steer with the motors, which I generally only do for sharp turns at speed, like at intersections or turning into driveways with traffic behind me).


The fifth piece determines if I stop pedalling, and immediately cuts the CA's throttle output, zero delay. (this is because it is too dangerous to allow any delay in shutoff, and the CA is apparnetly not capable of less than something over a second's worth of delay in shutting off output when I cease pedalling. (even though it *will* instantly stop outputting throttle signal as soon as I rotate pedals backwards a bit, but that's not good enough for my purposes).


Just a few changes to the way the CA handles input and output and I wouldn't need to do one, two, or five. :/ If I'm lucky I've just missed something for some of teh functions above, but Teklektik's already verified that the CA doesn't do what I need it to for the first function.

 

[amberwolf]

First, a bit of explanation of the CA itself, for Geeksville (or anyone else not familiar with it):

The Cycle Analyst (CA, v3 specifically in this case) is a device to take any or all of various inputs (torque sensor, cadence sensor, throttle, temperature sensor, current sensor, voltage, power, speed, etc) and create a single throttle output signal for a controller, based on those inputs and whatever settings have been created in it.

But it has limitations, one of the ones that's problematic for me being that you can't use pure torque sensor input to create a throttle output. It *has* to also detect pedalling via the cadence sensor (usually integrated with the TS, but doesn't have to be), before it will respond to any voltage on the TS input. There's reasons for this outlined below.

The CA is not open-source, and no code is available for it. So the simplest fix, of just removing that limitation, isn't available. (it would actually be more complex than that...and the code for it might not fit in the MCU it has without taking out other stuff that's also needed--see below for the complications, which are the reasons I think Grin doesn't do it already).

That means an external device, and a rather complicated one at that, to do it exactly the way I want it to work.


Some further research and experimentation over the last couple of years has determined some of the stuff I concluded in the previous post is not quite right, and that there are a lot more details to how this device must operate.

This bit is still true, and is the most important and complex part:

The first piece has to take the torque signal from the PAS unit and convert it into a throttle signal that bypasses the CA until the wheels start moving a bit, then lets the CA do it's thing. (this is because the CA cannot startup from torque alone, but has to detect some pedal rotation, but I need it to startup from just the torque, so I don't have to move the whole trike from a stop by pedals alone).

So I still need something that does this.

It doesn't have to be all that subtle--I really only need it to sense that I'm pushing on the cranks relatively hard, and provide immediate motor power at enough level to begin moving the trike, without me straining my aching joints to do it (or having to shift into the super-low-emergency-gear...which presently is where I just leave it all the time since I have to stop so often). The finer control it allows, the better...but I could probably live with less than that.


It will need a few other functions as well, that I've thought of since then, which make much more sense to implement in software (some form of MCU) than hardware, which puts it outside the scope of what I know how to do:


--The device would take the torque sensor signal itself (on my THUN that's a small-scale signal centered around 2.5v) and convert it into a throttle voltage (preferably a 0-5v signal, for finer scaling to whatever it is input to).

--This derived throttle signal (TH-D) then feeds into the Throttle In of the CAv3.

--In one version of this, the torque sensor wouldn't even connect to the CA Torque sensor input at all. This is simplest, but it means the CA can't directly monitor any human wattage input or other TS-derived data.

--In another version, the raw TS signal *is* sent to the CA's TS input, but *only* after the CA detects the trike is moving via speed signal (which is around 2-3MPH?). So the device will need to also monitor the speedo signal, and itself determine if the trike is moving. This would be used to let the CA do what it does with the TS after the inital problematic startup issue is bypassed.

--The cadence sensor would also be routed to an input of the device, and come unaltered from an output of the unit to the CA's cadence input, but the device would mask the CS input except beyond whatever limit was set in it. This prevents the CA from *also* responding to the cadence sensor. (I think it may already prioritize throttle input over CS/TS, but I don't recall for sure).

--The actual hand-throttles on the bars would input to the device (I prefer one on each side for when one of my hands goes numb, *or* for tank-style steering), and be passed thru to the throttle output. It would have a user-calibration function, to set it up for whatever throttle is actually in use on each input, and also allow a deadband to prevent undesired operation with temperature drift, etc. It would "expand" the range of a hall throttle to fill the 0-5v range, to match what it creates for the TS.

--If both that signal and the TS signal are present on the input, the TS will be masked and the throttle passed thru to the output. Otherwise, only the TS signal will be passed thru.

The way the device would operate is that at a stop, it would be masking the CS, and watching for TS or throttle input. When the TS input indicates sufficient torque on the pedals to signify demand for moving the trike, It would begin passing the TS input to the derived throttle output, with full-scale TS input equalling full throttle output voltage. (my system will be using torque/current-throttle controllers, so this will simply demand full power, not full speed). Lowest-scale TS input would be lowest-output throttle voltage. Wuld be nice if the response curve was user-creatable, rather than purely linear. If not fully user-creatable, then at least pickable from a number of preset curves, as it is likely that there will be need for fine control at low power levels.

Once above a speed where the gearing no longer allows TS response (may require additional sensing or user-settings), then the CS is no longer masked, so that the CA can take over creating a throttle signal from cadence alone.



Because there are issues with pure TS operation, such as the below, it will need some additional things:

For instance, if you happen to stand on the pedals at a stop waiting to go (like some trackstand maneuvers can be), you could with some sensors initiate unintended motor start, potentially at a high level if the sensor just detects distortion of the BB spindle from one side to the other. Easy to prevent by holding the ebrake, but the potential is there. Same thing with some sensors if you climb on the bike by using one foot on a pedal even already at it's bottom downstroke.

Another issue is calibration--torque sensors in general don't stay at exactly the same zero reading, and some fluctuate quite a bit, so the potential for it to power on at a setting that starts the bike going already without being touched exists.*** Or for you to let off the pedals, but it to still think it's detecting torque, and fail to shut off the motor.****

*** The fix for this is to autocalibrate it at powerup, just like other torque-based systems do, some of them by displaying a message to remove feet from pedals, then press a button, wait a second, and then it would be zeroed for the moment. This device probably wouldn't have a display (just would connect to the computer for changing it's settings, via USB or serial), but it could have an LED that flashes to caution you to not touch the pedals while it calibrates, and it could have a button next to that LED for manual recalibration.

**** The fix for this is to have something like the CA's throttle-setup-menu, that provides a range of minimal torque sensing input that is classed as a deadzone, where no response will occur until output goes outside that range. It's usually only a few hundredths of a volt change, but it is probably temperature dependent and other factors I don't know about, so rather than compensating for it, just mask out the entire driftable range.





This bit was caused by something in the CA itself to have "OEM limits" (which you can't see in the settings menus, only in the setup program on the computer). I've forgotten exactly what it turned out to be, but something like 1kw, which is about a quarter of the minimum needed to get moving at a reasonable acceleration rate for traffic around me, up to the 20mph max speed. So no matter what I did, this invisible limit was getting in the way. Was easy to fix once I found out what it was (I think Teklektik helped me find this problem).

The second piece has to determine if the CA is limiting due to speed or not, and if it's not limiting due to speed it overrides the CA's throttle output and passes my throttle straight thru to the controller. (this is because no matter what I do, the CA is limiting my power (W limit flag) at startup from a stop, the absolute one time I cannot allow it to do this).

So I don't need this bit in the addon device anymore.




The following bits would require the CA's throttle output to also route into the device, and be processed only if the following conditions are met. It requires the device have at least two throttle outputs (one for each motor controller). The last would be ideal anyway, so no Y-spliter in the wiring is needed.

The third piece overrides the speed limit (bypassing the CA's THo and outputing directly from THiL/R to THoL/R) only if I am at full throttle on both hand throttles at the same time, which means that I am trying to get out of someone's way and absolutely have to have max power and speed to do it, for however many seconds it takes.

The fourth piece overrides the CA's throttle output only if I am at full throttle (maybe if I am nearly there; have to play with it once built) on one of the hand throttles. This gets me the independent throttle control of each motor, whle still letting the CA do it's thing for the rest of the time and the TorquePAS control. (this is so I can steer with the motors, which I generally only do for sharp turns at speed, like at intersections or turning into driveways with traffic behind me).

For the fourth bit above, even more ideal would be an steering-sensor (position sensor/encoder of some type), that detects how far from straight the wheel is turned, and proportionally alters the throttle output to the controller so that the outboard one provides that much more power than the inboard, for even low-speed operation. It could also detect if I was in reverse-gear mode, and alter the "direction" to match that, if necessary.


This bit would be good, but not sure it's possible without a separate CS with as many magnet poles as would fit on a chainring and a sensor for those, and another input on the MCU. (well, really it wouldn't need another input, it would jsut use the "megapole CS" as the only CS input, and then interpolate this down to a 24-pole output for the CA's CS input).

The fifth piece determines if I stop pedalling, and immediately cuts the CA's throttle output, zero delay. (this is because it is too dangerous to allow any delay in shutoff, and the CA is sometimes apparently not capable of less than something over a second's worth of delay in shutting off output when I cease pedalling. (even though it *will* instantly stop outputting throttle signal as soon as I rotate pedals backwards a bit, but that's not good enough for my purposes).

So in total this needs a number of analog and digital inputs and outputs. This is the list I noted so far (there may be stuff I forgot):

Analog inputs required:
TS(2+?) (torque sensor)
THIL (throttle lefthand)
THIR (throttle righthand)
CATHoI (CA's throttle output)

Analog outputs required:
THOL (throttle left motor)
THOR (throttle right motor)
CATHiO (CA's throttle input)

Digital inputs required:
CS (cadence sensor)
SPS (steering position sensor)
SPD (speedometer sensor)
ManCal (manual calibration button)

Digital outputs required:
CACSi (CA's cadence input)
CalLED (calibration-mode signal)

 

[rowbiker]

First of all, amberwolf, your one paragraph explanation of what the CAv3 does is probably the best description of this device I've ever encountered. I think it's clear and concise, and not at all just for geeks. Your years of working with it certainly shows your clear understanding of it

I'm still digesting your post -- and will probably have to spend some hours really working my way through all the nuances and issues raised. But off the top, here's just one thought.

But it has limitations, one of the ones that's problematic for me being that you can't use pure torque sensor input to create a throttle output. It *has* to also detect pedalling via the cadence sensor (usually integrated with the TS, but doesn't have to be), before it will respond to any voltage on the TS input. There's reasons for this outlined below.

For several years I've been working on adding electrical assist to a device called a "rowbike" (see rowbike.com for photos of the stock bikes). This two wheel bike thing doesn't use pedals for propulsion, so using standard PAS/Torque devices isn't an option. My solution, generously provided by Justin, was the use of his "Skateboard" firmware loaded into the CAv3. When using this software, the CAv3 does indeed support a "pure" torque input to issue a standard throttle output signal to any controller you choose to use with it. In my case, I use strain gages on the handlebars and an instrumentation amplifier to provide the raw torque signal. The skateboard version of the CAv3 takes the torque signal on the Aux input port and outputs it on the throttle port. An added bonus is that I can use the existing Torque input port on the CAv3 and use it for regen braking. I've been using this setup for many road miles and am extremely pleased with the very responsive, smooth, and predictable behavior. With the right sensored motor/controller combination, you apply some torque and off you go.

In most other ways, this version of the CAv3 behaves 'normally'. In your case, you could use your existing torque signal as the input. The firmware has provisions for calibrating the required input and output values. It requires no physical modifications of the CA, so you can always try it and then go back to the stock firmware if you want.

 

[amberwolf]

First of all, amberwolf, your one paragraph explanation of what the CAv3 does is probably the best description of this device I've ever encountered. I think it's clear and concise, and not at all just for geeks. Your years of working with it certainly shows your clear understanding of it

I don't know that I really "understand" it, but I have some grasp of it's basic concept and some of what it can and can't do (as the regular release firmware stands right now).

For several years I've been working on adding electrical assist to a device called a "rowbike" (see rowbike.com for photos of the stock bikes). This two wheel bike thing doesn't use pedals for propulsion, so using standard PAS/Torque devices isn't an option. My solution, generously provided by Justin, was the use of his "Skateboard" firmware loaded into the CAv3. When using this software, the CAv3 does indeed support a "pure" torque input to issue a standard throttle output signal to any controller you choose to use with it. In my case, I use strain gages on the handlebars and an instrumentation amplifier to provide the raw torque signal. The skateboard version of the CAv3 takes the torque signal on the Aux input port and outputs it on the throttle port. An added bonus is that I can use the existing Torque input port on the CAv3 and use it for regen braking. I've been using this setup for many road miles and am extremely pleased with the very responsive, smooth, and predictable behavior. With the right sensored motor/controller combination, you apply some torque and off you go.

In most other ways, this version of the CAv3 behaves 'normally'. In your case, you could use your existing torque signal as the input. The firmware has provisions for calibrating the required input and output values. It requires no physical modifications of the CA, so you can always try it and then go back to the stock firmware if you want.

IIRC this has been proposed as a solution to me before (probably by you ) but I use the Aux port for my preset switch right now, that provides me a constrained "parking lot" mode with a 5mph speed limit, and will probably have other limits (power) once I complete this project:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=105711
While it isn't required, it's helpful (not just for busy parking lots full of pedestrians). I think there was some other reason, too, but I don't recall what it was now. (maybe it isn't applicable anymore?)

EDIT: I took a peek at your documentation page:
http://erowbike.com/ca
and this section here:
http://erowbike.com/ca.html#ca_settings_skateboard
which indicates

Note that we do optionally use a physical throttle (gripshift model) with this firmware, but the "throttle" device actually becomes a variable regen electric brake, so it functions exactly opposite its normal use.

If this means that it can't also use a regular throttle input to control the throttle output, then this firmware doesn't fit my needs, because I need the throttle to also go thru the CA (except when bypassed in very rare special situations as previously noted) for speed limiting, etc.

If it just means that I can *also* use a separate input for regen braking control, as well as the regular throttle, then that's fine--I won't need it with the Lebowski-HondaIMA setup (it has it's own regen input on each controller) though I could use it with the present half-grinfineon setup.


Reference: Justin's longboard thread with a bit of info:
https://endless-sphere.com/forums/viewtopic.php?t=88901



As long as it can also use a regular throttle input, I will still try it, if the "Skateboard" firmware also has the ability to deal with the potential problems noted previously:

For instance, if you happen to stand on the pedals at a stop waiting to go (like some trackstand maneuvers can be), you could with some sensors initiate unintended motor start, potentially at a high level if the sensor just detects distortion of the BB spindle from one side to the other. Easy to prevent by holding the ebrake, but the potential is there. Same thing with some sensors if you climb on the bike by using one foot on a pedal even already at it's bottom downstroke.

Another issue is calibration--torque sensors in general don't stay at exactly the same zero reading, and some fluctuate quite a bit, so the potential for it to power on at a setting that starts the bike going already without being touched exists.*** Or for you to let off the pedals, but it to still think it's detecting torque, and fail to shut off the motor.****

The solutions I imagine for them are:

*** The fix for this is to autocalibrate it at powerup, just like other torque-based systems do, some of them by displaying a message to remove feet from pedals, then press a button, wait a second, and then it would be zeroed for the moment. This device probably wouldn't have a display (just would connect to the computer for changing it's settings, via USB or serial), but it could have an LED that flashes to caution you to not touch the pedals while it calibrates, and it could have a button next to that LED for manual recalibration.

**** The fix for this is to have something like the CA's throttle-setup-menu, that provides a range of minimal torque sensing input that is classed as a deadzone, where no response will occur until output goes outside that range. It's usually only a few hundredths of a volt change, but it is probably temperature dependent and other factors I don't know about, so rather than compensating for it, just mask out the entire driftable range.

but there could be other solutions already implemented in the firmware you're using that I don't know about.


When you refer to using the actual TS input for regen, what do you mean?

 

[geeksville]

Sounds like a cool project. Alas, probably more than I can sign up for right now. It sounds like possibly an open-soruce replacement for that CAv3 device could fit the bill (but a fair amount of hw and sw work). But like casainho says, if you did the 'backend/analog' box as just a MCU with the right sensor/control hookups - the best way to get a GUI would be to repurpose the work we did there for his project.

 

[amberwolf]

Sounds like a cool project. Alas, probably more than I can sign up for right now. It sounds like possibly an open-soruce replacement for that CAv3 device could fit the bill (but a fair amount of hw and sw work). But like casainho says, if you did the 'backend/analog' box as just a MCU with the right sensor/control hookups - the best way to get a GUI would be to repurpose the work we did there for his project.

Yeah, I don't really need to *replace* the CA (it took them many years to get where they are now, with lots of people using it in different ways reporting bugs so they can fix things), just alter the way the torque sensing works at startup (and the other stuff because if it's already there...might as well do them too).

But even that is probably a lot of work, and the only help I can really provide is to test things as they're written, and provide suggestions on basic features, approaches, etc., as I don't know enough about the actual coding to do that part.

I can imagine the blocks of stuff that need to happen in the code, and some of what the code has to do...but I don't know how to actually write any of it.

 

[rowbiker]

When you refer to using the actual TS input for regen, what do you mean?

On the CAv3 using Justin's skateboard firmware, he repurposes the torque input wire on the CA's "PAS" connector ("TS") to do proportional regen braking. When used on an actual skateboard, this reflects the rider leaning back on the board to slow down.

On the skateboard you have two torque signals: leaning forward to go vs leaning backwards to stop. Which signal goes to which input on the CA is an arbitrary decision that's already made for you. For me, this was intuitively 'backwards', but it works just fine.

 

[amberwolf]

Makes sense, also having read your page about it. For me it doesn't truly matter what input is used, it's just inconvenient and kind of silly that I would have to make adapter cables to go from the Torque/PAS JST size to the AuxIn JST size. But that's life when adapting things for uses they weren't designed around.

I'm just a bit suprised that Justin didn't imagine this type of usage scenario when deciding which input to use for which, since the Torque/PAS input is already setup for this usage, wiring/etc wise, and the Aux would seem to be the best place for "other" inputs. But I expect that he started out developing the esk8 firmware by just repurposing the aux input, possibly comparing the results by switching input to the TorquePAS input to verify readout code, etc. (I'd probably do it like that, if I knew how), and then it just evolved that way. By now it's probably a lot of work to switch which input is used for what in the code.



Something I didn't quite get a clear sense of is whether or not the actual throttle input still works as expected. I'll have to test that part.

 

[rowbiker]

Something I didn't quite get a clear sense of is whether or not the actual throttle input still works as expected. I'll have to test that part.

If I remember correctly, the throttle input does NOT retain its functionality, unfortunately. On its intended use with an actual skateboard with no inputs other than the rider's weight distribution, this wouldn't be an issue. In my rowbike scenario, however, the option of using a manual throttle in addition to the torque sensing would have been nice to have.

 

[amberwolf]

If that's the case, then I cannot use the skateboard firmware, as I need the throttle to be subject to all the same limitations as the rest of the inputs (including whatever is different between presets).

Well, it was a nice idea, anyway. :/

(I'll still test it on my spare CA to verify, once I have time).

 

[rowbiker]

Thanks amberwolf. Please make sure to post your results here when available, since it's very possible I've missed something that you'll catch!

 

[amberwolf]

While I never have pursued this further yet, I have now begun (barely) to learn Arduino, and have actually sent my first code to a Nano to blink it's LED.

So I have started a different thread for making the modules that would do some of the things in this thread, over here:

https://endless-sphere.com/forums/viewtopic.php?f=2&t=110497

whcih will contain not only the stuff for this particular project, but also any other Nano/etc MCU thingies I work up to do odd jobs around the trike, etc., that other devices I'm aware of simply don't do.