PINNED - Roboteq Controller - developing for powerchairs

[LROBBINS]

There's a fundamental mixing error somehow.

I agree, and it's most evident when command goes from turn to stop-turn and the red line goes up but the green line doesn't go down at all. I think I have to take the time to re-think all of this, starting with looking at the basic accelmix calculations to see what, if anything, it's doing with turn-in-place. I think it's not doing anything at all because the whole procedure is divided into an "if accelerating" and an "if decelerating" section, so maybe I have to add "if increasing turn" and "if decreasing turn" sections.

Suppose you turn in place then let go of the stick without moving forward or back. Does the green line move down and the red line move up? Equal and opposite?

One thing about terminology I want to clear up though, or we'll forever be talking at cross purposes. If you are turning in place and transition to straight forward, until the rearward going wheel reaches 0, IT IS NOT ACCELERATING. It is going less strongly backwards, hence it is decelerating. If you go from turning in place to Throttle=0, Steering=0 both wheels are decelerating. The rearward going wheel is going less strongly backwards and the forward going wheel is going less strongly forwards.

Clearly, I've not dealt properly with turning, but could you also check the straight forward and back behavior (without turning)? Can you get decent initial acceleration without later hyper-acceleration? Can you get decent initial deceleration without later hyper-deceleration? I'd like you to check this by going straight forward and then back to 0 (not past 0) and then by going straight back and returning to 0 (not past 0). Can you get decent starting accel/decel by increasing RPMaccel/RPMdecel? and avoid the woosh effect by reducing MiAccel/MiDecel?

Also, to give me an idea of what accel and decel are needed to start and stop movement, with RPMaccel = 0 and RPMdecel = 0 what (low) values of MiAccel and MiDecel give a reasonable final acceleration, and what (high) values of MiAccel and MiDecel give a reasonable initial acceleration? I'm trying to think of some completely different ways to approach the two problems of movement start/stop and turn start/stop (starting from your notion that we should deal first with movement accelerations and then superimpose turning acceleration corrections), but I need some idea of what reasonable base values are and how much they have to be boosted.

To repeat the specific questions I'd like you to answer:

Suppose you turn in place then let go of the stick without moving forward or back. Does the green line move down and the red line move up? Equal and opposite? [You can try this with RPMaccel and RPMdecel = 0. Obviously, turning will be sluggish with increasing acceleration/deceleration over time, but I just want to know if the two lines converge properly if there's no attempt to boost things.]

Can you get decent starting accel/decel by increasing RPMaccel/RPMdecel? and avoid the woosh effect by reducing MiAccel/MiDecel? (NO TURNING)

With RPMaccel = 0 and RPMdecel = 0 what (low) values of MiAccel and MiDecel give a reasonable final acceleration, and what (high) values of MiAccel and MiDecel give a reasonable initial acceleration?

Ciao,
Lenny

[Burgerman]

OK will do that tomorrow. Just back from the pub so unwise to try thinking hard!

Suppose you turn in place then let go of the stick without moving forward or back. Does the green line move down and the red line move up? Equal and opposite? [You can try this with RPMaccel and RPMdecel = 0. Obviously, turning will be sluggish with increasing acceleration/deceleration over time, but I just want to know if the two lines converge properly if there's no attempt to boost things.

Yes. It behaves exactly as it should. Linear and symmetrical accel/decel to each wheel. With the newest script. But way too slow. (This is from memory) but will check tomorrow. No acceleration over time, straight lines only. You get triangles...

See image.
Turn in place, release. Same high settings as before. Latest script. Takes over half a second for wheels to reach turn speed, and the same for them to stop on release. That's a little slow even with high settings for turn. This is normal acceleration rate. I think. But symmetrical.

[Burgerman]

RPMAccel = 9000 No noticible affect at all???
RPMdecel = 9000

RPMAccel = 90000 No noticible affect on acceleration or initial reaction time, still takes about 5 seconds to 16mph.
RPMdecel = 90000 Stops from 16mph in 1 second...

I can get fast starting response by:

Changing
M1Accel to 10000 (instead of 2200 for all). Five times greater.
M2Accel to 10000
M1Decel " 10000
M2Decel " 10000
Results in a reasonably fast initial reaction to joystick, so would wheelie etc as per PG drives setups. As I would want it.
However it now would hit 15mph in 1.5 secs. Or rather I would be laid on the road! Without sitting in it not sure how accurate this 10k figure would be.

[Burgerman]

After lots of evaluation and thinking time I am of the opinion that I understand the problems and there are 2 seperate issues.

1. The TURN in place problem. The logic error exists in the last 6 months algos. Or maybe always has. That "green line" that doesent dipin the graphs above is the cause of the turn and go direction problem.

2. The ACCELERATION delay. The forward acc problem, ignoring the logic error, is that I need drastically different acc/dec rates for each axis. But the same speed of responce around the neutral point.


The forward acc initial delay (or slower feel) is because I need a low 5 second or so acceleration to reach 16 mph or it flips!
Although conversely I want to reach full steer left/right in around 1/4 of a second so it goes where I tell it...

But want the same forward "feel" and reaction time to the joystick from zero position to full forwards or reverse, as when I turn. Not easy!

So forward acceleration must be set to around 20x slower than turn acceleration. Yet have the same initial response speed at low speeds.

[LROBBINS]

RPMAccel = 9000 No noticible affect at all???
RPMdecel = 9000

RPMAccel = 90000 No noticible affect on acceleration or initial reaction time, still takes about 5 seconds to 16mph.
RPMdecel = 90000 Stops from 16mph in 1 second...

This confirms what was already noted: that script has some FUNDAMENTAL flaw. So, starting over from scratch, here's another one to try that does things in a much different way:

'in this version:
'accel and decel are boosted proportionate to difference between power and command values (without considering current)
'then accel/decel are adjusted for difference between current and target turn rates,
'finally mixing is done (as previously) for turning while moving and the "stick-cross-zero" is applied if needed

The parameters are:

'boost of accel/decel proportionate to difference between MotorCommand and MotorPower
PowerAccel = 100
PowerDecel = 100
'boost of accel/decel proportionate to diffeence between targetTurnRate and currentTurnRate
TurnAccel = 200 'has 10X the effect of boost for Power
TurnDecel = 200
'mixing of acceleration and deceleration when starting and stopping turns
AccelMix = 900
DecelMix = 900

I have installed the CAN equivalent in Rachi's chair, and it's OK there (for what that test is worth) though deceleration is MUCH too strong so I have to adjust some parameter values.

I have also, as boring as the process is, run this in the Roborun simulator and followed the numerical values of M1Accel, M2Accel, M1Decel and M2Decel going straight, just turning, turning in motion and going from there back to 0-0, and going from turn-in-place to going straight forward without stopping. Best I can tell, given that the numerical simulation is in chunks rather than continuous, things are behaving as I intended them to. Hopefully, this behavior is not only as intended, but correct as well.

Happy testing.

Ciao,
Lenny

[Burgerman]

We will soon see!

'previous attempts to adjust boost accel/decel to even out phsyical acceleration and deceleration didn't work
'deleted in this version to work on other approaches

'in this version
'accel and decel are proportionate to difference between power and command values (without considering current)
'and accel/decel are adjusted for difference between current and target turn rates

That sounds logical.

[Burgerman]

Initial playing about. You are correct! Deceleration is about 10x greater. Forward acceleration is set to really really slow, to show what I am talking about!

Because the logic error still exists. (I think)

This is what we see, when I zero turn, and then accelerate towards an imaginary doorway.
Note the top motor command here (green) maintains its forward speed, and the bottom red (reversing) wheel, accelerates to catch it up. Very quickly. However it means the chair continues to turn initially as you accelerate.

This is what I would EXPECT to see. This is actually what we see when I just look at the joystick input. (And what I would logically expect the motors to do unless I am wrong.) They converge, (the forward going wheel slows down), then both rise together. Ringed. Note, this is not from the same graph, its simply in place of a drawing to demonstrate what I think should happen!

[Burgerman]

And PowerDecel is quite wild at 100. Its almost impossible to set deceleration low enough. Both motor dec and powerdecel. And it starts very high, and tails off to very low, so is working. When set to Powerdecel = 20 it appears to sort out that increasing deceleration I used to get. By giving a deceleration curve that lowers in rate as I slow.

And PowerAccel = 100 or up to several thousands, (tried up to 8k) doesn't seem to change anything at all? I see a linear x rpm per second increase in motor rpm regardless of figures entered. (other than a serious boost from reversing to 0mph, when I hit it a forward command).

If it worked, it would fix my wheelie at speed problem. But might still need an initial low pulsewidth boost at zero to .5mph to 1mph.

[LROBBINS]

Obviously, there's still something very wrong.

I haven't yet figured out what's not working with turning, but I have figured out the trivial mistake that made PowerAccel do nothing no matter what its value even though PowerDecel was working wildly at 100 and reasonably at 20.

In the old MixAccel section I had lines like:

Code: Select all

NewM1Decel = BaseM1Decel+DecelDelta
NewM1Accel = BaseM1Accel+AccelDelta

In the deceleration sub-section I had changed this to:

Code: Select all

NewM1Decel = NewM1Decel+DecelDelta

to take into account the boost done by PowerDecel and TurnDecel, but I hadn't changed it in the acceleration sub-section so when accelerating it got reset to the base value and completely lost the effect of PowerAccel.

So here's a new script to try. It should at least let you get rid of the ramping acceleration as well as deceleration. (Make sure to change the parameters first in accord with your last tests.) It may also have some effect on turning, but I am not going to try to predict what effect it will have. You tell me.

Ciao,
Lenny

[LROBBINS]

Just took a look at the CAN version because it did seem to be working for both PowerAccel and PowerDecel -- of course it was as I had already changed those lines from BaseMiAccel to NewMiAccel. Annoying thing is that yesterday I had already discovered a similar mistake in a different place in the CAN version. Although Master was sending accel and decel parameters to the Roboteq, the Roboteq never used those, but continued to use the ones at the top of the script file. The reason was that the values sent over CAN were going into MiAccel and MiDecel instead of into BaseMiAccel and BaseMiDecel which are used at the start of all of the calculations. Only discovered this when I manually changed the values at the top of the script to the very low ones I was sending from Master and the chair refused to stop accelerating and stop decelerating in anything like a reasonable distance. So, just for reference, here are the values that are working well in Rachi's chair:

Code: Select all

M1Accel = 3500
M2Accel = 3500
M1Decel = 2200
M2Decel = 2200
'boost of accel/decel proportionate to difference between MotorCommand and MotorPower
PowerAccel = 100
PowerDecel = 100
'boost of accel/decel proportionate to difference between targetTurnRate and currentTurnRate
TurnAccel = 100
TurnDecel = 100
'mixing of acceleraton and deceleration when starting and stopping turns
AccelMix = 400
DecelMix = 400
DecelBoost = 200


Notice that I too found PowerDecel = 100 to be too strong with MiDecel set at 3500, but I tamed things by reducing MiDecel rather than changing PowerDecel. Don't know which is better; reducing the base rate or reducing the boost effect, but you might try both ways of calming things down.

Ciao,
Lenny

[Burgerman]

Responding to the post two above!
It gives an initial high rate, then more gentle rate of deceleration in a smooth decreasing curve. And stops gently.
It will likely do the same on acceleration once it works. Which should give a real world approximation of actual linear acceleration. So no unexpected flips as speed increases.

But it might also need a really steep forwards/reverse acceleration/dec curve added just around the stick centre that tails off to zero by say 1 to 2 mph. And leave the rest of the line alone. To remove that initial slowness in setting off when you touch the stick.

Turn is almost instantanious. Its as if the stick is connected directly to the wheel. Since the wheel only needs to reach about 10% or the rpm for a full turn. And because accel can be really high since it only involves reaching a very low wheel speed. At low forward speed we need the same. I am not sure your new acc/dec curves will achive this, but they may do.

Only that odd steer logic lets it down. Strange how will doesent see this. I can feel it when driving in the house quite clearly.

[LROBBINS]

Try out the new version. With the mistake in PowerAccel, once the chair is being told to accelerate, the effect of TurnAccel was also being zeroed out, so there'll most likely be a difference, just don't know if TurnAccel will now do what I wanted it to do. I have run some more simulations (only numerical output, no curves are generated) and the activation of PowerAccel definitely affects what happens when you go from turn-in-place to moving straight forward. BUT, I don't know if what it is doing is good or not -- when starting to move forward while turn straightening, the simulated steering actually oscillates around 0, if it starts with positive steer, it first goes to negative steer, then to back to positive. The oscillations keep getting smaller but it only settles on a solid 0 when forward acceleration has finished. I don't know if that oscillation around 0 will be a steady 0, or very close to that, when there's an actual controller rather than the simulation that goes in big steps, but it might. Or might not, my brain can't follow all these plusses and minuses no less the changes of amount.

As to whether one wants the acceleration/deceleration boosting to gradually disappear, or to completely disappear at a relatively low speed, will depend on how it feels to you. My suspicion is that if it's removed completely too quickly, you will still feel the continuously increasing acceleration after you start moving - you'll just get off the blocks more sharply. If it turns out that you want it to disappear more quickly, or follow a logarithmic rather than linear progression, it shouldn't be hard to do that, but I'd like you to get some experience with it first.

As to Will's not feeling the turn stopping problem, that could be because he tends to manually stop the turn before moving off, or because accel/decel with brushless are actually deltaRPM/time instead of deltaPWM/time. I'd have to have a brushless controller to figure out just how much that different definition of accel/decel affects things.

Ciao,
Lenny

Ciao,
Lenny

[Burgerman]

OK...

Testing with the:
M1Accel = 300
M2Accel = 300
M1Decel = 700
M2Decel = 700 -- All reduced from 2200.

PowerAccel = 40
PowerDecel = 10

TurnAccel = 150
TurnDecel = 150 - seems about right.

Gives much improved acc response initially, very good accel off the line and no wait. Feels like the steer response. But the acceleration is then too fast after this, esp in the middle speed range (which is 8mph on this chair) and too slow towards max speed where it tails off naturally anyway. Its a long curve. Ideally it needs to stay hard initially, but taper off almost completely by around 15 percent of speed (or adjustable). (ADDED Acceleration boost needs to tail off long before half speed is reached)

Deceleration is only going to need a tiny boost addition. To make it linear in reality. And stop it from slowing harder over time. And I think it does this.

Reverse is very low acceleration. And very sudden forward acc if you are reversing and choose forward stick. Will need care... But my PG chair is the same.

Turn is about correct set to 150 boost. At least on blocks...

In all a great improvement, but we still have that turn thing going on.

Note, after release from zero turn, it still turns during the period of the vertical black lines.

And note forward acceleration increased by large margin at start, tailing off to low level and 8 seconds to full speed. This acceleration boost really needs a parameter that allows it to end at 5, 10, 15, 20, 30% speed - adjustable to get it correct. Or better still have it add "less" boost as speed increases in linear (square?) fashion? We may really need a short steep boost acc "curve" then a straight line at a lower acceleration the rest of the way.

[LROBBINS]

OK, good progress. Having the accel boost quit at a variable % of power is easy to do. The turn "thing" is another kettle of fish, and I don't know what to do about it. Notice the very beginning of the green line when you move the stick? It very briefly, but only very, very briefly does what it should. I have to figure out how to get it to continue doing that. I'm thinking about "faking" the Throttle and Steering values; keep track of last values, if last Throttle was 0 (or near 0), and new Throttle is high, keep using the old Throttle value until turn gets to at or near targetTurnRate, then let it use the new Throttle. That would take care of accelerating straight ahead out of turn in place, but I don't like the notion of "near". How near? If we demand exactly 0, it may never actually be there because of noise and/or stick jiggle. If too far from 0, it might improve things, but there'd still be some turning when throttle advanced. Also, what about going to turn-in-place from full forward stick? Isn't there a problem doing that as well? This wouldn't help that.

And very sudden forward acc if you are reversing and choose forward stick. Will need care... But my PG chair is the same.

And probably rather abrupt if decelerating and you pull the stick back past 0 - it is that way on Rachi's. You might try lowering DecelBoost which should really be called "Crossed0Boost" or some such; it boosts whether accelerating or decelerating once you cross 0 in either direction.

I wish I had that second Roboteq. It's kinda frustrating to do things without being able to really test them some before I send them to you. I'm going to order another one, but not until there's someone coming here from the U.S. who's willing to carry it in baggage as I don't want to pay the high shipping fees + 22% VAT (getting Italian customs to reimburse VAT overcharge is hopeless, asking shippers to actually show the 4% reduced VAT documents to customs hardly ever works). Of course, after today's murders in Paris, they're probably going to be inspecting baggage with extreme attention, and it might not be possible to take a blue box onto an airliner anyway. I was going to wait until Roboteq's next board revision, but they've now told me that it will be some (long and indefinite) time until that happens.

Ciao,
Lenny

[Burgerman]

OK, good progress. Having the accel boost quit at a variable % of power is easy to do. The turn "thing" is another kettle of fish, and I don't know what to do about it. Notice the very beginning of the green line when you move the stick? It very briefly, but only very, very briefly does what it should.

That depends how accurate I move my hand, how fast, etc. So I wouldn't take too much notice.

Also that faking thing may not be wise. Because I don't always gun it straight ahead. I may be aiming at an angle, accelerating in a curve, etc. I change mind as I pull away to miss a human etc. I think its a consequence of the very way the mix algo is working.

The forward acc boost needs to be higher. To get a crisp start. But then needs to weaken fast -- maybe with the sq of the pulse. Leaving just "normal" acceleration.

[LROBBINS]

But then needs to weaken fast -- maybe with the sq of the pulse.

I am pleased to offer the attached file almost before your fingers have left the keyboard. An added parameter offers you 5 choices for how strongly PowerAccel (and PowerDecel) decay:

Code: Select all

PowerCurving = 5 '1=no curving, 2=mild curving, 3=mid curving, 4=strong curving, 5=full curving
' these correspond to X, X^1.24, X^1.4, X^1.56, X^2

I don't like the fudging idea either, so haven't started working on it anyway, but I still haven't thought of better. Perhaps I should just leave it a day or two to let my subconscious work a bit (unless I get inspired in the middle of the night).

Ciao,
Lenny

[Burgerman]

I like the midnight idea.

I might need this for reverse acc too. Since reverse and slowing in reverse seem very sluggish now. How does the acc boost affect reverse?
You can see how the commercial ones end up with so many settings cant you.


As an aside, I managed to set dec so slow, that it just didn't
an up to full speed fine, and stayed that way no matter what I tried. Had to turn the roboteq off...

[LROBBINS]

Yes, PowerAccel and PowerDecel don't depend on direction of travel, just on the absolute value of the difference between MotorCommand and MotorPower. If you're not getting enough accel in reverse, where the lower maximum command, 26% in your case, means that the starting difference is smaller, you'll have to increase PowerAccel and reduced M1Accel and M2Accel (really should change this to just one Accel parameter). If necessary, but not now, we could complicate things by scaling by speed pot value so you get maximum boost when command = speedpot(fwd or rev)max.

Let me know how the different accel curvings work out. Note however that the sooner the boost is reduced (the stronger the curving), the less effective it will also be in reverse (the square of 26%, your reverse max, is under 7%).

Ciao,
Lenny

[Burgerman]

Yes, PowerAccel and PowerDecel don't depend on direction of travel, just on the absolute value of the difference between MotorCommand and MotorPower. If you're not getting enough accel in reverse, where the lower maximum command, 26% in your case, means that the starting difference is smaller, you'll have to increase PowerAccel and reduced M1Accel and M2Accel (really should change this to just one Accel parameter).

Reverse acc is much slower than forward acc. And. If I turn speedpot down to a low level, forward acceleration is now far too slow as well. Yes I realise its the same thing /cause. But that doesent happen with my PG chair.

So it looks like we may need high both high and low speed acc/dec parameters just like normal mobility controllers. For turn, but thats not so important, but definitely for forwards (and reverse).

I wonder exactly what for eg:

Forward acceleration
Min forward acceleration
Reverse acc
Min Reverse acc
Turn Acc
Min turn Acc
(Plus the decelerations)

- Actually change?
I suspect that Acceleration in all four cases, controls max linear acceleration on the 4 axis.
Min Acceleration controls acceleration rates (increasing them) at small throttle stick or low speedpot settings.

Because I FEEL through my backside, the same Acceleration, and deceleration, at low speeds, regardless of speed setting choosen, or how far you push the stick.

I suspect acceleration/dec is the same rate or almost so, at 1/4 stick, as it is at full stick if setting off from a standstil, or turning. Or is this only caused by compensation? And that only the point where it stops acceleating (runs out of pulsewidth/volts) depends on stick position. This is what my backside tells me, in a maxed out pilot plus chair.

If necessary, but not now, we could complicate things by scaling by speed pot value so you get maximum boost when command = speedpot(fwd or rev)max.

I think we may need to do this - not based on speedpot - but on all control inputs, but based on joystick percentage input. So that a lower joystick input level gives the higher acc or dec value. Something about what I just wrote is bugging me and doesent make sense...

Will test the new fixes tomorrow.

[LROBBINS]

I will wait for your results from tomorrow re: curving the boost. I already have several other files for you to try depending on those results and I'm surely going to get both of us too, too confused if I keep going without those results. For example, I've done two (somewhat) different things to try to get "turn priority" in all circumstances, and I'll send you at least one AFTER we know whether the curving code works. However, there is one thing I'm going to do this morning and send you before tomorrows' testing:

So it looks like we may need high both high and low speed acc/dec parameters just like normal mobility controllers.

We could do that, but I don't like the idea. I'd rather do this:

Code: Select all

in place of:

M1Delta = (CurvedM1Diff*PowerAccel)/10
use
M1Delta = (CurvedM1Diff*PowerAccel*SpeedPot)/1000

this will automatically adjust for pot settings, including the difference between forward max (100) and reverse max (26), making the latter ca. 4X stronger.  It will also adjust for pot position - e.g. for forward with pot at 50% strength will be doubled.

and, in place of:
TurnDelta = (TurnDiff*TurnAccel) 'note already arbitrary factor of 10 higher than for Power
use
TurnDelta = (TurnDiff*TurnAccel*TurnPot)/1000

at TurnPot = 15, this will be 6.67X stronger than for Power, on Rachi's with TurnPot = 22, it will be 4.5X stronger


I think that doing it this way is better for a couple reasons: (1) no extra parameters to fiddle with, (2) it's the equivalent of setting high and low speed acceleration (in PG terms) to 100%.

I suspect acceleration/dec is the same rate or almost so, at 1/4 stick, as it is at full stick if setting off from a standstil, or turning. Or is this only caused by compensation?

Compensation will have a big effect here. When you start from a dead stop, the initial current draw will be just as high, and very high, whether you use full or part throttle. If compensation were "tuned" to the point of almost unstable, this would indeed give exactly the same initial acceleration because the motor compensation adjusted throttle will be 100% in either case. However, once the motors fall back from near-stall current, the drop off in accel at part throttle will be quicker than the drop off at full throttle.

In at most a couple hours, I'll get you a modified version of the last file I sent with the auto-adjusting Power and Turn boosts added.

Ciao,
Lenny

[LROBBINS]

Well, that didn't take long. Here's the same script modified to adjust for pot setting. It should give the same accel/decel boost whether going fore or aft and with pot turned up or pot turned down (if I didn't make another stupid copy-and-paste mistake). I await your testing.

[Burgerman]

I will get mixed up too! Do I skipb the previous one? Will do one script at a time.
I have a new one on my desktop to try first. With the 5 seetings for boost...

If I wasnt disabled I would love to leap in and out to test how these things feel when fine tuned. I need a test pilot that knows whay he is doing/sensing but there isnt one! But that involves transfers, carers, beds, etc. So I plan it for a day or half a day. Then have to wait to test on blocks again another day. It all takes a bit of planning and organising. And I still want to lift up the seat front edge, again, meaning two new alloy bars and some manual work. Because theres inadequate seat dump. I overdid an adjustment... And machined too much off.

Will test the one above as soon as I can today, about 1pm. And report back! I suspect it will be good, and will answer a few questions but needs testing while in the chair.

[Burgerman]

Before xmas, I am ordering http://www.roboteq.com/index.php/robote ... 130-detail both to build a RC mower/edge trimmer, and because it will make a good test device with the same handling characteristics as the powerchair. Without dying. Running 6v motors at 24V.

Will it run your code/script as is, without specific modification?

It may be very helpful.

[LROBBINS]

Yes, skip the last one and use "John 11-14-2015 temp2_mod". You will, however, need to adjust the various parameters - probably need a bit higher TurnAccel and TurnDecel because the turnpot effect will be a multiplier of about 7 instead of the arbitrary, hard-coded 10 there's been before now.

If I wasnt disabled I would love to leap in and out to test how these things feel when fine tuned. I need a test pilot

And if Rachi didn't need her chair, and my back weren't hurting, I could get hers jacked up (or disconnect the motors) to do the same. You need a test pilot, I need another Roboteq. Without that this is an inevitably slow and confusing process. As a (professional programmer) friend just wrote me:

Debugging an embedded system is challenging enough. Debugging an embedded system containing a major component you didn't design is worse. Remotely debugging an embedded system containing a major component you didn't design? That'll separate the men from the boys!

Before xmas, I am ordering http://www.roboteq.com/index.php/robote%20...%20130-detail ... Will it run your code/script as is, without specific modification?

Except for having only 2 digital outputs, it might do for your testing - but the only digouts you'd have would be 1 for the contactor and 1 for brakes (or any other 2 you'd choose) and you'd have to find, and comment out, any parts of the code that need other digouts.

For me it won't work because it doesn't have a CANbus interface. I also want a 2nd Roboteq as a backup in case of a breakdown in Rachi's chair. She has only 1 power chair, and we wouldn't have room for a second anyway, but all the electronics is mounted in a quick-release fashion so swaps of dead modules can be done quickly. The current state of my back was provoked by trying to diagnose and fix the failed system back in early August, before I had the quick mounts so I even had to horse batteries in and out repeatedly, and with a trip to the U.S. scheduled for the end of the month. I actually got it back running just before we left, but I wasn't about to trust it 8,000 km from my shop so we took her ultralight push chair (that is only used for such "emergencies").

Ciao,
Lenny

[Burgerman]

Except for having only 2 digital outputs, it might do for your testing - but the only digouts you'd have would be 1 for the contactor and 1 for brakes (or any other 2 you'd choose) and you'd have to find, and comment out, any parts of the code that need other digouts.

I dont think I would need any dout other than the Status LED.
If I left the code in, but never used any dout pins, it would cause errors?

I may use a couple of digital or analog ins to reverse it if it hit anything via sensors/microswitches. So it could cut grass on its own... And the battery low to stop it. But those are already built in.

[woodygb]

As you know I dabble in Robots and recently installed a VDC2450 ... purchased by my team mate..into the current bot.

Questions.

Would the bot drive better with a modified version of the script ? ... I'm happy to go through it and comment out anything irrelevant.

Could I be of any help if I uploaded the script to my current setup ? ... NOTE Current sensors are on my to do list .... but it has nothing extra added as yet ... it's just a bare Roboteq using RC inputs.

[Burgerman]

Would the bot drive better with a modified version of the script ?

Depends what you are using now. Its almost undrivable without any script! It will definitely be much better with the script that I am using than non at all. Of that there's absolutely no doubt. The roboteqs mix algo is hopeless.

So I presume you are using the same as I am? I think its also pretty bad without current sensors. It doesn't slow, doesn't accelerate or steer consistently. So I am not sure how much it would tell you without them. If the bot is light or uses casters then you may get an idea of what's going on. Its really not bad, its just that it could be better! If its heavy, tank steer, without any motor compensation it will be horrible to drive in any sort of steady controlled accurate fashion.

[woodygb]

The bot weighs 100kg ...has casters on the front and is nose heavy ....std Bot setup using one motor per side just like a wheelchair.

It had it's first outing with the Roboteq installed last weekend... I didn't attend the event ... and apparently it drives like a pig.

NO SCRIPT of any sort is currently running it's just using the Roboteq's RC mix algo.

I'll order up some current sensors.

[LROBBINS]

Don't order current sensors yet! The VDC has only 4 analog inputs. 2 for joystick leaves only 2. If you don't need a speed pot, I guess you can get away with it. It also has only 2 digital outputs and no USB (if you don't have an RS232 port on the computer you'll be using, you'll need an adapter). Some script changes will be needed.

Ciao,
Lenny

[woodygb]

These?

http://www.ebay.co.uk/itm/111689533182? ... EBIDX%3AIT