Arduino controlled wheelchair

[gcebiker]

Interference is gone, seems to go away late at night... Long un shielded connection to test points is not a best situation to have.

I have been able to test just now and the base is no longer responding to the code...i have made a few changes, i will have to back track and find what worked i hope i did not fry something with the DWiZ testing, i doubt i did but its nagging at me at the moment.

Mostly likely to be code or wiring issues.

[gcebiker]

Found working copy of code, one where the base responds at least...

Now to try to go forward with Irvings code for the Data Speed, direction and Speed pot.

[gcebiker]

No success as yet, i tried to rename the variables, ill keep trying. Dumb luck has to win out eventually....

[Irving]

Hi

Yes I did make a mistake in my code and accidentally swapped speed and direction in the 'data[4]' element, you were right to swap them over.

In my defence its bad practice to declare speed as the lower byte (byte[0] == data[1]) and direction as the next byte up and then in the LSB bit coding make the lower one the direction and upper one speed! Logically they should be in the same order.

Your code is broken though, because as written you assign them to themselves not to the data bytes... it should read

Code: Select all

    speedpot = 255;     // this is a fixed value ...being full speed on the Shark Remote
    data[0] = (0x60);    // Packet type identifier

    // Assign joystick and speedpot MSBs values to data[1 ] - data[3]

    data[1] = (speed >> 3) & 0x7f;
    data[2] = (direction >> 3) & 0x7f;
    data[3] = (speedpot >> 1) & 0x7f;

   /* encode LSBs into data[4] as follows
       bit 6: Speed pot reading LSB
       bits 5-3: Joystick speed reading (3 LSBs)
       bits 2-0: Joystick direction reading (3 LSBs) */

    data[4] = (speedpot & 0x1) << 6 | (speed & 0x7) << 3 | (direction & 0x7);

    // end of code for data


[gcebiker]

I tried to stuff all the info into the one picture to try and help make it easier to understand.
Top trace in pic is the result of the above BitMath, i thought perhaps i had declared the variables wrong, as 'int'

So i went through and reworded the variable to SpeedXXX and DirectionXXX, changed 'int' to 'unsigned int'
did not seem to help, also tried not using the mapped values V the mapped, i am still fiddling with the code as i am sure Irving is right and its something i have earlier in the code that is messing things up.



I am also a little confused, i thought bit numbering went left to right
ie n0,n1,n2, ... but turns out could be either way depending on if its numbered LSB or MSB...bloody hell.

I took the factory notes to be numbered 0,1,2,3..
so
0,1,2 |3,4,5 |6 |7
Direction pot |Speed pot|Max speed|

Which would be the opposite to ?

data[4] = (maxSpeed & 0x1) << 6 | (speed & 0x7) << 3 | (direction & 0x7);

/* encode LSBs into data[4] as follows
bit 6: Speed pot reading LSB
bits 5-3: Joystick speed reading (3 LSBs)
bits 2-0: Joystick direction reading (3 LSBs) */

So i will try

data[4] = (direction & 0x1) << 6 | (speed & 0x7) << 3 | (maxSpeed & 0x7)

I will also go through and rename the speed pot as its ambiguous with the renaming of the X/Y pots , i will change to 'maxSpeed' per the different naming in this post.

I am still working on the code even now, just notes for myself and anyone following.

[gcebiker]

Gone back to mapped values for Speed, Direction and Fixed value for maxSpeed so that i am only working with one variable
...that is the one for Data4 - hoping that with known values, i can do the bit math by hand this one time for neutral values and try to get the expected result

I had to take out half the code and notes just so it would even post this snippet.

Code: Select all

speedPotVal = analogRead(speedPot);
    directionPotVal = analogRead(directionPot);
    speed = map(speedPotVal, 0, 1023, 128, 255); // Map min/max pot values to match min/max original Shark joystick values.
    direction = map(directionPotVal, 0, 1012, 128, 255); // Map X values
  }
    /* Following are notes on Shark Remote data Byte information packets (what each byte holds data for)
        Type 00 SR General Information
      This packet contains the joystick speed and direction ( 10 bit readings), speed pot setting (8 bit reading), and input and status
      bits.
      The minimum allowable length for this packet is 6 data bytes.
       */
    maxSpeed = 255;     // this is a fixed value ...being full speed on the Shark Remote
    data[0] = (0x60);    // Packet type identifier

    // Assign joystick and speedpot MSBs values to data[1 ] - data[3]

    data[1] = speed;         // (speed >> 3) & 0x7f; // Joystick speed reading (7 MSbs)
    data[2] = direction;     //(direction >> 3) & 0x7f; // Joystick direction reading (7 MSbs)
    data[3] = maxSpeed;      //(speedpot >> 1) & 0x7f;   // Speed pot reading (7 MSbs)

    /* encode LSBs into data[4] as follows
      bit 6: Speed pot reading LSB
      bits 5-3: Joystick speed reading (3 LSBs)
      bits 2-0: Joystick direction reading (3 LSBs) */

   data[4] = (maxSpeed & 0x1) << 6 | (speed & 0x7) << 3 | (direction & 0x7);

[gcebiker]

its bad practice to declare speed as the lower byte (byte[0] == data[1]) and direction as the next byte up and then in the LSB bit coding make the lower one the direction and upper one speed! Logically they should be in the same order.

I see what you mean , when i typed it out in Word in a Table its all arse about face..



Its also interesting that its written eg 5-3 ...instead of 3-5 so the numbering must be n7,n6,n5.... ?

[gcebiker]

...i think i am even more confused working it out long hand.
Tho quite unexpectedly..not ! i got the wrong result...

[gcebiker]

Hi
/* encode LSBs into data[4] as follows
bit 6: Speed pot reading LSB
bits 5-3: Joystick speed reading (3 LSBs)
bits 2-0: Joystick direction reading (3 LSBs) */

data[4] = (speedpot & 0x1) << 6 | (speed & 0x7) << 3 | (direction & 0x7);
[/code]

Going about understanding the above differently....
(speedpot & 0x1) = (255 & 0x1) = (1111 1111 & 0000 0001) = 0000 0001 and then shifts it 6 places...giving 0100 0000
(speed & 0x7) = (190 & 0000 0111) = (1011 1110 & 0000 0111) = 0000 0110 and shifts it 3 places ...giving 0011 0000
(direction &0x7) = (191 & 0000 0111) = (1011 1111 & 0000 0111) = 0000 0111) and no bitshift = 0000 0111

Bitwise OR is " | " sign, meaning if any of the numbers being summed are 1 then the bit for that position is 1 ?
0100 0000
0011 0000
0000 0111
=0111 0111 = 119 ?

I used the Dec values i see in the trace from the factory joy read...and the factory result is 214...so i am getting closer i feel, to understanding it, definitely getting smaller headaches thinking about it

[gcebiker]

data[4]= (direction) | (speed << 3) | (maxSpeed << 6) ; gets me '255'

...but i also need to extract only the 7 bits out of that byte...(bit 6 actually being bit number 7 as number starts from n0...or n7 depending on how they numbered it...its not actually that clear but as there are only two options that helps)
'255' = 1111 1111 so i need BitWise AND "&" to clear out that extra bit ?

only trouble is that 214 = 11010110 ... and if i do what i was going to do and use BitWise AND...

I would get either 0111 1111 = 127 or 1111 1110 = 254

What i have done earlier in the code is MAP the joystick reading, so that the mapped number matched the Data read from the original Shark Remote joystick.

If infact it uses the raw values (it does say in the documentation that the Speed and direction are 10bit readings and the maxSpeed an 8 bit reading)
I will edit the code that gets a response from the base to the Joystick data packets and see what happens.

Its seeming likely that Irvings code is spot on and its my earlier code messing things up.

[gcebiker]

Oh,

data[1] = (speed >> 3) & 0x7f;
data[2] = (direction >> 3) & 0x7f;
data[3] = (speedpot >> 1) & 0x7f;

not sure of the BitShifting Irving, but now i finally understand the "& 0x7f" ...that gets me the 7MSB per the documentation....i feel so stupid now

Speed and direction are 10bit readings....so the BitShifting is to convert them to an 8bit number same as the maxSpeed pot ?

and you are shifting three places instead of 2...because ...na Ive no idea about that one.


..oh and sorry about the mass posts today, Ive hit my stims up to wake my brain up so i can think and i kind of have to 'hit the books' as it were while i can before darkness on my mind falls and i am 'out to sea' again.

[gcebiker]

Hoping Jim is feeling Generous, i have just emailed him and begged for a bit of correction.

Its my feeling that code in other parts of my sketch may be mucking things up, and as Jim has already done this successfully with a RoboBoard in Python ...he probably has a pretty good handle on where i went wrong.

After the dog came three weeks ago and me clipping her heels with my chair as i turned around i have been trying to walk around the house...and that's not been working out so well...i really need to get sensors on my chair...or get better at walking

[Burgerman]

Or a faster dog.

My german sheherd dog met my chair a few times as a puppy. He soon figured out that the wheels hurt. After that he never once got under a wheel or caster. They learn very fast. He was inch perfect on walks etc or indoors. You couldnt run over his feet if you tried. Sadly RIP now.

[gcebiker]

In reading Jim's notes, i see him declare 'unsigned char'....i first used 'int' then yesterday 'unsigned int'

I will try changing it to 'unsigned char'

This is the Python code that worked, i am not sure how to translate it to C++ for Arduino, though it shares a fair amount of similarities.
I am interested in the " & 127 " v's 0x7F .. and there is more, this little bit of code for sure is a lot more complicated than it looks.

Decoding it ...is not my end game, i just dont want to run over my puppy...

Today i purchased an RC 'Esky' Trolley... it was already remote controlled, came with a battery and looks pretty sweet...12v geared reduction motors with Golf Cart wheels, Free Wheeling hubs...Steel frame and a check plate Alloy top to put your Esky on.......for ......yes $60 AUD !

People say you cant put a $ value on some things...but mobility you can...and often its in the "shit loads of money" price bracket....but look sideways...this ESKY RC thing i bought is not marketed at the Disabled...and the prices are very affordable....

Still...i want sensors on my chair, i want senors on my blind friends chair (to be fair only partially blind), and i want flexibility with a platform that is just so capable....

I wish more of the community were contributing to this cause, its got great potential, unlock the Power Drive modules...and you unlock your feet...
I hope you can all contribute if only with your dreams of unlocked mobility.

Code: Select all

void sendmessage (unsigned char msgtype, unsigned char outbuf[32], unsigned char length)
      {
   int n, wres;
   unsigned char firstbyte, parity=0, sendbuf[32]="";
   firstbyte=msgtype+((length-1)<<4);

   sendbuf[0]=firstbyte;
   //printf("FB: %x\n", firstbyte);
   parity=firstbyte&127;
   for(n=0; n < length; n++) {
      parity+=(outbuf[n]&127);
      sendbuf[n+1]=outbuf[n];
      //printf("%x ", outbuf[n]);
      }
   parity = (255-(parity & 127));
   //parity = 0xe4;
   sendbuf[n+1]=parity;
   sendbuf[n+2]=0x0f;
   //for(n=0; n < length+3; n++)
   //   printf("%2.2x ", sendbuf[n]);
   //printf("\n");   
   wres=write(sharkfd, &sendbuf, length+3);
   //printf("Write result: %i\n", wres);
      }

[Irving]

Going about understanding the above differently....
(speedpot & 0x1) = (255 & 0x1) = (1111 1111 & 0000 0001) = 0000 0001 and then shifts it 6 places...giving 0100 0000
(speed & 0x7) = (190 & 0000 0111) = (1011 1110 & 0000 0111) = 0000 0110 and shifts it 3 places ...giving 0011 0000
(direction &0x7) = (191 & 0000 0111) = (1011 1111 & 0000 0111) = 0000 0111) and no bitshift = 0000 0111

Bitwise OR is " | " sign, meaning if any of the numbers being summed are 1 then the bit for that position is 1 ?
0100 0000
0011 0000
0000 0111
=0111 0111 = 119 ?

I used the Dec values i see in the trace from the factory joy read...and the factory result is 214...so i am getting closer i feel, to understanding it, definitely getting smaller headaches thinking about it

NO you made a fundamental error above... the decimal values in the trace are already coded. 190 and 191 are only part of the decimal value, already shifted right.

reviewing the data values from the lower trace in post 81554 above
you have data[1]-[4] = {0xbe, 0xbf, 0xff, 0xd6}. removing MSB this translates to {0x2e, 0x2f, 0x7f, 0x56} which in turn decodes to:

maxSpeed = (0x56>>6) | (0x7f << 1) = 0xff = 255
speed = ((0x56>>3) & 0x7) | (0x2f<<3) = 0x17A = 378
direction = (0x56 & 0x7) | (0x2e<<3) = 0x176 = 374

These the values you need to be inputting for speed and direction. if not, then its no surprise the outputs don't tally.

I am interested in the " & 127 " v's 0x7F .. and there is more, this little bit of code for sure is a lot more complicated than it looks.

'& 127' is the same as '& 0x7f', the former is decimal, the latter hex. Tho identical, the latter is better syntactically as we are dealing with bitwise and/or functions.

As far as I can see there is no issue with 'direction/numbering' of bits. They follow standard convention of bit 0 = LSB of byte. The only confusion is the way the logic analyser shows the data stream LSB to the left which is correct as regards time sequence (time progresses right) but is counter-intuitive to the way bytes are normally written and the reverse of the hex value of the byte in blue above it.

There is however one glaring error in the code I wrote. Remember way back the issue of framing. The first/start byte has its MSB set to 0 to denote start of packet, subsequent bytes of the message have MSB set to 1. So the following corrects that:

Code: Select all

    .
    .
    .   

    maxSpeed = 255;     // this is a fixed value ...being full speed on the Shark Remote
    data[0] = (0x60);    // Packet type identifier

    // Assign joystick and speedpot MSBs values to data[1 ] - data[3], setting MSB = 1

    data[1] = 0x80 | ((speed >> 3) & 0x7f); // Joystick speed reading (7 MSbs)
    data[2] = 0x80 | ((direction >> 3) & 0x7f); // Joystick direction reading (7 MSbs)
    data[3] = 0x80 | ((maxSpeed >> 1) & 0x7f);   // Speed pot reading (7 MSbs)

    /* encode LSBs into data[4] as follows
      bit 6: Speed pot reading LSB
      bits 5-3: Joystick speed reading (3 LSBs)
      bits 2-0: Joystick direction reading (3 LSBs)
      and set MSB = 1 */

   data[4] = 0x80 | ((maxSpeed & 0x1) << 6) | ((speed & 0x7) << 3) | (direction & 0x7);



[gcebiker]

Holey Moley Batman....plugged that code in Irving and getting responses from the base !

Chair is not moving yet but base is responding, its probally not moving as the values for the joystick are not neutral like they should be, this is an error in my mapping earlier i guess but i will go thru and try to find it.

It may aslo be that i need to do the bit math for the other data bytes, instead of straight write, i am hoping not as the other values are for stuff i dont need at this time.

[gcebiker]

Changed from 'unsigned char' for Analog variables to 'int'

Removed mapping of analog variables,
now getting correct 'neutral' values...
chair still not moving but by god i am metaphorically jumping up and down in it....

[gcebiker]

very minor tinkering with code and chair is now MOVING...well the gearbox is unlocked so its freewheeling but you get what i mean.

[gcebiker]

I am still trying to work the answer out myself...but not having any luck so far and getting a lot confused.

you have data[1]-[4] = {0xbe, 0xbf, 0xff, 0xd6}. removing MSB this translates to {0x2e, 0x2f, 0x7f, 0x56} which in turn decodes to:

maxSpeed = (0x56>>6) | (0x7f << 1) = 0xff = 255
speed = ((0x56>>3) & 0x7) | (0x2f<<3) = 0x17A = 378
direction = (0x56 & 0x7) | (0x2e<<3) = 0x176 = 374
[/code]

Minimum encoded values for joystick are 128 (0x80)or (1000 0000) , Max 255 (0xff) or (1111 1111)
>>1 to remove the MSB ? 0100 0000/ 0111 1111
then 3 << to convert to ten bit number ? 010 0000 0000/ 011 1111 1000

no thats not making sense , using this site http://www.miniwebtool.com/bitwise-calc ... erator=AND
if i take 128, shift right one place i get 64, then left three places i get 512
if i take 255, >> 1 = 127, << 3 = 1016
If i take 190 (neutral), right shift to remove msb = 95, then left 3 i get 760

I am trying to work the max and min actual values out so that i can map the joystick values.

[gcebiker]

it might also be that i need to change the VRef from 5v to 2.56v (ATmega 8 specs)
...easier to map it than rewire the emulator board tho..

Or change from a Mini Thumb joystick to something with a Logarithmic response...or do both, the hall effect of the Shark Remote would have to be a LOG response for sure one would think.

[LROBBINS]

the hall effect of the Shark Remote would have to be a LOG response for sure one would think

Doubtful. The Hall effect Apem joysticks that several of us are using are all linear response - and I don't recall seeing any log response ones in the catalogs. Controller software often has the option of applying a logorithmic (or usually more useful, exponential) curve to the linear pot output, but the pot itself is, at least in the cases I know, linear. Ciao, Lenny P.S. I did notice one thing about the Apem Hall-effect joystick that is not the case with inductive joysticks - output is velocity as well as position dependent. If you move the stick fast enough, the output overshoots then settles back to the one that corresponds to position.

[gcebiker]

Oh yeah, i guess the Shark is inductive not Hall effect.

Its not really important as i will (later tonight) just do a serial port write of the values and just watch for when it goes out of range and stops responding, remap to those values and retest till i get as close as possible.

At the movement the mini thumb stick i am using from spark fun, the max deflection at the moment is only about 45deg to get full speed.

[gcebiker]

After a mapping it out, i am thinking it is more to do with the cheap pots in the super cheap thumb joystick i am using.

So i will dig though and find some better joysticks or just start integrating the Wii Nunchuck wireless with the I2C or SPI (i forget which one it uses)

[gcebiker]

Also does not seem to like big swings in the analog readings.

[LROBBINS]

Are you alternating between reading the X & Y analog inputs? Be aware that the Atmega shares one ADC for all analog pins and that the AD conversion involves charging and discharging a capacitor. Hence, if there's little time between reading one analog pin and another there will be a lot of crosstalk between the two readings. You can reduce this by reading each channel at least twice and discarding the first reading - that gives the capacitor a chance to change charge level. Also, especially with the el-cheapo joystick, the analog signal will be pretty noisy, so its a good idea to average several readings before using the value. Here's a snippet of what I'm talking about:

Code: Select all

void READ_JOYSTICK_PINS (int * RawThrottle, int * RawSteering) {
  long sumRawThrottle = 0;
  long sumRawSteering = 0;
// average over 5 reads
// separately average Throttle and Steering and discard first read
// to avoid effect of delay in switching ADC channels
  analogRead(ThrottlePin);
  for (byte I = 0 ; I < 5 ; I++) {
    sumRawThrottle = sumRawThrottle + analogRead(ThrottlePin);
  }
  analogRead(SteeringPin);
  for (byte I = 0 ; I < 5 ; I++) {
    sumRawSteering = sumRawSteering + analogRead(SteeringPin);
  }
  *RawThrottle = sumRawThrottle/5;
  *RawThrottle = map(*RawThrottle, 0, 1023, 0, 5000); // scale to mV
  *RawSteering = sumRawSteering/5;
  *RawSteering = map(*RawSteering, 0, 1023, 0, 5000); // scale to mV
} // end of READ_JOYSTICK_PINS


Ciao,
Lenny

[gcebiker]

After doing various ADC smoothing things, double reads ,average, delays (which really muck things up due to the timing needed on the bus)

Its the pots in the thumb sticks, i can see on the Logic Analyzer the read values and its hitting max speed at only about 45deg throw.

Mapping the inputs helps but not much.

I have had the same issues with the arduino + thumb joysticks in the past.

I have had better luck with the thumb sticks in the Nintendo Wii controllers,
Ill do something like
#include wiichuck.h to work with the nunchuck.

[gcebiker]

For anyone following,

This is the working code such as it is.

Its a bit of a mess, its RAW, meaning you have to yourself...physically delay a few seconds before moving the sticks or it wont respond.

You also have to move the sicks very slowly or it starts to respond then stops.
Releasing the joystick to center and starting again will have it responding.

This emulator was built with the following
15v supply to LM7812
15v supply direct to DG419 chip - this provides the 'spike' at the start of the 'on sequence' that turns on the Shark Power Base.
LM7812 to Arduino Nano v3.0
Arduino Nano outputs to RS485 development board - this converts the single wire TX of the Arduino to dual wire RS485 signal to the Shark Power Module.

Input via Spark Fun thumb stick - analog input to Arduino A0/A1

Spark Fun RS232 to TTL converter has been posted and should be here early next week, i paid for express shipping...maybe it will be here tomorrow (fingers crossed) http://littlebirdelectronics.com.au/pro ... hifter-smd

With the RS232 to TTL i can check that my DWIZ emulator tests earlier in the week were correct...what does this mean ?
Your PC can talk to your Power chair, well you need a few more bits but Woody and some other rather clever folk are working on that bit.



Enjoy

[gcebiker]

Code has been ported to Wii Nunchuck input

I think my mapping was back to front on the analog version of the code above, its fixed for this Wii Nunchuck version.

Also due to me trying to wire it up from memory...i soldered the Nunchuck Data and Clock to the digital pins (completely forgetting about the remapping in the library)

All going to plan (and when does that ever happen...hehe), in the next few days i should be able to rewire and try and get a video up of Wii (2.4ghz wireless version but could also be wired) control via my Arduino Shark Remote Emulator.

[gcebiker]

Did the rewire...and it all started working....but only for about 10seconds, then would reset and start getting all weird.

After much head scratching, it turns out the 15v power supply i have been using is only 500mA, not enough to power the full rig (its ok till i added the Wii)

Bought a new XLR today to see about powering it from the chair but also thinking its time for a rebuild, the proto-type board is getting a bit messy.

Also working on a ESP8266 version of the code and wiring, i am hoping the FCC certified WiFi module with its built in security might be better to use than the non secure Wii, or use a RF24 module, i am not sure - now that the code has been broken i am sure others will take it up and do all sorts of stuff.

Not yet done any more with the RS232 to ttl converter, at the moment looks like the middle pin of the XLR provides 4.7v+ and the TX/RX. I want to do more reading tho...i will probally just wire it up and see what happens

[woodygb]

I've had success with this board connecting it to a built in RS232 port and also with the same board via a MAX 3232 to a TTL - USB.
download/file.php?id=4612&mode=view
I've currently got 2 more MAX 3232 boards on order ... ( I've inadvertently killed my current MAX 3232 board ) ...so that I can investigate some more .