Arduino controlled wheelchair

[gcebiker]

Finished the board but somethings gone wrong with the Arduino, so have ordered a few more - will be midweek before they get here.

[Irving]

you need a few capacitors. Try 100nF 5v to GND on both chips, also 100nF on DG419 VDD to VSS/GND. I suspect you're getting switching transients on +5v and/or GND into the Arduino - it won't like them much...

[gcebiker]

you need a few capacitors. Try 100nF 5v to GND on both chips, also 100nF on DG419 VDD to VSS/GND. I suspect you're getting switching transients on +5v and/or GND into the Arduino - it won't like them much...

Ya, i have them on the other board that's in the video, i should have put them in this one too. I will also add the signal diodes i have in the other board.

From the data sheet for the DG419

Proper power-supply sequencing is recommended for all CMOS devices.
Do not exceed the absolute maximum ratings because stresses beyond the listed ratings may cause permanent damage to the devices.
Always sequence V+ on first, followed by VL, V-, and logic inputs.
If power-supply sequencing is not possible, add two small, external signal diodes in series with the supply pins for over voltage protection (Figure 1).

...thankfully i don't smoke...or i would never be able to afford my semiconductor a day habit.

[gcebiker]

...bit the bullet.

Purchased a DuinoTech Arduino Nano from Jaycar for ... $30 !

Rewired Wii RX into the 5v line with the new 6.3v 1000uf cap.

Have wired in a 6.3v 1000uf Electrolytic on the 5V line as i noticed the Wii was wired into AREF...and a candidate for why the last board starting going weird.

Going to do the same on the other board, as all chips run from the same 5v i will put a big cap on the output of the VReg (and jaycar does not stock 100uf ceramics) well at least not my local one.

I will still need to add the diodes and a cap to the Bat+/- of the DG419 (on the new board)

For now i am just going to leave what is working alone, concentrate for the next few days on getting read and write code correct, start interacting with the data from the power base....i dont know how to do it yet but i am sure there will be some people that have done it before over on the Arduino forums.

[Burgerman]

I hope someone needs all this! I dont understand any of it!

[woodygb]

To the best of my knowledge.. the coms code used by Dynamic has been cracked by gcebiker and he currently has an Arduino based equiv of the Dynamic joystick pod.
This will/should ... with more Arduino coding ...eventually allow the addition of other external control options.

[gcebiker]

I hope someone needs all this! I dont understand any of it!

To enhance the usability of a powered wheelchair.

- eye tracking
- distance sensors
- automatic lighting control
- interact with sensors to eg, open a door
- PC mouse emulation with your wheelchair joystick.

Some of these things are available on higher end power chairs.
- Distance sensors are my main goal at this time to assist my wife who is Left Side Blind and to aid the control a person may have in confined spaces/indoors.

I was also trying to give my Grandmother some more mobility , she was severely vision impaired but not blind.

[Burgerman]

Fair enough. We will see how it works out!

[LROBBINS]

A small warning. The Dynamic DX bus and Dynamic Shark bus are NOT identical, indeed they are quite different in signal levels and packet structure. What gcebiker has done, however, could probably serve as a guide for someone wanting to crack the DX system. On the DX, however, the approach Woody used for the P&G, tapping into the connections from joystick pot to electronics, might be easier as the DX uses an analog joystick rather than the SPI-output joystick of the Shark. The DX has a much richer set of possible messages, so cracking it at the bus level will be rather a tougher slog than cracking the Shark. Ciao, Lenny

[gcebiker]

I only started down this road after pulling apart a Samsung NaviBot Smart Vacuum.

I think Roomba was first to be open source on their code, Samsung has now gone the same route.

Hopefully wheelchair companies will come on board and share source/protocol too.
Hacker development benefits the manufacturer in much reduced RnD costs.

Comparatively speaking, an inline module to enhance the function of a power chair is probably a small market but with 3D printers coming down in cost and a huge Arduino community.

Its not IF Its going to happen...but WHEN.

[gcebiker]

Sorry, also have to remember that

DougL of this forum had already hacked the GC2 controller serial data - viewtopic.php?f=2&t=4867&start=20#p69425

Jim did it with a RoboBoard

And I think i am reinventing the wheel, as Kelly (i found his video's long after starting on this )
...has done it all already...not sure where Kelly has gone. He has quiet a few videos, He has hacked the DX https://www.youtube.com/watch?v=VzyvzoxBWs8

If you watch this video of Kelly's https://www.youtube.com/watch?v=03OlfYWkgbw ...i think he might work for Dynamic

I think the only point of difference i have over other guys is that my emulator is a heck of a lot smaller and cheaper (if you dont add up what i have spent to get this far... )

I would just like something 'inline'
...maybe you have the chair already, maybe its second hand and you are not so good at soldering or wiring ...or its just to precious to you to even think of opening it up.

Inline has the advantage of just ...plugging it in.
No mess, no fuss.

[gcebiker]

Screen capture of data stream at its failure point.
Fwd capture data


Base stops responding to packets (so it must see them as invalid), curiously...the power base does not switch off.
Releasing the joystick, the base starts responding again and you are again able to move up to the same '227' fwd/145rev speed.

Reversing capture data base responds,


Very next packet, base stops responding.


Its not like the Arduino cant keep up, i can hold a constant speed as long as i like (as long as i dont go past where it stops working).

Looks like a failure to calculate the BitMath in Data[4] ?
Given the two different data [4] values in two consecutive packets with the same data [1-3] values.

[gcebiker]

at the moment trying
- different variable data type names...didnt seem to make a difference.
- changing the mapping, which is making a difference...making the issue worse, perhaps this a good thing...if i can fix the mapping

[gcebiker]

tried changing lots of things.

Variable names, mapping, names of speed to speedo...and direction the same.
As they were both going orange in the IDE...nothing makes a difference.

I am wondering if i need to calculate the values , before writing them, maybe its just slightly to much work at the time of writing the data to get the Data[4] spitting out the right value ?

That is what i will try next.

[gcebiker]

First i am reading up on if it makes a difference and if so why, the original Joystick uses a ATMega8 ....so it cant be a big thing i am missing surely.

Reading this atm, not sure i need to but its interesting.
https://users.ece.cmu.edu/~koopman/pubs ... ay2012.pdf

[gcebiker]

maybe its my mapping,
From the data capture
Min = 128 , Max = 255

My current mapping is

speed = map(speedPotVal, 7, 255, 0, 1024);

7 to 255 being the range of the Wii Remote when read as serial print to terminal.

Been at it all day, need to take a break, ill try more after Sailability Tomorrow.

[Irving]

it wont be a variable name issue, don't know why you have a hangup
on that. Once the code is compiled the names don't exist. And changing lots of things is just obfuscating the issue. You need to be more methodical...

Looks like a failure to calculate the BitMath in Data[4] ?
Given the two different data [4] values in two consecutive packets with the same data [1-3] values.

Hmm, I think that's a fallacy as the bitmath as you call it isn't a calculation but a splitting of the data...

so using "SR_Emulator_joy_in_shield_software_serial",

Code: Select all

0xe3, 0xc1, 0xff, 0xfa decodes to
speed     = (0xe3 & 0x7f) << 3 | (0xfa >> 3 & 0x7) = 0x318 | 0x7 = 0x31f = 799 dec.
direction = (0xc1 & 0x7f) << 3 | (0xfa      & 0x7) = 0x208 | 0x2 = 0x20a = 522 dec.
maxspeed  = (0xff & 0x7f) << 1 | (0xfa >> 6 & 0x1) = 0xfe  | 0x1 = 0xff  = 255 dec.

0x90, 0xc1, 0xff, 0xe2 decodes to
speed     = (0x90 & 0x7f) << 3 | (0xe2 >> 3 & 0x7) = 0x80  | 0x4 = 0x80  = 132 dec.
direction = (0xc1 & 0x7f) << 3 | (0xe2      & 0x7) = 0x208 | 0x2 = 0x20a = 522 dec.
maxspeed  = (0xff & 0x7f) << 1 | (0xe2 >> 6 & 0x1) = 0xfe  | 0x1 = 0xff  = 255 dec.

0x90, 0xc1, 0xff, 0xc2 decodes to
speed     = (0x90 & 0x7f) << 3 | (0xc2 >> 3 & 0x7) = 0x80  | 0x0 = 0x80  = 128 dec.
direction = (0xc1 & 0x7f) << 3 | (0xc2      & 0x7) = 0x208 | 0x2 = 0x20a = 522 dec.
maxspeed  = (0xff & 0x7f) << 1 | (0xc2 >> 6 & 0x1) = 0xfe  | 0x1 = 0xff  = 255 dec.


All are perfectly valid as per the bit slicing, so it must be something else... print out your joystick outputs and mapped values; do these decoded values correspond?

[gcebiker]

I was using data type names that only went to 255 for the 8 bit data, i was thinking that some roll over was happening.

Board i am using at the moment is the Hardware Serial, software board still needs those caps and diodes fitted and waiting on some more Arduino Nano's.
I have stopped swapping the one Arduino board between shields.

Now that the boards run on 5v i just leave it all hooked up to USB/Logic Analyzer IDE and chair and can test variations much faster.

As i am using Hardware UART , for now i cant print to the terminal window, new Arduino boards should be here in a day or two and i will be able to once i am able to use the software serial board.

But....i have overlaid both pictures so its a bit easier to see, these two data packets are less than 20ms apart...same three (Speed, Direction, MaxSpeed) values yet they have a different fourth bit (byte i am confused as to what to call it).

[gcebiker]

Could this be read, that the speed byte should have bit 7 set to (0) ....its the first data byte ?

While the data format is 8 bits, bit 7 in each byte shall be used to indicate the first byte of a packet. Bit 7 shall be CLEAR (0) for
the first byte in a packet, and SET (1) for all other bytes. If there is a slight timing difference between the sending and receiving
modules, such that the receiver is slightly faster than the sender, having bit 7 set in the majority of the data bytes will give the
greatest chance of correct reception.
This means that each transmitted byte carries 7 bits of actual information.
The packets shall consist of a start character which specifies the type of packet and its length. This shall be followed by the data
bytes, and then a single byte checksum. The length shall not include the start character or the checksum. The modules shall
start a timer upon recognition of a byte, and if 3ms elapse without receipt of a byte and without the packet being completed, the
partial packet shall be discarded.

so instead of

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

it should be ?

Code: Select all

 data[1] = (speed >> 3) & 0x7f ; // Joystick speed reading (7 MSbs)

Na that cant be right ...it would show up on the Logic Capture.

[gcebiker]

so i changed the mapping to limit it to an 8bit int and the code...same fault.

Code: Select all

 data[0] = (0x60);    // Packet type identifier

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

    data[1] = 0x80 | ((speed >> 1) & 0x7f); // Joystick speed reading (7 MSbs)
    data[2] = 0x80 | ((direction >> 1) & 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);
    // end of code for data 4

Dr Who is on soon but still trying to nut it out, should Data [4] have bracket around the whole statement...or all of the bit sliced data bytes for that matter.. ? It has to be something tiny i am missing...

[gcebiker]

Well with problems, trying to eliminate the variables is generally the way to go.

So ...i removed the mapping, direct write the Wii Values - same issue.

SO the issue may be with the bit shifting the .h file for the Wii is interacting with the bit shift of Data [4] (or what ever its messing with).

I will wire in an analog joystick and see how that goes (though that's what i started out with and where i first had this issue)
...well going in circles but having an interesting time doing so.

[gcebiker]

Passed out thinking about it...happens a lot with my brain injury....happens a lot with everybody when they think to much i reckon...

ANYWAY, woke up thinking slices Irving, not bitmath...bit slices.
So for a | 'slice' its actually a 1D representation of a 2D matrix ?

So my issue might be with the other bytes in the data packet....

If i took

data[5] = 128; // default horn off 128 , horn on value is 130
/*
bit 6: Joystick Error (indicates joystick mirror fault or some such problem when set).
bit 5: Speed pot Error (indicates out-of range error or some such problem when set).
bit 4: Local fault (such as CPU fault) (set when there is a fault)
bit 3: Battery charger inhibit state (set when inhibit is active)
bit 2: Power switch state (all bits in this byte are 1 for active, 0 for inactive).
bit 1: Horn switch state ( set when switch is pressed)
bit 0: Lock switch state ( set when switch is pressed)
*/

Using above as example, i build a 2D matrix (spaces so its easier to read)
Bit8 to 1000 0000 (1 when active)
bit7 to 0000 0000 (not used)
bit6 to 0000 0000 (no joystick error)
bit5 to 0000 0000 (no speed pot error)
bit4 to 0000 0000 (no local fault)
bit3 to 0000 0000 (no battery charger)
bit2 to 0000 0100 (power on ?)
bit1 to 0000 0000 (no horn)
bit0 to 0000 0000 (lock switch state)
data[5] = 0x80 | 0x04 ; ( 1000 0100) ,

instead of what i am writing at the moment ? 128 (10000000)
or if bit2 is a momentary switch (which it is) then i am writing it correctly ?

so data[5]= 0x80 | 0x00 ...is the same as data[5] = 128

so if i am decoding a BYTE that has been coded using | i decode it by its N position ? because unlike a regular 2D grid of X/Y
its not the labels that dictate where the information goes but the information that tells us the label ? As long as you have the right look up sheet handy.

So if i can get back to sleep...in the morning i will check the other Data Bytes in the packet...it may turn out that i have taken the values to early in the boot up sequence of the Joystick, its not till the joystick is about 3 seconds in that its operational.

...i MAY be trying to drive it in LIMP mode (now i am just guessing , way to fried to figure it out now...its taken me over an hour to write this out..)

[Irving]

Tony

Excuse my bluntness, but you have alluded to your brain injury and I'm sure that's what giving these manic responses where you're making changes/clutching at straws at random so often its hard to tell exactly what you're seeing or thinking! I feel you are overthinking this and confusing the hell out of yourself.... and anyone else reading this thread...

I prescribe a dark room and stop thinking for a while..... and breathe.... and read this slowly...

You are right, to find a problem we need to remove variables - including the biggest one; ourselves. Its very easy to get blinded to our own ability to screw up and look for problems elsewhere. That's why a slow and logical step by step approach is needed, focussing on one avenue of attack at a time.

Now, to further address your last few posts:

The start byte is data[0]. This is standard serial comms architecture. Data[0] is 0x60. This has bit 7 - the MSB - set to zero. So stop worrying about any of that, the framing looks OK.

The difference between the two data bytes in data[4] 0xE2 followed by 0xC2 is bit 5 which is the top bit of the 3 LSB of speed. For that to change means speed goes from 132 to 128. If you are putting the same speed value its extremely unlikely that this value being changed after encoding but we need to test this - I will come back to that.

should Data [4] have bracket around the whole statement...or all of the bit sliced data bytes for that matter.. ? It has to be something tiny i am missing...

no, its fine and works as expected. Set maxSpeed and speed to 0, for values of direction 0 - 1023 test boundary conditions of:

Code: Select all

value =      0 gives data[2] = 0x80, data[4] = 0x80
value =      7 gives data[2] = 0x80, data[4] = 0x87
value =      8 gives data[2] = 0x81, data[4] = 0x80
value =     15 gives data[2] = 0x81, data[4] = 0x87
value =     16 gives data[2] = 0x82, data[4] = 0x80
value =   1023 gives data[2] = 0xFF, data[4] = 0x87


A similar table for speed and MaxSpeed with the other two set to zero can be created. I'll leave that as a useful exercise for you to try.

When I write code such as this I always use a technique called test-driven development where you write tests first then put the code into a procedure and subject it to rigorous testing. It takes a minute longer but saves time as every time you change something the tests are rerun automatically to check nothing else got changed or broken. I won't say more here else this post gets too long but happy to explain further elsewhere.

On the subject of testing, when I talk about eliminating ourselves, you provided a great 'for instance'. The code you posted @ 9:04am UK post 83383 has a glaring error:

Code: Select all

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

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


instead of

Code: Select all

    // 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)


Is that because you retyped it for the post, or cut and pasted it from code you're testing with???

Also this statement

Using above as example, i build a 2D matrix (spaces so its easier to read)
Bit8 to 1000 0000 (1 when active)
bit7 to 0000 0000 (not used)

suggests you're still not fully comfortable with bit numbering (ordinal) in relation to its position (index) in a byte/word/dword etc, e.g. the 1st bit is bit 0 so in your example, the 8th bit, bit 7 IS used, its 1000 000, there is no bit 8 in a byte. Nor are you fully comfortable with the natural conversion between bit index, its binary and/or decimal value and how to add it in (bitwise or) and remove (bitwise and with complement) to the byte.

Your last point about data stream elements and bootup sequence may or may not be relevant, so follow that up until you are sure one way or the other before we do anything else.

Since you can't print anything at the moment the way I would debug this is to start with the base code and make some simple but clean changes to eliminate any variable elements. I'll come back to this in a subsequent post, but put the base code for the hardware serial version here so I can see what you are testing with right now.

[gcebiker]

SR_Wii_input_limited_mapping.zip

This is the file as of 10am Wednesday 11th May.

(4.68 KiB) Downloaded 319 times

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

The Wii has a output of 7-255,an 8bit input.
I had been mapping this to a 10bit, i was testing the difference between a straight write of the Wii input to see if my mapping was throwing things out of kilter.

My injury severely limits my interaction with the world.
I spend the greater portion of my life since the car accident sitting inside a dark, silent room.
I feel fortunate for in an environment with limited external inputs(my brain lacks the energy to process normal life 'stuff' at the speed with which life happens) i have quite a lot of capacity but its a bit dull and this is a very interesting puzzle.

I do get enthusiastic when i figure out a tiny nugget of the mystery.

Taking stimulants helps a LOT...but they then of course do overshoot and i get hyper enthusiastic...

No i am not comfortable thinking in bits and with bit stuffing, i had what i thought was an AH HA ! moment.
Yes i often forget about 0 being bit 1, so other than that small oversight...i was not to far off.

But if a switch is a boolean value and those last few data bytes are just compressed data for the switch settings.
So its probably more like a BYTE Array(true, false, false, false, false, false, false , false).
1 line of data for 7 settings instead of 7 individual Serial.write's

I will go back to the beginning,
- get data from the factory joy AFTER it finishes its boot up sequence.
- Figure out what its is saying per the manual from Dynamic
- compare / edit my code.

[gcebiker]

Figured out a way to get my raw/mapped data values...
Write them before the packet, its really convenient having all the data in the one place (instead of trying to match Arduino terminal data with the Saleae LA)



After doing this i could see my mapping was not working as planned, it was not mapping the smaller numbers of the Wii (1-255) to a 1-1023 range.
I was getting weird results with the mapped values.

So tinkered with the Wii code and the other Data code.

The code i have attached here works...well as well as it has ever worked (ie it still cuts out at mid joystick movement)
and its the code i used to get the above picture.

SR_Wii_input_limited_mapping620pm.zip

(4.51 KiB) Downloaded 322 times

- Questions on my mind
1. IS using a 1k current limiting resistor on the V+ starting pulse (limiting the current to under 30ma)by the Dynamic book...i need 40ma. Though working, is it not latching something on fully ?
2. My timing is out, Ive not yet been able to get the Arduino to respond to the Power modules data packets properly so for now the Arduino just writes blind.(well that's a statement not a question if one were to split hairs but it raises questions )

[gcebiker]

EUREKA !!!

It was the checksum...

Code: Select all

  byte sum = 0;
    for (int i = 0; i < 8; i++)
      sum += data[i] & 127;
    data[8] = (255 - (sum & 127));

I had been trying this earlier today but could not get it to work.
Which reminded me of what i saw when reading Jims work.

I dug through Jims working code, which is in Python.
Found what i thought to be the checksum and gave it a go.

Had to change it slightly but only slightly.

[gcebiker]

Demo Video of it working https://youtu.be/6GkNFPJlW4c

[Irving]

Excellent! Well done for finding that and getting it going.

Incidentally, to make everything consistent in the code and make debugging easier in future, I would rewrite it like this:

Code: Select all

  byte sum = 0;
    for (int i = 0; i < 8; i++)
      sum += data[i] & 0x7f;
    data[8] = 0x80 | (sum & 0x7f));

That is syntactically and functionally the same but expressed in hex rather than decimal and using Boolean logic rather than math. Also being inline it only works for this 8-byte packet and not a general variable length packet so needs further rewriting - in fact the whole sketch needs rewriting to 'functionise' it and remove the inline code. You alluded to that in the video.

[gcebiker]

Excellent! Well done for finding that and getting it going.

Thanks Irving.
Not so bad for my first Arduino Project....thank heavens for the large community base.

[gcebiker]

Did a little bit with the code.

This copy of the code i am using, will drive the chair with a Nintendo Wii
- Wired or wireless versions (not the BT wireless, should be 2.4ghz due to lag/range with BT)
- Holding the Z button will use the accelerometer values to move the chair.
- Releasing the Z button will use the Thumb Joystick values to move the chair.
- C button, will turn the emulator on/off... as a software on/off , Arduino stays powered up(so technically the code is still running but instructed to do nothing, revisions could include better on/off/sleep settings).

All tested and working.

SR_Wii_input_joy_and_accel.zip

(4.59 KiB) Downloaded 377 times

I think with a GPS module attached to the chair i should be able to plot some GPS way points...not that i know how to do that but i have expanded my goals.
- GPS + Long range distance sensors + short range distance sensors + drop off sensors....compass and a few solar panels...and a pirate flag...a beer esky with peristaltic pump (or strong lungs...)... i am getting silly