+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 20 of 23

Thread: Decoding electric wheelchair controller

  1. #1

    Default Decoding electric wheelchair controller

    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
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  2. #2

    Default

    Wait for the edge (positive or negative) that starts the data burst and sample at a multiple (10x?) of the bit rate. Should be easy enough to do with the prop. 20 bits in 6 ms would be about 300uSec per bit so take a sample every 30 uSec.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  3. #3

    Default

    You can also measure the times between transitions. The minimum time would most likely be the bit time.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  4. #4

    Default

    On the scope it looks like one bit is 50 uS - oops, I meant to say 120 bits not 20.

    Is this something that can be done in Spin or would I need PASM?

    Rich H
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  5. #5

    Default

    I have the exact same problem, like I just unloaded the chair yesterday afternoon, except I don't have a scope. I was planning on taking it apart and interacting physically or electronically with the separate joystick. I don't have the brand name off hand this morning, I will have to look later. If you do figure out enough of the communications, maybe they are common between chairs, and I would be very interested.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  6. #6

    Default

    I'll be bringing the controller along to UPEW, might be able to talk someone in to helping decode it. It would be nice if they are common between chairs but I'm not counting on it. I also have an Invacare Arrow Storm to play with but that one is a bit more inconvenient to open up.

    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
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  7. #7

    Default

    You would need PASM to sample the data that fast. At 50uS per bit I would take a sample at least once every 10uS, and the prop can do that easily. The alternative is to measure and store the times between signal edges. That requires a bit more hub ram but will give a more accurate determination of the data rate.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  8. #8

    Default

    How about adding GPS to your design? I would be wonderful for many to have an electric wheelchair that learns routes to and from routine destinations. Stops could be put in at street crossings and so on. For severly handicapped, it would be very liberating; for the slightly handicapped, it would relieve the tediousness of control.

    Thing of this as a wheelchair autopilot. Pretty cool, hun?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Ain't gadetry a wonderful thing?

    aka G. Herzog [ 黃鶴 ] in Taiwan
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  9. #9

    Default

    Loopy, unless you can make that Prop driven wheelchair 100% reliable and have a 1 ft resolution on the GPS not to mention all sorts of fail safes, all you will have is a self-propelled coffin for its severely disabled user and lots of lawsuits for the designer.

    For the less handicapped it would be seen as a insult - because you're telling them they're totally helpless.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  10. #10

    Default

    waltc, are you sure you read his post? He said "I intend to make into a multipurpose outdoor service bot", which does not sound to me like it is intended to be used by the handicapped for transport. By service bot I would assume he means carrying items, cutting grass, etc.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  11. #11

    Default

    You could crack open the Joystick case and attach the prop to the joystick outputs to create the signals of the joystick therefore controlling the wheelchair.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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:1WEEK UNTIL ENDING TIME==
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  12. #12

    Default

    microcontrolled,

    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
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  13. #13

    Default

    W9GFO & grindel, I think you should be able to use the prop to decode the serial data, but if you can not do so your next best option may be to use the prop to replace everything up to the motor drivers. I have done so several times when updating the electronics on old equipment. Quite often it is the simplest and best solution.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  14. #14

    Default

    A lot of wheelchairs/power chairs have the motor drivers in the same module as the joystick. The chair that I have has the driver module in the base and the joystick on the armrest. In between these two is a control box with relays and other "stuff" for the power tilt accessory. So.. the joystick plugs into this box then the box plugs into the driver module. If you plug the joystick directly into the driver module it is smart enough to know not to enable the power tilt feature on the control panel but you can drive around just fine.

    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
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  15. #15

    Default

    I regret that my suggestion was taken so negatively. Of course, the person in the wheelchair would still have to manage the environment around them to some extent, but I am recalling watching a fellow pushing his conventional wheelchair on his daily rounds of the neighborhood. He has only one arm, so he uses a crank on a tiller rather than pushing the wheels. Some people cannot walk because of neurological conditions that cause tremor as well.

    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, ajog, 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 [ 黃鶴 ] in Taiwan
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  16. #16

    Default

    The serial could be modulated over a carrier frequency to be filtered at the other end [120 bits seems absurd] or synthesized of bursts of 1s and 0s from a higher frequency. What does you scope show when you move the joy stick to various positions? Take a look at Wikipedia for discussion on various kinds of modulation. The wheels may be controlled by a phase-shift modulation of some sort or pulse-width modulation.

    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 [ 黃鶴 ] in Taiwan

    Post Edited (Loopy Byteloose) : 6/26/2009 4:03:21 PM GMT
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  17. #17

    Default

    Actually you may have something quite complex.

    Google this --- Dynamic DX Joystick Controller schematic -- and you will get a rather larger [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 [ 黃鶴 ] in Taiwan

    Post Edited (Loopy Byteloose) : 6/26/2009 5:00:13 PM GMT
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  18. #18

    Default

    I've used the ViewPort before and it would probably be useful in hacking this signal...although maybe not necessary if you have a datasheet for the joystick.

    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.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  19. #19

    Default

    Have you been successful? I have a P&G From a Jazzy 1113 ATS so I would love to use it if I could control with serial communication. I have purchased a roboteq and I am using that until I can get the CAN communication protocol decoded.
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

  20. #20

    Default

    Hi,

    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
    Last edited by ForumTools; 10-01-2010 at 01:42 AM. Reason: Forum Migration

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts