Decoding electric wheelchair controller
W9GFO
Posts: 4,010
I just picked up an electric wheelchair that I intend to make into a multipurpose outdoor service bot. It is was a Jazzy 1101 if you want to see what one looks like. This particular chair has the joystick controller separate from the motor driver - makes it much easier to hack. I have hooked up my scope in an effort to decode the signals and found that it sends a 6 mS burst of serial data every 10 mS. It looks like each burst is 20 120 bits long but it is hard to tell because the traces jump around quite a bit. If I am real careful - sometimes I can lock into the signal where the first half is clear but the second half of approx. 20 120 bits vary wildly. It may be that it is sending two bursts where the first ten bits or so are the same for both.
I'm thinking that there should be a simple way to read this using the Propeller chip, maybe using Viewport?
What would be the simplest way to capture this serial data and have it displayed in real time so that I can figure out what all the bits do?
Rich H
Post Edited (W9GFO) : 6/20/2009 5:18:10 AM GMT
I'm thinking that there should be a simple way to read this using the Propeller chip, maybe using Viewport?
What would be the simplest way to capture this serial data and have it displayed in real time so that I can figure out what all the bits do?
Rich H
Post Edited (W9GFO) : 6/20/2009 5:18:10 AM GMT
Comments
Is this something that can be done in Spin or would I need PASM?
Rich H
It appears that the controller (the part that actually drives the motors, not the joystick) takes the info from the joystick and ramps the motors accordingly. So it is not just a dumb driver.
Rich H
Thing of this as a wheelchair autopilot. Pretty cool, hun?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan
For the less handicapped it would be seen as a insult - because you're telling them they're totally helpless.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
If it's not Parallax then don't even bother. :-)
Propeller SRAM TV driver winner: ==NOT COMPLEATED:·1·WEEK UNTIL ENDING TIME==
That is what I had in mind, although I suppose if you really can't figure out how it works, then I suppose you could rig servos to the joystick
There really isn't an emoticon for how I feel about the inelegance of that solution.
Post Edited (grindel) : 6/24/2009 10:34:02 PM GMT
It is an advantage to decode the signals. I can easily tap into the signal by way of that box without cutting or hacking anything.
I would be hesitant to connect the prop directly to the motor driver - I assume you meant opening the driver module and bypassing it's uController, because I wouldn't know what I was doing. I have taken apart one of those that has the joystick and motor drivers all in one and I was lost as to how it worked.
I would use something like this motor driver before replacing the joystick outputs with a prop. Not that it's a bad idea...
Rich H
I don't seem to see what is wrong with a semi-automatic navigation as even a joystick for some is quite demanding for some people.· But having the freedom to wander rather than request someone push them everywhere might make them feel a bit less helpless and dependent.· It is likely that programing in a route would require someone to assist in making a dry run first.· In that case, places with lots of hazards and steep slopes might easily be excluded.
Of course, the above is merely a conversion of a wheelchair to other use. And yet, it would seem to make a perfect opportunity to explore the value of GPS assisted wheelchairs.· There are other add-ons that might further help; such as sensing slope. But I certainly cannot see the need to get within 1 foot of the same spot everytime. It just might be nice that in long mild runs that one doesn't have to keep pushing the joystick.· Nonetheless, the· joystick or other input would be there to immediately overide any GPS route with a stop, a·jog, or correction.
People think nothing of getting behind the wheel of car, including many handicapped that rely on a wheelchair and special devices to drive. And yet, the automobile has killed more people than all the wars in history.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan
Sounds like you might feel safer to provide an opto-isolated interface. I suspect the wrong serial data will be pretty much ignored and incomprehensible. But the wrong momentary voltage configuration might be a horrible error.
If there is a baud rate and it is the audio range, audio scope software on a PC and input via a sound card should be all the scope you will need. The software is free and you even have two inputs with capture. Just make sure you don't put more than 5volts peak into your computer. I have an opto-isolated set up for that as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan
Post Edited (Loopy Byteloose) : 6/26/2009 4:03:21 PM GMT
Google this --- Dynamic DX Joystick Controller schematic -- and you will get a rather larger [noparse][[/noparse]93 page PDF file] that explains the whole specification. This is suppose to be THE 1101 joystick module.
I don't think I can attach it as it is rather large, but I was able to download a copy.
In order to get the right schematic you may have to locate the DX ACU Joystick patent at the U.S. Patent office. Don't pay any money for preliminary patent info as the U.S. government is required to provide access for free. There are a lot of scam fee based search engines on the web.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan
Post Edited (Loopy Byteloose) : 6/26/2009 5:00:13 PM GMT
You'll definitely need assembly if the signal is that fast. but it shouldn't be too hard.
One option might be to just over sample the data, output the results to the serial port like in hex form or something ... then you could capture them with a PC and analyze the protocol that is being used.
Do it first without the joystick moving (there might be some noise), but you'd be able to find things like packet counters, checksums, etc.
Then move one axis, button at a time and figure out where that data is.
Once you know what kind of data is where ... it'll be easier to reverse engineer what protocol they're using to encode the data.
worse case you record the packets for a known signal (ie. full forward) and then replay them to get that result.
I agree that replacing/emulating the joystick is good approach.
If we are talking about 120bits in 6ms, that is 50microseconds/bit. At 80MHz each instruction is roughly .05 microseconds/instruction, so that is 1000(pasm) instructions per bit. Yep, I think you can do that in spin.
Please correct me if my math is not right.
Anyway, you might want to look at the PEKit manual in the counters chapter. On page 151 of http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PELabsFunBook-v1.1.pdf it has some examples of counting edges with the counters.
I hope this helps.
Thanks,
Doug
Not so much. Thought I was getting close...
There are six wires;
Red and Black for power and ground - maybe 14 ga.
White, Green, Blue and Yellow ~ 20 ga.
When running this is what the wires are doing;
White - Four bytes are being sent. The first byte is 101010. Bytes two and three are signed and the values range from -100 to 100 corresponding to joystick position. Forward and left are positive. Byte four ranges in value from 0 to 12, this is the dial on the back of the controller which sets sensitivity (not max speed) - 0 being like molasses and 12 being quite peppy.
Green is a signal that is high (10v) for 4.8 mS then transitions from low to high 16 times for the next 10 mS, low for .31mS, then repeats.
Blue is DC at 5v.
Yellow is DC, just under 7 volts. I think this is for the battery level indicator.
I made a program to replicate these signals but nothing would happen.
Then I decided to just disconnect the white wire from the joystick module since that is the one that carries the control signal, and send the signals on just that one wire while the rest of the joystick was active. That also didn't work. the Joystick module would flash all it's lights as if it knew something was wrong.
So for now, I am beat. I may come back to it later when I learn more about serial communication or I may just stick some digital pots in the joystick module.
Rich H
Did you succeed in your attempt to tame the wheel chair code?
Regards (73)
François