Show Posts
Pages: [1] 2 3 ... 10
1  Using Arduino / Project Guidance / Re: Multi-node CAN bus: a progress report on: April 13, 2014, 04:32:49 am
Aux node and power distribution boards:

The usual three boards are underneath, alongside the smaller power board.  The top, larger, power board has the contactor and battery connections, and H-bridge relay pairs for seat lift and tilt.  The lower board has motor current sensors and solid-state switches for lights.  It also connects to logic-level circuits of both the Roboteq and the Aux node boards.  Connection to the boards is by crimp-and-solder ring connectors, or direct soldering for light gauge outputs.  The heavy Roboteq wires will be directly connected without other connectors, but battery motor, brake, light and actuator lines will connect with a variety of connectors suited to the currents involved.  I have a variety on hand (SB50, Anderson power-pole, XT60, EC3, 4mm SupraX) and will use different ones for different functions to try to keep me from plugging the wrong wires together.

The contactor is a heavy (130A continuous, 300A breaking current), normal (not latching) relay which, in normal use, opens whenever no Roboteq outputs are called for and the brakes have been set.  Thus, it will be switching quite frequently, but with only the ca. 100 mA quiescent current of the Roboteq across the contacts.  In an emergency, it will be opened either by the Roboteq's runaway protection algorithm or by pulling the shorting plug from the box.  In non-runaway fault conditions, such as a joystick failure, Master first tells the Roboteq to stop everything, then opens the contactor.

The DC-DC converter on Master is directly controlled by the power switch, while the DC-DC converters in the other nodes are controlled via the CAN bus - no extra wires are needed.  Power to the Roboteq's computer is controlled by the Aux node via a reed relay.  Off is really off - only microamps of parasitic load, and standby load (except for the Roboteq that doesn't have a sleep function) will be only a few mA.

Some examples of display images:
For demo purposes, I've programmed some visible marker dots into the display.  They won't be there in actual use and I didn't fuss much over programming them, so bits of the main image get erased as they move about.  Voltage is measured in Master by interrogating the Roboteq only when there is no drain, and an average of several such measures is sent to the display.  Ahr is accumulated from Roboteq battery amps, and reset to full any time the system starts up just after being charged.  This will be misleading in two situations: if the charger is unplugged for some time before the controller is turned on the gauge won't go to full and if the batteries haven't been fully charged when the charger is disconnected it will show full even though it's not.  Not completely satisfactory, but it's the best I can do as I have no way to monitor current replaced using a basic charger.  There is no warning icon for low voltage.  Instead, Master reduces maximum output by stages to a limp-home level if the voltage gets too low.  Of course, the Roboteq can be configured to shut things down completely if one persists beyond all reason.  Several levels of drive inhibit - slow, very slow and stop - can be triggered by limit switches, accelerometer or what have you.

I'll stop here.   Though I could go on for pages and pages, I think this is enough to show the state of the project.  I have no wish to become a wheelchair controller manufacturer.  Rather, I'd like to provide a starting point for those who want to have a controller that can be personalized to the individual rather than the other way around.  For me it's been an intensive learning experience.   I'd never before done programming of embedded micro-computers. Indeed, although I've written data analysis programs in a several languages, this is the first time I've used C or C++. Most of my learning of electronics dates back to vacuum tube days, though I've done a bit with semiconductors and ICs - the switch interface box in the pictures is just a miniaturized version of the one that's been on Rachi's chair for years. I'd never worked with SMD components before. I'd done some fairly complicated hand wiring, but never laid out a PCB more complex than what can be etched in a pyrex baking dish. I knew what CAN is (vaguely), but had never actually worked with any communications protocol. I've never dealt with high currents, and even now I sure wouldn't want to design the motor controller itself. Virtually all of this is new to me and there is a certain amount of satisfaction just in being able to learn so many different things and put them together.

Whether this will be anything more than a personal exercise will depend on whether anyone else uses this as a starting point. It may be just another instance of Lenny tilting at windmills, as I've done more than once in my life.

Ciao,
Lenny
2  Using Arduino / Project Guidance / Re: Multi-node CAN bus: a progress report on: April 13, 2014, 04:10:19 am
It's been quite some time since I've posted an update.  At this point I have a working prototype that awaits only purchase of a Roboteq HDC2450 and its programming to actually try it out in a semi-real-world test.  A lot of work has been done on both the hardware and software, but for now I'll post mostly photos and a (relatively) few words and leave the program and PCB files for another time.

First, an overview of the system:

There are four CANbus nodes: Master (with joystick, speed pot and some switches), Display (that also has a micro SC card and a real time clock), Aux (housed with the power distribution boards) and Roboteq emulator (which is not in a box as it will disappear in the real version).  Each node contains three boards: an Arduino Nano compatible microcomputer, a CAN controller/transceiver board and a DC-DC converter board.

The fourth box is a switch interface that provides three isolated outputs for each of five switches.  One set goes to the WC controller (DB9 cable), one to the PC (USB cable) and one, for any other use, to a set of 3.5mm jacks.  It also has a relay with latching logic that is here plugged into two of the 3.5 mm jacks.

The Master node:

There are three switches and several connectors: momentary contact pushbuttons for Power and Mode and a rocker to switch between Attendant (joystick) and Driver (switch) control.  The 4 wire CAN bus cable (CAN-hi. CAN-lo, 24V and 0V) uses USB connectors, and the switches (in my use, the switch multiplexer box) use a DB9.  There's also a 3.5mm jack for an attendant's stop switch - this is not an emergency stop that opens the Roboteq contactor, but a normal stop that toggles with a remote button in case Rachi is going where she shouldn't.  It's a rather crowded little box from a defunct Dynamic ACU.

Display node:

Another even smaller box that houses the three CAN node boards, a 1.8" TFT board with micro SD card holder modified with addition of a P-channel MOSFET so that the backlight can be controlled from the processor, and a highly accurate real time clock with backup battery.  More about what the display shows later.

To  be continued ...
3  Using Arduino / Motors, Mechanics, and Power / Re: Electric wheelchairs DIY motor and control questions on: January 25, 2014, 01:49:05 pm
-- continued --

(3) Commercial wheelchair controllers.  I know that you don't want to go this route because you want to have something open source, but I do think you should still consider it -- at least you would start out with something that you know is safe.  If it's the high retail prices that are keeping you away from these, please be aware that the wholesale prices, and even more so OEM prices, are far, far lower than retail.  For example, 18 months ago I bought a Dynamic DX 80A/channel power module from the U.S. distributor (Rosstron Inc.) and it cost $495.  (I live in Italy, but Dynamic sells only to manufacturers in Europe and will not sell to an end user.  In Italy I would have to buy from a dealer at retail; Rosstron's price is far better.)  That's already cheaper than going route (2) once the safety stuff is added.  Since your NGO is already a wheelchair manufacturer that now wants to add power chairs to the manual product you already make, I suspect that you can open an OEM account with either Dynamic or the other major WC controller manufacturer (P&G Controls) and get pricing even better than that.  Moreover, as an OEM you would also be able to get OEM-level programming access (I do too, even though I'm not a manufacturer; I got mine directly from Dynamic engineering, but Rosstron will sell the OEM dongle to individuals who are technically competent; wheelchair manufacturers will not) which will allow you to adjust virtually every parameter of the controller.  Thus, I would urge you to write to both Dynamic and P&G, outlining the specifications you need (both have simpler, cheaper models than the DX), asking them to suggest which of their products best meet your needs and telling them that you would want to purchase one unit and OEM programming access for evaluation purposes, but expect to be producing xxxx chairs per year.  If you write the technical part, and an "official" of the NGO co-signs the letter, I suspect that you will get positive responses from them.  When you have that information you will be in a position to make a truly knowledgeable decision between approaches (1), (2) and (3).

Ciao,
Lenny
4  Using Arduino / Motors, Mechanics, and Power / Re: Electric wheelchairs DIY motor and control questions on: January 25, 2014, 01:48:26 pm
Dear Hajj,

I'm glad your still working on this and pleased to see pretty clear specification of what kind of controller you need.  I think that there are three avenues you might explore, so I'll take them up one by one.  There'll be two messages because this will take more than the 9500 characters allowed in a single message.

(1) Do it yourself.  This seems to be what want to do, but I think it may not be the best way to go. You wrote:
Quote
- A PWM module is a must, because acceleration and deceleration need to be well controlled.
- The motors used require peaks of 60 amps for a couple of seconds and 20-30 amps while cruising on a slope.

As wheelchair controllers go, that is a basic level of output suitable for a chair going no more than say 7-8 km/hour on relatively smooth terrain.  Many wheelchairs do use controllers of this type, but faster chairs, chairs for heavy users, and chairs that have to handle the outdoors often have more powerful controllers - top-of-the-line commercial controllers at the moment provide up to 90-110 Amp for several seconds, adequate for 10 km/hr with a heavy user and perhaps 12-13 km/hr with a very lightweight driver.

However, even a 60 Amp PWM controller is not an easy thing to engineer, especially when the person riding that chair can't get off and walk away if something goes wrong.  Not only must it have low resistance MOSFETS and enough of them to handle the current, at a minimum it needs run-away protection, brake control (about 1Amp at 24V for each brake), overheat protection, under and over voltage protection and you CAN NOT use the chair frame as part of the battery circuit as you would in a car and you MUST make sure that there are no low-impedance connections between the electronics and the frame.  The PWM is going to be switching high currents to (and from) an inductive load.  Transient protection is not trivial for this, nor is keeping electrical noise to a reasonable level so that it doesn't drive the microcontroller crazy.  Even the circuit boards are very different from the 1 oz copper boards used for low power circuits.  You need lots of copper, good isolation and excellent heat sinking if you expect it to work for any length of time.  You already have a controller that doesn't work, you don't need to create another one, so a lot of study is going to be needed if you want to go this route.

You wrote:
Quote
- The maximum speeds and accel/decel profiles need to be adjusted for each individual, depending on their case, handicap and overall mobility requirements.
This would be handled in the microcontroller, again with a lot of attention to safety, but it is not nearly as difficult an engineering challenge as the motor controller.  Other things to consider for the algorithm are how to mix X and Y joystick outputs to get left and right motor power, an adjustable deadband for users that might have a hand tremor, different speeds in forward and reverse, turn rate, turn acceleration and deceleration, variable exponential curving so you can have fine control near stick center and increased response with large joystick deflections.  There's a good discussion of chair programming on the WheelchairDriver web site.  As noted there, the best control for those who have good hand coordination comes with turn accelerations/decelerations maxed out, but turn rates reduced way down.  If acceleration is turned down, the delay between control input and response can make the chair very difficult to control and easy to over-control.  It sets you up for what in aviation is called a "pilot induced oscillation".

Lastly, you wrote
Quote
- More thinking needs to go into controlling the wheelchairs on upward and downward slopes as this will impact the control algorithm.
  Most wheelchair controllers do this by using what's called IR compensation.  As mechanical load on a motor increases, the current flow increases as does the back EMF.  That back EMF, which is current x (motor + wiring) resistance is then used as FORWARD feedback to increase PWM on time.  Notice that this is a potentially unstable situation; the more PWM is boosted, the more current flows, when PWM increases current goes up, then PWM again increases and so on.  Hence, a fraction of the motor resistance is experimentally found that gives enough boost for decent control, but not so much that the chair is "nervous" (or in the worst case actually takes off on its own).  One might start out with 0.7 * resistance (in the 50-300 milliohm or so range) * motor current, and then adjust in small increments to get the response needed.  If you don't know the motor resistance, you have to start with a very low value, and work cautiously up from there.  Set up well, motor compensation will let a chair go at fairly constant speed as slope changes, and keep going reasonably straight if one wheel hits a bump -- at least until your controller runs into its Amp limit or the motor just can't produce the needed torque.  The only hardware needed is a good way to measure actual motor current: voltage across a shunt or (better) a Hall-effect current sensor.  Take a look at the data sheet for the Allegro ACS758 family of current sensor ICs, particularly the board layout, to get an idea of the engineering involved in working with these kinds of currents.

A less common scheme is to use sensors (gyroscope, or shaft encoder etc.) and closed loop control.  This can give very constant speed and direction, but is more complex and more expensive.

(2) Use a commercially available generic motor controller and add your own microprocessor control.  I think that this is a more feasible approach, but might still not be the best way to go.  MarkT suggested looking at http://www.robotpower.com/osmc_info/, and I agree that would be a good idea.  What you will see is that very few the control boards they sell would be workable for you.  First off, none of the controllers for "up to 28V" are suitable, even though the battery is nominally 24V unless you block regeneration - the motor acting as a generator when decelerating or going down hill.  Voltages generated during regeneration can easily go to 32V or more, and you really don't want to prevent regeneration because it is what gives a chair controlled deceleration and also adds to efficiency.  So, the OSMC store controllers that can handle 60Amps are just two: the Vyper and the OSMC.  Both have far more current capacity than you need, and they are not cheap.  Each one is just one channel, so you'd need two, hence $400 for two Vypers, or $440 + fans for two OSMC.  Even then, you would have to design and engineer the safety controls that are needed on a wheelchair controller.

Another possibility, are some Roboteq products.  http://www.roboteq.com/index.php There are a few people using these on wheelchairs because they want higher power than commercial wheelchair controllers produce, or want to move to higher voltage LiFePO4 batteries, or want open-source programming (and can't, as individuals, get full access programmers for standard WC controllers).  The Roboteq NextGen series of controllers already has many of the safety features built in, or programmable, though at least an external high-current contactor has to be added to meet the minimum safety requirements for a wheelchair.  Most people experimenting with these for wheelchairs are using the HDC2540 which is a dual channel, 150 Amp for a full minute controller that costs $645.  At least one person is experimenting with brushless motors and a Roboteq dual channel brushless controller.  For your specs, the MDC2460 (60A/channel for 1 minute) costing $395 is one to consider.  You can download their user manual, spec sheets and software to get an idea of the work involved in making safe use of these for a wheelchair.

--- continued in next post ---
5  Using Arduino / Motors, Mechanics, and Power / Re: Electric wheelchairs DIY motor and control questions on: December 17, 2013, 05:46:25 pm
I will make some specific comments and give you a couple links to things you may find interesting to read.

(1) braking.  The solenoid brakes on wheelchairs are indeed On/Off and are used ONLY as parking brakes.  Braking while driving is provided by dynamic (i.e. regenerative) braking and the parking brake coil is de-energized only after the H-bridge has gone to 0 for some time (often programmable so that it can be adjusted to avoid having the parking brake engage before the chair has stopped moving, but so that the chair doesn't drift too much if stopped on a slope).

(2) Wheelchair controllers.  On most modern powered wheelchairs the controller is not just an H-bridge, many safe-fail and fail-safe features are built in, and there's usually  at least a joystick pod and a separate motor controller.   On some of the simplest chairs, everything is in one box, and on the more complex ones there may be several additional modules, such as for lights or seating actuators.  In most cases modules are connected together over a CAN bus, with each control system manufacturer having its own CAN protocol.  They are expensive and definitely not open source.  Designing high current motor controllers and safe wheelchair controls is not trivial - a major automotive electronics company tried, had their units adopted by some WC manufacturers, but their controllers were so trouble prone that they are no longer around.

(3) Add-on units have been marketed, and I think there is one on the market even now, but they have not had a very successful history.  That is not to say that a workable add-on couldn't be designed, just that the ones produced until now have left a lot to be desired.  All of them have been slow, none have offered decent control feel, and they've suffered from other problems as well.  Friction drives, for example, often leave one stranded as soon as there's a bit of rain.

(4) If you are aiming to make a slow chair and can make do with not having proportional control, just forward, back, left and right, consider wiring a pair of SPDT relays (for each motor) as H-bridges.   Proportional control is certainly much more pleasant, but you might be surprised how well some people can drive without it -- and some people have no choice in the matter as they need to use switches of one sort or another to drive because they can't use a joystick.  You would have only one speed in each direction, and braking (by shorting the motor) would be pretty abrupt (that's why this is workable only for slow chairs), but a total of four relays driven by some transistors from four digital pins are certainly cheaper than high-current PWM bridges.

(5) You need to plan on handling substantial currents.  Even a very slow indoor-only chair will need a controller with at least 40 Amp per motor output , and outdoor capable chairs, or chairs that can handle heavy users, or ones that go any faster than 6 km/hr will need a lot more.  Typically, a 10 km/hr chair with some outdoor capability will have an 80, 90, or even 120 peak Amp/channel controller.  Also, you must plan for voltages much higher than the nominal 24V of a pair of batteries; especially during regeneration voltages can go quite a bit higher, say 36 Volts.  You might want to take a look at the Pololu motor controllers and see which ones they say are suitable for 24V systems; only a minority of the ones they sell are.

(6) http://www.wheelchairdriver.com/ and its associated forums are a good place to learn about wheelchair design and to meet people who have been building do-it-yourself chairs.  For the most part they are working on high-performance or very personalized projects, but there are people there with plenty of hands on experience with the mechanical and electrical side of things, and some people with substantial electronics and/or programming skills.  My own feeling is that if you jump in to designing something before you have a good idea of what you want the chair to be capable of, you will be very disappointed.

(7) For some time now I have been working on an Arduino-based open-source, open-hardware CANbus wheelchair controller (NOT the motor controller; for that I intend to use a hefty Roboteq unit).  You will find several pages of discussion, code for several modules as well as circuit board designs (each with several revisions as problems were dealt with) at http://forum.arduino.cc/index.php?topic=171236.0  This project is still a ways from being finished, and I'm taking things slowly and carefully because I'm very concerned about the safety issues involved (my daughter will be using the prototype).  I'm also having to learn a lot as I go along as I am a geneticist by profession (now retired) and only an amateur for everything else.  Nevertheless, it might give you an idea of how this kind of design evolves.

I applaud you for taking this on.  Powered mobility can be a very liberating thing and there is certainly need to bring affordable powered mobility to places like Lebanon.  Do be prepared though to make a major investment of your time so that you can make something that people can really use and use safely.

Ciao,
Lenny (Siena, Italy)

P.S.  If you can get at least one chair to strip down and see how it is built, that might really help.  Unfortunately, used chairs are only going to be available in places where a fair number of people have power chairs, which is clearly not the case where you are.  It's also not the case here in Italy where powered wheelchairs are rather few; in Siena with a population of about 40,000 I think there are no more than 6 people using powered chairs.  They are also heavy to ship.  BUT, if you can find some reasonable way to get a chair or two from the U.S. or U.K., you can probably find some (even on e-bay) at reasonable prices so that you can see how they're put together (often not really very well) and how they are controlled.
6  Community / Website and Forum / Re: website stuck in redirect loops. on: December 13, 2013, 01:28:56 pm
Firefox today also can not reach any page at www.arduino.cc; it gives a re-direct error, although it opens forum.arduino.cc just fine and tabs such as Unread Posts work just fine. 
7  Using Arduino / Project Guidance / Re: Nano SPI pins on: December 08, 2013, 06:57:07 am
Hardware SPI is exactly the same on the Nano as on the Uno and the SPI library is now included with the Arduino package despite the (historically accurate, but no longer true) note.  You do have to, of course, #include the library.
Ciao,
Lenny
8  Using Arduino / Programming Questions / Re: Memory and SD library problem on: November 26, 2013, 02:18:51 pm
My experience using the SdFat library rather than SD is that I freed about 5k of PROGMEM and 500 bytes of SRAM with SdFat.   The SD library is a resource hog.  YMMV. 

Ciao,
Lenny
9  Using Arduino / Microcontrollers / Using Nick Gammon's bootloader programmer to re-burn bootloader to a Nano on: November 13, 2013, 01:39:33 pm
A couple months ago, after a power failure during an upload, one of my HobbyKing Nano 3 compatibles stopped accepting uploads.  Having a little spare time today, I used Nick Gammon's sketch to first check the failed Nano (all addresses were 0xFF) and then to upload a fresh bootloader.  All went well except for one minor glitch.  The resurrected Nano accepts programs, but only if I tell the IDE that it is a UNO!  (I get an out of sync error if I try to use it as a Nano.)  I will have to tag it or I'm sure I'll have forgotten this if I ever try to actually use it.

I haven't checked this, but I wonder whether this also means I've also lost access to the two "extra" analog input pins on this board.

Aside from the different USB to serial hardware, anyone know what is different about the UNO and NANO bootloaders?

Ciao,
Lenny
10  Using Arduino / Microcontrollers / Re: Two of my Arduino Uno v3 analog inputs acting wird on: November 01, 2013, 03:54:17 am
The analog pins are multiplexed to a single A-D converter.  Because doing the conversion involves charging a capacitor, reading different pins one right after another can give misleading values.  One partial workaround is to discard the first reading of a pin.  Better yet, discard the first reading, then read the pin several times and average those values do dilute any carryover.  (BTW, as you didn't post your code, but just the output, it's rather hard to know exactly what you did.)
Ciao,
Lenny
11  Using Arduino / Project Guidance / Re: Multi-node CAN bus: a progress report on: October 23, 2013, 02:30:31 am
Hi Bernt,

Quote
Then I went quickly over the schematics, and I learned from it. Thank you for sharing.
One question: where do you source the annealed copper bus bar, can you give any references ? (I failed lately to find such material with the distributors.)

Ha, ha.  A piece of plumbing tubing, cut, flattened and annealed.  Copper is easy to anneal, heat to cherry red and let cool (cooling speed is unimportant).  I usually dunk the hot metal into cold water because it helps clean it.  Flatten some more, clean up with a rubber abrasive bit in a Dremel, flux and tin.  You can buy (hard temper) busbar material from McMaster-Carr, but they no longer ship outside the U.S., it is expensive and, not being annealed, very hard to bend.  It's slightly higher purity, but I'm using far more cross section than needed.  Copper work hardens very quickly, so if you have to work it you may also have to re-anneal it.

I'll take a look at GITHUB, but if there's a significant learning curve to using it I probably won't.  To me, the progress feels very slow.

Ciao,
Lenny
12  Using Arduino / Project Guidance / Re: Multi-node CAN bus: a progress report on: October 22, 2013, 11:52:29 am
CONTINUED

b]Power control:[/b] I found that my idea of simply turning non-Master node DC-DC converters on and off based on the value of (CAN-hi+CAN-lo)/2 was not adequate.  With just two nodes (and even with 3 - mostly), with Master off and the non-Master transceiver in standby (CAN-hi+CAN-lo)/2 drops low enough to turn off the non-Master converter.  With four nodes (one off, and 3 in standby) it does not.  I have therefore added an NPN low-side switch to the control line in the non-Master converter that gets turned on by a digital pin of the Nano.  As before, (CAN-hi+CAN-lo)/2 turns the converter on, but when the non-Master gets the CAN message to shut down, the converter's control pin gets pulled low.  (A small capacitor is also needed so that the shutdown is not so brief that the Arduino just goes into a brown-out reset.)  I also wired up an old 18.5V computer brick so that I didn't have to go down to my "dirty-work" shop's 24V batteries to test this (which I hadn't been doing routinely enough).  Now, the DC-DC converter's are always the primary power source and I should, hopefully, spot screw ups when they happen rather than a few weeks later.

Revision organization: To keep track of what I'd been doing, I sequentially numbered each node's sketches as they got modified, and archived the older ones.  Then I discovered a bug, I don't even recall now what it was, and had to backtrack through that archive to find what change had caused it.  BUT, I had no decent way to know which revision number of NodeX was really concurrent with NodeY, and mismatched programs might not work for reasons having nothing to do with the bug.  I've therefore changed how I'm tracking things, but really don't know if there isn't a yet better way to do things - suggestions would be welcome.  What I'm doing now is that each day that I work on software I copy all elements of the previous version into a fresh, dated folder.  If I then discover a problem and have to figure out when it got introduced, I will at least have coherent sets of nodes.

High current circuitry: This mostly has naught to do with Arduino, except that some functions will be handled by the AuxNode as the Roboteq doesn't have quite enough pins.  Nevertheless, I've included schematic and PCB layouts in hopes that you can spot weaknesses.  A couple notes are in order: (1) safe use of the Roboteq requires addition of a high-current contactor, fuse, pre-charge resistor etc.; I'll also have a plug connected to a wrist lanyard as an emergency stop device, (2) in order to use IR motor compensation at low outputs accurate motor currents are needed, but the Roboteq estimates motor current as (battery current*PWM on fraction) so gets less and less accurate as current goes down.  I've therefore included Allegro Hall-effect current sensors that have some rather tight PCB requirements.  (3) I've also included smaller current sensors for the brake coils, but don't plan on mounting them in hopes that the Roboteq battery current parameter will have enough resolution to detect coil faults.  (4) To control seat lift and tilt actuators I've used SPDT automotive relays in H-bridge, self-braking configuration.  Both physical limit switches and current drain monitoring will be used to detect end-of-travel and alter chair speed for less-stable CG conditions.  If more than two actuators are wanted, another relay board would have to be added.  (5) the contactor and actuator relays have snubber resistors rather than diodes to avoid compromising contact break time, (the Roboteq digital outputs are 1 Amp continuous low-side MOSFETS) (6) For LED lights, I've chosen STM Pentawatt-V power switches that provide control of moderate currents without needing added components.  (7) The circuits are sprinkled with transient voltage suppressors - I hope enough of them and with the right specs.

To do: An RTC has to be added for time-stamping the log file.  I have a  DS3231 board on order, but fear that it's been caught in the Hong Kong and China post decision to X-ray everything and send anything that might contain a Li cell back to the sender.  We'll see.
   I have to get an accelerometer to add to the Aux node and port the code I now have running in a free-standing Uno on Rachi's chair to provide shock/stability sensing.  This, along with the actuator limit switches/current monitoring will trigger the Stop, VerySlow, Slow and full-speed states of SpeedSlow already included in the sketches.
   I have to place orders for boards and components.  I've not found a single supplier who stocks everything, but between Mouser, Digikey, RS, Farnell (possibly) and e-bay I think I have a BOM.  e.g. RS.it (but not RS.uk) has a good price for the contactor, IF I'd buy a minimum of 25 of them, so I paid a higher unit price to Mouser to buy one rather than 25, but Mouser doesn't stock decent joysticks.
   One thing still not decided is connectors.  For the breadboard, I've just used the usual male & female headers, but on the deployed version I intend to connect the small stacked boards with male headers only, soldered to the boards.  For the few off-board connections (joystick, CAN, 24V) I'll use some robust Molex variant (and add a dab of Goop to each; from experience a useful backup).  Higher current connections will be ring terminals, Anderson SB50, power-pole and XT connectors as appropriate.

Schematics, pcb and program files are in the two zipped attachments.

Ciao,
Lenny
13  Using Arduino / Project Guidance / Re: Multi-node CAN bus: a progress report on: October 22, 2013, 11:52:01 am
CAN update 2013_10_20

I've not posted for quite a while, and though I've made some progress, it's not been as fast as I'd like.  I'll try to not be too verbose here (but will probably fail at that) - change details are summarized at the ends of the sketches.

DisplayNode: I finally put together a prototype display node using a cheap 1.8" TFT board (Sainsmart) after getting tired of waiting for Adafruit to re-stock a 2.2" higher-resolution board.  In the end, the 1.8" is actually quite nice in this application, and I haven't even had any problems with full-speed SPI despite the resistor voltage shifting for the SD card used on this board.  I will probably change to another supplier's board, however, as this one doesn't give me access to the backlight.  The screen is slow - about 200msec to retrieve and paint a full-screen bitmap, and, as doubling SPI speed (from half to full speed for both the screen and SD card) and tripling the buffer for bmp data (from 20 to 60 pixels) reduces paint time by less than 2%, it is almost surely the controller chip that's the hangup.  Still, it's satisfactory; resolution is quite adequate for what I want to show, and the image is good enough for all but bright sun.

CAN handling for this node differs in one major respect from that in the others.  Use of the display is entirely dispensable, indeed for a simpler chair than my daughter's one might not want one at all, and a display failure is in no case driving-critical.  The only side-effect would be loss of fault logging so a variant system might have an SD card and no display.  Thus, messages are sent to this node without any request for confirmation.  To be sure that the bus continues working even if the display were simply not there, filters in one of the other nodes also accepts and sends an ack for these non-essential messages.  (As current Roboteq motor controller software doesn't provide any real message filtering, just lets you ignore uninteresting messages loaded in it's 12 FIFO message registers, it will ack all messages anyway.)

I started out with Adafruit's libraries and examples, but had a lot of trouble not exceeding both flash and ram limits.  I then switched from using the SD library (that comes with the Arduino download) to using SdFat.  This freed up >6000 bytes of progmen and >700 bytes of RAM, as well as allowing the SD card to go to low-power mode when idle.  The SD library not only has some flaws, it is also a resource hog.

MasterNode and Joystick/SpeedPot calibration: I stripped the electronics out of an old Dynamic DX Attendant Control Unit that Continental Airlines had destroyed a few years ago to see how things behave with a real inductive joystick and decent speed pot instead of the trimmers on the breadboard.  Works great with much less noise, but I did find out why that unit gave a fault after the chair was bounced over on the tarmac.  The Vcc=5V joystick has two outputs per channel: 1 to 4V signal and a 4V to 1V mirror.  The mirror outputs were AFU, and the direct X & Y outputs, though not as far off as the mirrors, didn't match each other and were offset (differently) from 2.5V at mechanical zero.  Even a new joystick would surely have some deviation from ideal and will drift with age.  Moreover, there are many models of inductive and Hall-effect joysticks out there, with each retail supplier perhaps having just 1 or 2 available.  I therefore wrote a little calibration sketch to store neutral, minimum and maximum values in EEPROM and re-wrote Master to use these rather than hard-coded numbers.  While I was at it, I made that sketch also store min and max speedpot values as well.  (The spans for these signals are deliberately less than 0 to Vcc so that a broken wire can be detected as an out-of-range 0 or Vcc.)  While I was at it, I did some clean-up of the deadband, scaling and curving code and provided for the fact that one joystick model might be Left=low, Right= high and another might be Left=high and Right=low etc.

TO BE CONTINUED
14  Using Arduino / Installation & Troubleshooting / Re: How to recover Arduino Nano from death on: October 22, 2013, 10:59:06 am
A 5V to gnd short on the Nano often fries a Schottkey diode (I think that it's D1) that connects +5V and Vusb.  If that's all that's failed, you can replace that SMD diode with another one or with a carefully connected thru-hole diode.
Ciao,
Lenny
15  Using Arduino / General Electronics / Re: Arduino power consumption on: October 20, 2013, 09:57:06 am
One place to start is with the data sheets for each of the major components, then add "high" current items like LEDs, linear regulators etc.
Pages: [1] 2 3 ... 10