Arduino controlled wheelchair

[Ri5ux]

Hello everyone. Would just like to start by thanking everyone involved in the process of reverse engineering\hacking the shark bus on these mobility scooters. I ended up reading approximately 90% of this forum thread to attempt it myself and was successful at doing so and may have even learned a bit of information that is unknown here. Regardless, for future users attempting to interface with their scooters or re-purpose an older one, I have started organizing a sort of tutorial\walkthrough of the process on a blog I created a few days ago.

The Blog Post (Part 1): http://blog.arisux.com/2021/01/12/dynam ... r/#more-47
Summary Video (Showing the concept working): https://www.youtube.com/watch?v=8B36xSl ... nnel=Ri5ux
Update Video (Showing it interfaced with a tablet PC): https://www.youtube.com/watch?v=ECUhorI ... nnel=Ri5ux

I did also notice a post mentioning that you had to use a MAXIM branded DG419 IC, but found this to not necessarily be true. I am using the Vishay variant of the same part in mine with the initial pulse being the full battery voltage and have had no issues. I initially purchased this part before I had noticed that post, but figured I would try it anyways. After viewing the datasheet I hadn't seen any data showing it may be damaged due to the voltage or perhaps overlooked something you may have seen.

Regardless, just wanted to share my experiences with you and other hackers as well. Thanks again, it would have taken me significantly longer without the information I sourced here.

[Ri5ux]

Additionally my startup packet ended up being different. On the DK-PMA01 the startup packet I used is as follows:

Code: Select all

74 130 135 129 128 143 180 165 128 153 15

To clarify, I did not try the startup packet you guys used, so both may actually work. Looks like different joysticks have different startup packets.

[woodygb]

This thread may have given you better information,

viewtopic.php?f=2&t=6503

[gcebiker]

Additionally my startup packet ended up being different. On the DK-PMA01 the startup packet I used is as follows:

Code: Select all

74 130 135 129 128 143 180 165 128 153 15

To clarify, I did not try the startup packet you guys used, so both may actually work. Looks like different joysticks have different startup packets.

Hi, thank you for the compliments.
Regarding the start up packet - many will work as it mostly just contains manufacturing data - Please see excerpt from the manual below.

Type 04 SR power-up information
The minimum allowable length for this packet is 6 data bytes. If the SPM receives this packet with a length less than 8 data
bytes, it shall assume that the SR does not support actuator or lighting control.
Byte 0: Remote type: Types recorded elsewhere ( see )
Byte 1: Year of manufacture, minus 2000 - for example, 01 is 2001, 127 is 2127.
Byte 2: bits 3-0: Month of manufacture ( 1 is January, 12 is December).
Byte 3: Serial number bits 20-14
Byte 4: Serial number bits 13-7
Byte 5: Serial number bits 6-0
Byte 6: Software version number
Byte 7: Capabilities:
bits 6-3: currently unused
bit 2: If 0, has a virtual speed pot. If 1, has an analog speed pot. This flag is only honoured where the software version
is 2.5 or greater (whether prerelease or not)
bit 1: Supports 2 actuator control
bit 0: Supports lighting control
Notes:
The serial number format is chosen for compatibility with Dynamic Controls' standard serial number format (YYMXXXXX).
Allowance has been made such that the maximum serial number for any month can go up to 1,048,576. (they start at 10,000)
The values for the Software version number are:
0x00Versions before 1.0 release. This version has a 7-byte power-up packet, it omits the build version number.
0x01Release version 1.0. This version has a 7-byte power-up packet, it omits the build version number.
0x02Version 1.1 up to release candidate 1. No released product uses this value.
Where the upper nibble of the version number is greater than zero, the format of the version number is:
Bits 6-4: Software major version
Bit 3: "Pre-release flag": when set, this software is pre-release and is not suitable for production.
Bits 2-0: Software minor version.
For example, software version 1.1release candidate 2 will have a software version number of 0011001b or 0x19. Version 3.2
release will have a software version number of 0110010 or 0x32.
The format is chosen to enable easy reading of a hex dump such as that produced by the ^ terminal command on the Shark
Power Module (see SPM SRS section 26.14 for details).
The maximum version number that can be indicated using this scheme is 7.7.

[gcebiker]

I did also notice a post mentioning that you had to use a MAXIM branded DG419 IC, but found this to not necessarily be true. I am using the Vishay variant of the same part in mine with the initial pulse being the full battery voltage and have had no issues. I initially purchased this part before I had noticed that post, but figured I would try it anyways. After viewing the datasheet I hadn't seen any data showing it may be damaged due to the voltage or perhaps overlooked something you may have seen.

Yes, the other data sheets for other brands (that i read at the time) indicated a voltage operational rage that was not high enough to withstand a fully charged battery or different battery chemistry (LiFePo4) when they were fully charged.

I see you are using Woody's variant with the relay, this is something i am yet to implement but a very good idea of his.

I love what you are doing with the tablet interface.

A shorter version of this thread may be found here - http://greenmobility.com.au/rc-wheelchair-controller/

Cheers
Tony

[Ri5ux]

Thanks. I ended up going back through the document pertaining to the sharkbus protocol, and re-wrote the code to be able to build the startup packet and SR general packet bit by bit, quite literally. And you're right, the startup packet is pretty flexible on most values. I'll share the final result of that here when I'm done with it as well.

Also I didn't actually use relay variant, but yes it's a good idea. You may have mistaken my DCDC converter for a relay, it's quite a bit larger than the one you used.

I had also completely missed the threads you both posted, but that's how it goes haha.

The tablet is actually running a Java application, interfacing it with the Arduino via serial was pretty straight forward once you figure out the RXTX library functions. My intentions are actually not to drive the wheelchair base with a tablet though. As odd as it seems, that's just a temporary solution to be able to make sure it functions as intended. I plan on turning into a self-navigating autonomous robot of sorts. Basically navigate from point A to point B within an environment with absolutely no intervention. Going to use a combinations of sensors here including a GPS with RTK support, ultrasonic sensors for distance measurements, IR sensors to determine how fast/if the base is actually moving, and likely a camera or two. Will probably link to an RF base station for more accurate location measurements.

[gcebiker]

Seed Studio is coming out with really cheap Lidar at the moment - here is just one of them
https://www.seeedstudio.com/RPLiDAR-A1M ... -4785.html

And if you used an Arduio Pilot from the quad copter world its already got all the software and hard ware stuff setup.
I started then found the resolution on the GPS to be to low/slow with non military grade access to the GPS satellites and at the time the LIDAR's were prohibitively expensive.

Here is a link to the Ardupilot Rover, the land based version of the platform https://ardupilot.org/rover/index.html

[Ri5ux]

Seed Studio is coming out with really cheap Lidar at the moment - here is just one of them
https://www.seeedstudio.com/RPLiDAR-A1M ... -4785.html

And if you used an Arduio Pilot from the quad copter world its already got all the software and hard ware stuff setup.
I started then found the resolution on the GPS to be to low/slow with non military grade access to the GPS satellites and at the time the LIDAR's were prohibitively expensive.

Here is a link to the Ardupilot Rover, the land based version of the platform https://ardupilot.org/rover/index.html

Very cool! That lidar has an insanely better sampling rate and range than the one I was looking at earlier today. I think the one I found only had a sample rate of 1800, so 8000 is just insane. And to think this one is $20 cheaper.

I noticed most of the GPS modules available under $100 USD were pretty low resolution as well. The only one I found that had a millimeter level accuracy was $250 and required a base station to achieve that level of accuracy. Supposedly it doesn't work very well indoors either, which is understandable, so I keep trying to find other solutions.

I'll look into the Ardupilot platform as well, sounds like it's exactly what I need. Thanks for all the tips.

Additionally, I was able to quickly implement bluetooth on the controller instead of being tethered to a USB cable, so the previous tablet interface is now wireless! Quite fun to mess around with as well, haha.

[gcebiker]

This is an earlier iteration of the code, controlled via Wii Nunchuck .... the code is partially not finished works but does not have the finesse of later versions.

The best bit about this code is that you could use it for the onboard accelerometer and gyro if you needed them, just have the Nunchuckii mounted to the chair and use a hard wired version instead of the wireless one i did.

You will need the Nunchuck libraries.

Best bit about this code and the Nunchuck (i feel) is that it uses I2C , very smooth to use.

Video of the code in action.

youtu.be/6GkNFPJlW4c

[bhuja]

Hi,

I am working to replace my DK-REMD01 joystick with an Arduino nano and have read a lot of the forum trying to fix up my initial attempts.

I constructed the following circuit: https://www.wheelchairdriver.com/board/download/file.php?id=14818&mode=view

I am currently utilising the code at https://www.wheelchairdriver.com/board/viewtopic.php?f=2&t=6503&p=93844&hilit=working_deadband#p93844; "SR_Joystick_input_working_deadband.zip" but I'm not sure if this is the latest version as it does not exactly match the pinouts from the circuit above.
I have moved the Arduino wire pins to match the code. I am unsure what the onOffPin is used for, I am assuming it would be a physical switch?

I looked at the Shark Bus communications PDF and I am confused at the different power-up packet structures, how can I tell if I have a SACU in my system?
Additionally, is there any way to read the SPM responses?

I am wondering what is the best way to try and debug and find what sort of problem I am facing. I have a cheap logic analyser which I could try utilise.

Thanks for any help!

[woodygb]

I use a USB-RS485 Convertor and monitor the signal with Realterm.

https://realterm.sourceforge.io/

https://www.ebay.co.uk/itm/313630807756 ... SwSdJhDuxn

feel free to email me nala_doow AT hotmail DOT com

[gcebiker]

Hi Bhuja,

The thread with my current build might be more helpful, I was a complete Noob at the beginning and a lot of that other thread is my learning curve.
I still have the issue with mine clicking but i am also still using the same VERY cheap RC controller.
It doesn't affect the use of mine so I've not bothered eliminating the clicking.

This link is to the most recent code and may be the old code is very likely to be the reason that yours is not turning on.
https://www.wheelchairdriver.com/board/ ... 70#p117801


The 'Blue Boards' sketch in the link above is for the boards that I had made up.
You are correct, you may need to check over the pin outs to see if they match the build you are using.

Hi,

I am working to replace my DK-REMD01 joystick with an Arduino nano and have read a lot of the forum trying to fix up my initial attempts.

I constructed the following circuit: https://www.wheelchairdriver.com/board/download/file.php?id=14818&mode=view

I am currently utilising the code at https://www.wheelchairdriver.com/board/viewtopic.php?f=2&t=6503&p=93844&hilit=working_deadband#p93844; "SR_Joystick_input_working_deadband.zip" but I'm not sure if this is the latest version as it does not exactly match the pinouts from the circuit above.
I have moved the Arduino wire pins to match the code. I am unsure what the onOffPin is used for, I am assuming it would be a physical switch?

I looked at the Shark Bus communications PDF and I am confused at the different power-up packet structures, how can I tell if I have a SACU in my system?
Additionally, is there any way to read the SPM responses?

I am wondering what is the best way to try and debug and find what sort of problem I am facing. I have a cheap logic analyser which I could try utilise.

Thanks for any help!

[bhuja]

Hi gcebiker,

Thanks for the prompt response, I will try it out!

[bhuja]

Hi woodygb,

Thanks for the reply as well, will check out your links.

[bhuja]

After analyzing the joystick values with the logic analyzer and comparing it to the circuit I created on a breadboard, I can see that the packets sent do not match the coded values.

I am getting framing errors which I believe would be caused by the circuit not being wired properly.

Are there any more printed PCBs available? Since I made the circuit on a breadboard, this may contribute to the issues I am facing.

[woodygb]

The coded values at start up are different between each chair.

// byte 0 1 2 3 4 5 6 7 checksum
// OTHER 0 pulse 116 130 133 130 128 136 205 160 128 141 15
// MINE 0 pulse 116 130 140 132 128 130 165 160 128 178 15
// Micheal 0 pulse 116 129 143 133 128 143 249 167 128 199 15 .... later shark type pod

data[0] = 116;//Start Byte ..... Packets shall consist of a start byte, which includes the type of the packet and its length; followed by the data; followed by a checksum
data[1] = 130;//Byte 0: Remote type:
data[2] = 140;//Byte 1: Year of manufacture
data[3] = 132;//Byte 2: bits 3-0: Month of manufacture
data[4] = 128;//Byte 3: Serial number bits 20-14
data[5] = 130;//Byte 4: Serial number bits 13-7
data[6] = 165;//Byte 5: Serial number bits 6-0
data[7] = 160;//Byte 6: Software version number
data[8] = 128;//Byte 7: Capabilities:

[woodygb]

I would also suggest using the Nano's pin D1 = TX for the diPin and remove the SoftwareSerial from the sketch.

#include <SoftwareSerial.h>
SoftwareSerial sharkSerial (roPin, diPin, false); // 'true' sets this to invert software serial output.
void setup() {
sharkSerial.begin(38400);

Remove the above and just use the standard Nano Serial command.

void setup() {
Serial.begin(38400);

Connect the pins as below and alter the sketch to suit.

const int dePin = 7; // D7 .... to DE and RE of Max485
const int roPin = 0; // D0 .......RX of Arduino to RO of Max485 .... ( Not currently required as there is as yet NO receive coded )
const int diPin = 1; // D1 = TX of Nano

[woodygb]

You can order some boards very cheaply from China.

https://dirtypcbs.com/store/designer/de ... -v3-23-zip

[bhuja]

Is there a PCB schematic of the latest PCB design?
I could try etch a blank PCB

I would also suggest using the Nano's pin D1 = TX for the diPin and remove the SoftwareSerial from the sketch.

^Yep I have noted that change.

Thanks for your help.

[bhuja]

How would we know if the shark startup is successful? (i.e. the initial the startup packet was sent successfully)

Currently, the startup packet has framing errors for some reason, but the subsequent operating mode packets are successfully captured by my logic analyser.

[woodygb]

The checksum for the coded startup maybe incorrect ....try capturing the ACTUAL startup packet being sent and use that in it's entirety.

This is MY captured startup code.
0 pulse 116 130 140 132 128 130 165 160 128 178 15

So I have replaced the checksum with MY actual captured value of 178.

void sharkStartup () {

speed = 512;
direction = 512;

{
digitalWrite(dataSwitch, HIGH); // Flip DG419 switch, HIGH = 24v connected to emulator bus
delay(298); // Allow 24v pulse for 300ms +/- 20ms
digitalWrite(dataSwitch, LOW); // Flip DG419 switch, LOW = MAX485 connected to emulator bus
delay(10);
}

// byte 0 1 2 3 4 5 6 7 checksum
// MINE 0 pulse 116 130 140 132 128 130 165 160 128 178 15


data[0] = 116;//Start Byte ..... Packets shall consist of a start byte, which includes the type of the packet and its length; followed by the data; followed by a checksum
data[1] = 130;//Byte 0: Remote type:
data[2] = 140;//Byte 1: Year of manufacture
data[3] = 132;//Byte 2: bits 3-0: Month of manufacture
data[4] = 128;//Byte 3: Serial number bits 20-14
data[5] = 130;//Byte 4: Serial number bits 13-7
data[6] = 165;//Byte 5: Serial number bits 6-0
data[7] = 160;//Byte 6: Software version number
data[8] = 128;//Byte 7: Capabilities:

// byte sum = 0;
// for (int i = 0; i < 9; i++)
// sum += data[i] & 0x7f;
//data[9] = 0x7f - sum; //Checksum = 0x7F - (least-significant 7 bits of ( sum of all data bytes and start byte ) ).

data[9] = 178;//Checksum
data[10] = 15; // all packets end with this identifier


for (unsigned char x = 0; x < 4; x++)
{

for (unsigned char i = 0; i < 11; i++)
Serial.write(data[i]);
}

delay (12);


{
data[0] = 96;//(0x60); // Packet type identifier
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 | ((maxSpeedVal >> 1 ) & 0x7f); // SpeedVal pot reading (7 MSbs)
data[4] = 0x80 | ((maxSpeedVal & 0x1) << 6) | ((speed & 0x7) << 3) | (direction & 0x7);
data[5] = 128; // Power ON 128 , Power OFF 132
data[6] = 132; // Start up
data[7] = 128; // chair mode/ drive 128, tilt/aux output 129
// Checksum calculations - thanks to Irving,Jim and Tony
byte sum = 0;
for (int i = 0; i < 8; i++)
sum += data[i] & 0x7f;
data[8] = (255 - (sum & 127));
data[9] = 15; // all packets end with this identifier


for (unsigned char x = 0; x < 4; x++)
{
for (unsigned char i = 0; i < 10; i++)
Serial.write(data[i]);
}

On_Off_State = HIGH;
digitalWrite(led , HIGH);
delay (12);
}
}

[gcebiker]

Is there a PCB schematic of the latest PCB design?
I could try etch a blank PCB

I would also suggest using the Nano's pin D1 = TX for the diPin and remove the SoftwareSerial from the sketch.

^Yep I have noted that change.

Thanks for your help.

Its from the PCB factory.

[gcebiker]

This is the Eagle file Ver 3.0 of the board, its a Pi Hat but would be nicer if it was a stand alone board.
I've not the time to learn Eagle at the moment but if I can I'll cut the board down (the brd sketch) so that its a stand alone board (it does not need a Pi to run as it is)

NANO_SHARK_HAT_V3.0.zip

(22.95 KiB) Downloaded 58 times

The boards direct via the link in the sketch are really cheap (The same link woody linked)

Everything I've listed has been heavily tested but the only way to know for sure any issue is with a data capture of your start up packets.
Please remember and make sure you have the 300ms on pulse, without it, the chair will not power on.

If there is a delay in the packets being sent, it will power down.

If your joystick is not centered on power up, it will power on but remain stationary till the values are '0' (192)

This code mimics in a talk (but not listen) of the original joystick, as such all of the factory safety aspects are utilized.

[woodygb]

Just incase it may prove useful...here is how I modified MY PCB.

[bhuja]

If your joystick is not centered on power up, it will power on but remain stationary till the values are '0' (192)

This may be helpful as I did hardcode some values as I have no connected it to an external remote controller yet. So I probably need to let to be 0 for a period of time before changing to the hardcoded values.

The checksum for the coded startup maybe incorrect ....try capturing the ACTUAL startup packet being sent and use that in its entirety.

This is MY captured startup code.
0 pulse 116 130 140 132 128 130 165 160 128 178 15

Yep I was able to read my own code to be (in hex)
0x74, 0x82, 0x8C, 0x88, 0x80, 0xB1, 0x85, 0xA7, 0x80, 0x98,0x0F

However, when I send this packet via the Arduino it seems to be having framing errors on the initial startup packet. The next packet detailing the direction and speed is presumed to be sent fine as there are no framing errors and the packet ends with "15" which is expected.

[gcebiker]

This may be helpful as I did hard code some values as I have no connected it to an external remote controller yet. So I probably need to let to be 0 for a period of time before changing to the hard-coded values.

Yes - I hope its off the ground for testing.
If you have motors on a bench you will need them wired, including the brakes.
If you have your setup without motors, the power module will shut the system down (not power it up in the first place after detecting the fault)

Yep I was able to read my own code to be (in hex)
0x74, 0x82, 0x8C, 0x88, 0x80, 0xB1, 0x85, 0xA7, 0x80, 0x98,0x0F

However, when I send this packet via the Arduino it seems to be having framing errors on the initial startup packet. The next packet detailing the direction and speed is presumed to be sent fine as there are no framing errors and the packet ends with "15" which is expected.

Here are some screen shots of my power on data capture.

looks like your code should be working

[bhuja]

void sharkStartup () {
Serial.print("Shark Startup Called");
digitalWrite(dePin, HIGH); // Hold dePin high when transmitting.
{
digitalWrite(dataSwitch, HIGH); // Flip data switch, HIGH = 24v is connected to emulator bus
delay(298); // Allow 24v pulse for 300ms +/- 20ms
digitalWrite(dataSwitch, LOW); // Flip dats switch, LOW = data connected to emulator bus
delay(10);
}

I have found the section of code which seems to be causing the issue with the startup packet. It seems that if I comment out these lines the packet is actually sent without error, according to my logic analyzer, however, this means that the 300ms pulse would not occur and there would be no startup.

Is there some sort of shielding or method I could try to stop this from occuring?

[woodygb]

I don't use any special shielding etc...

Here is how I have my Blue board modified.

Note that I have a relay in my version , a press button ( for initiating R/C Signal calibration ) and some led's.

[bhuja]

Hi woodygb,

Would you have a closer image of the 419 schematic, can't see the yellow lines too well.
But it seems that you pull S2 of the DG419 to ground with a 270ohm resistor
Thanks

[bhuja]

When I send the startup packet with the pulse it has framing errors as shown. I was thinking it could be some sort of noise in the circuit so I increased the delay of 10 milliseconds after the pulse to 100 milliseconds but it made no difference. From the screenshot, it can be seen that some of the values are correct as the sent values were: 0x74, 0x82, 0x8C, 0x88, 0x80, 0xB1, 0x85, 0xA7, 0x80, 0x98,0x0F

Initial Packet with Framing Error only when it has the pulse.

Inital Pulse

inital_pulse.png (8.75 KiB) Viewed 3304 times

The following packets after the startup are sent fine.

Speed/Direction packets

subsequent.png (11.18 KiB) Viewed 3304 times