Please advise on best way to create a wireless foot pedal for motor speed control.

Hi

I am currently driving a motor controller with a Picaxe. (14m2). The speed of the motor is controlled by output from the PICAXE 0 - 4.8V with 10 intervals, 1 -10 being increments of speed. The speed is adjusted by pressing a speed up or down button.

I would like to create foot pedal for use with the system which will be an alternate method of controlling the speed. I would also like to make the foot pedal wireless.

I would be grateful if anyone can suggest the best method (hardward) to send this wireless signal. I intend to purchase foot pedals and strip out the electronics and install our own. These foot pedals have POTS within them and I there for will have the ability to control the speed more accurately if I can find a real time way to get the signal from the pedal to the motor control PCB. The problems here (besides my lack of experience) are that I need the PICAXE to monitor the RF signal constantly as well as deal with sending a signal to the motor controller. At the same time the PICAXE needs to keep an eye on the emergency STOP button.

Any help would be appreciated or even better perhaps someone knows of a pedal system out there that already exists to integrate into out system. (It would have to be sub £200)

Thanks for your help.

Converting a voltage from a pot to a signal that can be transmitted over an RF link is easy enough, use an 14M2 in the pedal to read the voltage, convert it to a suitable data format and send it to an RF transmitter module using the RFout command. Probably no more than a handful of lines of code. At the other end just use an RF receiver and connect it to a suitable Picaxe input pin, using the RFin command to receive the data.

However, I'd urge caution over this approach, and ask you to look very, very carefully at all the possible failure modes and the consequences of each of them. I have a fair bit of experience with electric vehicles, and had a very nasty encounter with a "drive by wire" 1200hp V12 tank engine a few years ago. This had a throttle pedal that was just a pot delivering a voltage to the digital engine control unit. I was trying to sort out a problem with some sensors on the engine whilst it was running on a dyno. Communicating with the dyno control was only by hand signals through a triple glazed window, because of the noise. I needed to shut the engine down quickly (I was in the cell with it) and assumed that the designers would have made the throttle pedal fail safe, so I just undid the throttle pedal connector. This caused the engine to go to full revs, and made the dyno operator have a fit as he tried to increase the brake to slow 1200hp down as quickly as he could.

The problem was that the designers hadn't done a proper FMECA (Failure Mode Effects and Criticality Analysis) on the design of the throttle interface. In this case, undoing the connector caused the throttle voltage to drop to 0V, and 0V happened to be the full throttle command.

Car designers do some fairly clever stuff to make drive-by-wire throttles safe, and you could do worse than copy them. They build in sensing so that if the throttle voltage is either too high (say, +5V) or too low (say, less than 0.5V) the throttle shuts the controller/engine off. The working range may be the bit in the middle, say 0.5V for no throttle and 4.5V for full throttle. This means that if the throttle wire gets shorted to either the supply or ground because of a fault the motor stops.

In your case you're introducing an additional failure mode with the wireless link, so will need to build in some fairly good and robust ways to make sure that the throttle signal to the controller always fails safe (i.e. no throttle signal) if any possible corruption or degradation of the wireless link occurs. You may well want to look at incorporating "graceful degradation" based on the state immediately preceding a detected fault, as it may be as dangerous to just shut the throttle suddenly as it would be to have an error. An example might be where there has been a period of sustained, valid, high throttle commands, followed by a glitch. Shutting the throttle off suddenly may cause unwanted safety-related effects, especially if the controller has regenerative braking. You may want to gently slow the throttle to a zero for such a condition.

All told, I'm not at all sure I'd want to use a wireless link for throttle control, I'd stick with a relatively robust wired connection and good error trapping. Consider using screened cable for the throttle voltage control signal too, as not only will that help reduce possible interference, but it also provide an element of mechanical degradation fail-safe (partially cutting the cable may cause the screen to short the signal and cause a fail-safe shut down, rather than a hazardous condition).

In

Hi Jeremy

Thanks for your very helpful answer. You are very right and we will need to build in fail safes to our design. Your suggestions are helpful, thanks.

I was wondering what options I had in terms of hardware. Would you suggest PICAXEs RFA001 or do I need to go more complex and use the ERF modules. There are chances that equipment may be used in the vicinity of other machines and so "cross talk" or interference from other units may be possible. Could I avoid this with the RFA001 modules if I use some sort of identifier in the signal?

Will it be possible to have real time monitoring of the foot pedal signal, if the PIC is also controlling the motor controller?

These are some of the questions which are puzzling me?

Thanks

@JPU

What are you making, and where will it be working?

e

Its a motor used to run various hand tools, kind of similar to dremel tools. The unit works perfectly at the moment using the power up and down buttons. I would like to now introduce a foot pedal so that the user can have more control if needed and also free up both hands during motor speed up and down.

There is no specific environment in which the tool will be used. It could be used anywhere and also it could be used where other users may be using exactly the same tool. I dont know much about wireless, but I am getting the impression from reading the forums I need to understand what PANID is?

Ive looked at the ERF modules but there is little help in the technical sheets on the Picaxe shop site, would anyone have any pointers to further help on these units.

Could I use a bluetooth module. I have seen some on Ebay, would these take care of the network identifier PANID. I have seen a unit advertised ( http://www.ebay.co.uk/itm/5x-HC-05-Bluetooth-Transceiver-Host-Slave-Master-Module-Wireless-Serial-6pin-/271491509594?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item3f3627ad5a )

Could these be used to solve my problem.

Any help appreciated.

You could use any variety of RF data link, ranging from the cheap and cheerful 433MHz ASK modules (combined with the RFin and RFout commands available on the 14M2, see here: http://www.picaxe.com/BASIC-Commands/Digital-InputOutput/rfin/ and here: http://www.picaxe.com/BASIC-Commands/Digital-InputOutput/rfout/) through to a far more complicated solution using Bluetooth modules.

All would suffer from the same safety related issues, but susceptibility to interference may be less with some options than with others.

You're looking at a very small range (maybe a couple of metres?) so interference may well not be a major issue, IF you engineer in suitable fail-safe provisions to your code. The application doesn't seem to be critical in terms that turning the controller off would seem to be always a safe action, so I'd suggest looking at using the cheaper 433MHz ASK modules, either from Rev Ed or elsewhere.

Bearing in mind that you will need to power the pedal, is there any real advantage in using an RF link over using a cable? A direct cable to the pedal would be a lot easier, cheaper, more reliable, safer and generally a better technical solution than using an RF link in my view.

Jeremy Harris said:

Bearing in mind that you will need to power the pedal, is there any real advantage in using an RF link over using a cable? A direct cable to the pedal would be a lot easier, cheaper, more reliable, safer and generally a better technical solution than using an RF link in my view.

Click to expand...

I had a similar thought, for me there would need to be some compelling reason for the Wireless approach ................

Thanks again for your help.

I agree a direct link would be the ideal solution however one of my competitors has introduced a blue tooth foot pedal, people deciding on whether to go for ours or theirs always mention this damned blue tooth pedal. Its almost like a "go faster stripe", useless but looks good!

The only justification I can give it is that if I choose to introduce a set of control buttons directly on the tool itself, I could do this with the RF rig. I have ordered a set of BT HC-05 units from Ebay. I will have a play with them when they arrive. I already have a set of ASK modules, Ill dig those up and have a go, again!. Do you have any links to setup files or examples of the ASK modules in use. Also would you suggest I use the NKM2401 Radio Encoder/Decoder chip. Is this necessary if I am to go down the ASK module route?

Thanks.

I think I've twice pointed you to the RFin and RFout commands! Take a look at them, they do the Manchester encoding so make getting an RF link working with 433MHz Tx/Rx modules extremely easy. You're already using the 14M2 which support these commands, and makes the use of the NKM2401 superfluous.

I also have many years experience with "drive by wire" controls, and can second Jeremy's advice that your overall system must be robust enough to be BOTH fault tolerant and fail safe.

Part of this robustness is to carefully choose the modulation method used. ASK is very susceptible to noise, consider FSK instead.

Jeremy Harris said:

I think I've twice pointed you to the RFin and RFout commands!

Click to expand...

Hi Jeremy

Yes, I remember we have been involved in a similar conversation in the past. I ordered the ASK modules then and got some success in making them talk. I didn't pursue the subject and the old grey matter needs a kick start now as I have decided to revisit this project.

I didnt realise that 14M2 could deal with the Manchester encoding. In the past I used a 08M2 with the NKM2401 and now I realise why!

Please could you explain PANID and how I could get this to work with the ASK modules, is there a specific command or method. So that if there are several machines in one room then only the relevant foot pedal can effect its "master" motor. Is there a way todo this or could I just write this into the software e.g so that the foot pedal has a serial number and the relevant motor only listens to that foot pedal after it has read an ID code in the serial data from the pedal? I hope this makes sense!

Thanks

Is this a commercial product, with all the very obvious safety and insurance issues ???

JPU said:

Hi Jeremy

Yes, I remember we have been involved in a similar conversation in the past. I ordered the ASK modules then and got some success in making them talk. I didn't pursue the subject and the old grey matter needs a kick start now as I have decided to revisit this project.

I didnt realise that 14M2 could deal with the Manchester encoding. In the past I used a 08M2 with the NKM2401 and now I realise why!

Please could you explain PANID and how I could get this to work with the ASK modules, is there a specific command or method. So that if there are several machines in one room then only the relevant foot pedal can effect its "master" motor. Is there a way todo this or could I just write this into the software e.g so that the foot pedal has a serial number and the relevant motor only listens to that foot pedal after it has read an ID code in the serial data from the pedal? I hope this makes sense!

Thanks

Click to expand...

Just assign every pedal and controller a unique ID in the header data transmitted. This will work over any RF link (and I agree, the FSK modules would be more robust than the ASK modules, as suggested above).

The procedure would be to transmit a unique header at the start of each transmitted packet, that identifies the particular pedal (which could be something as simple as a serial number sent as ASCII). The receiver side would then just look for its ID header and only process the data following the header if the header matched that which the receiver was expecting.

This could be really simple. Say you gave the pedal the serial number 1234 and then use the numbers 0 to 9 to set the speed. You set the receiver to parse the first four characters and match them to a stored serial number. If they match, then the code accepts the following speed setting command, if they don't match then the speed command is rejected.

I'm not suggesting for one moment that this is in anyway suitable for a safety-critical commercial product, or that it would be the best or safest approach, but it is an illustration of a way in which a unidrectional link might be made to work.

I think if you want to make an RF link robust you need to look at using more sophisticated techniques t ensure link reliability. You may want to consider using CRC checks to ensure that data packets are uncorrupted, or even using a bidirectional data link with handshaking to make the command link more robust.

A PANID is a Personal Network ID. This IDentifier is a number that identifies the network. With ASK modules it could be a qualifier., With smart RF modules it would be the Network ID. Each device will also have a Node ID.

So if one module wants to send data to another, it first sends a preamble, then the NETWORK ID, then the NODE ID, then the actual data and then finally a CRC. If everything matches only the NODE that was addressed will get the data packet, filter out the ID's and the CRC, and then send the Picaxe or other micro-controller only the actual data of interest. This is a very simplified explanation, buy gives the jist of what is happening.

Since the foot pedal will be close to the motor there is no need for long range RF modules. So you could use any legal frequency from 2.4Ghz to 433Mhz. There is no one "BEST" method, or maybe I should say that the best method is one that one works reliably and is within your budget and programming skills.

Look into the INHAOS LC-1000 Modules. These may be ideal for you application

Xbee modules have all what Geoytex describes plus they can be configured for analogue pass through.
No PICAXE required. Simply an analogue value at the sender appears (as PWM) at the receiver.
Very reliable, auto data correction and resend all built in with all the ID and node configuration on board.
A little more expensive but no development/testing required and no RF Rx/Tx code to write leaving you to concentrate on the rest of your project.

If we are out to name brand products, than why not look at the Dorji range of products being less than half the price as Xbee and as good and simpler when used with picaxe.

If you select the right Dorji module you will have the simplest interface to picaxe as there is, with a good robust system, and at a good price range.

I would suggest using transceiver modules (they talk both ways) then you can have a bi-directional system, with station id and a simple fail safe system, where one end requests data and another end sends data, if no answer to a data call, then revert to a fail safe.

It might sound slow but at 100 - 1000 times a second then i would expect it to be fast enough for a fail safe system for your requirements.

Thats my 2c worth or should that 2p worth?

Playing with ASK modules is what the name suggests "ASK_ing for trouble" great place to learn wireless and picaxe, but next to useless in a broarder project.

Hi All

Thanks all for your help and detailed explanations which I do need!

I have gone ahead and ordered a set of bluetooth HC-05 to have a play with! Good or bad what are your views??

I also have a set of ERF modules from Picaxe, however I can find limited information about them. ie, what type of modules are they? how to set them up, how to connect them? I have read the PDF RFA020.PDF but there must be more information available? I bought these a couple of years ago and gave up on them, should I have another go?

I did have a look into the DORJI modules and I looked at the Getting Started with PICAXE and Dorji DRF4431F13 Wireless Transceiver Modules PDF created by SABorn in the PICAXE forum but that looks well over my league or can SABorn point me to an exact Dorji product that you think would do the job given my limited knowledge.

Thanks again all, for your help.

I use the ERF/URF/SRF modules all the time for all manner of projects.
One great advantage is that you can even program with them. Makes it very easy for projects that may be installed in an inaccessible location.
They simply work out of the box but will accept AT commands if you want to fiddle. Be careful though, the requirements to be able to do downloads to PICAXE are very specific and easily mucked up.
Their range is also much greater (~300m with default settings) than many similar products. (30m for Xbee, 10m for Bluetooth)
Data correction is not as good as Xbee and there is no in-built re-try but they are much cheaper.
Should be plenty of help available hear as they are a Rev-Ed sold product.

As for HC-05 Blutooth, it depends....
There many different version out there. A lot depends on which variety you have.
Some are just bare-bones modules. Other come fixed to a carrier that makes interfacing easier and often 5v tollerant. (the base module is strictly 3v only)
The HC-05 is harder to control than the HC-06 because can be master or slave but there are lots of Ardweeny examples that can be ported to PICAXE.
If you are wanting to go the Bluetooth route I would suggest the HC-06 on a carrier as it's cheaper and easier but as you have HC-05, stick with it and make sure you have (and read) the datasheet for the particular version you have.
It will at least give you the ability to do debugging with any Bluetooth enabled PC via a terminal emulator but range will be limited to about 10 meters.

I did have a look into the DORJI modules and I looked at the Getting Started with PICAXE and Dorji DRF4431F13 Wireless Transceiver Modules PDF created by SABorn in the PICAXE forum but that looks well over my league or can SABorn point me to an exact Dorji product that you think would do the job given my limited knowledge.

Click to expand...

Yes Dorji has a large range and it can be confusing, but if you get the right modules they are so simple to use with picaxe and very reliable and at a good price.

I dont have time for a few days to go through what modules to use and the data for them, but i will reply if you want to go this path, for the mean time check your PMs as i will send a message because i would like to know more information that you might not want to post public.

Hi Guys

Thanks again for the help and advice, all taken on board.

Im going to have a go with the HC-05 when they arrive (sub £5.00 each). They are mounted on boards and so can take voltages 3v-5v.

I did dig out my ERF boards last night and unbelievably I got them to work. Some of you were involved in a thread I started a couple of years ago, but in the end everyone gave up and I didn't get them to work. (frustration due to my lack of knowledge took over!)

Last night I did succeed, so either I have moved on or most likely I was lucky!

I have created two very simple programs to A) help me get my head around this and b) try to understand PANIDS.


TX PROGRAM


RX PROGRAM

The output via the two ERFs shown on my terminal window in the PE is ABC134ABC135ABC136 etc etc

This appears to work OK.

Questions:

1) So, could I user the ABC as a PANID (would this be the correct way), So that PIC connected to the receiving ERF would look out for a string that contained "ABC" if it did then it would make use of the data in the string ie 134, 135, 136 etc, if not the PIC would ignore it. I am sure there is a more professional way of working the PANID but I would have to get involved with AT codes??

2) Can I assume the the ERF is taking care of any error correction, its unaltered from out the box.

3) Would this system allow several units (foot pedals and motors) with unique PANIDS to work successfully in close proximity to each other.

Thanks for looking.

Just thinking of the physical setup that you are proposing, remember that RF links are generally used for working at a distance; not normally for the distance between one's foot and hand. You can have issues with the radio modules being too close together - most instructions recommend that they should be separated for at least a couple of metres for test purposes. You can adjust the output power of the ERF modules and others and this may be necessary for the very close working distance that you are considering.

True, but it can depend on the module.
As you say, some like XBee and ERF, have the option of turning the power down.
And those two examples, I believe, will have packet / error checking set by default? (Not sure).

If you are experienced with RF, or good at Googling, you can add attenuation on the PCB design to chop the range down.
Obviously you will investigate the type most appropriate for the job


What speed will you be doing for pedal -to-speed update rate?
I only ask this as my cordless meeces are really good but I had a graphics tablet that was about 3 hours behind.
How will you ensure that the motor stops in the event of RF loss?
You can have a really good protocol but if your motor doesn't 'hear' a stop command is there any risk?
SABorn suggested a method though a watchdog method may be easier.

Thank for the tips. It has been a common concern, the loss of signal and so this is something I have given some thought to.

I guess my system will only run the motor when it sees a "go" signal from the pedal ERF, any loss of signal will mean the motor will then stop. The speed of the motor depends on a 0 - 4.8V signal and the motor spins from 100RPM - 6900RPM and so the foot pedal will be able to control the motor through this range, hopefully?

I think attenuation is beyond me, I did Google it,, maybe next time.

Ive played around with my version of PANIDS tonight and it seems to work OK. Tomorrow I will connect up a POT to PIC to an ERF module and go wireless. We will see what happens when I try to control the DAC output from the PIC on the other end of the link.

The first thing I need to do is figure out how to make the ERFs talk at 2400 (currently 9600). I don't want to adjust the clock speed of my PICAXE as I am using PWM in one part of the code to create a secondary DAC output. I think the change in the clock speed will mess with this PWM output which is currently working perfectly??

Is anyone able to answer question 2 from my last post, This is concerning me?

Thanks for your continued help.

JPU said:

The first thing I need to do is figure out how to make the ERFs talk at 2400 (currently 9600). I don't want to adjust the clock speed of my PICAXE as I am using PWM in one part of the code to create a secondary DAC output. I think the change in the clock speed will mess with this PWM output which is currently working perfectly??

Click to expand...

You may like to have a look at this thread http://www.picaxeforum.co.uk/showthread.php?26188-Configuring-ERF-with-Wizards-and-Ciseco-Explorer-Plus for a quick and simple method to configure ERF modules - see my diagrams in posts 7 and 8 based upon Hippy's circuit in post 6.

The easiest way to configure ERF modules is to use the wizard(s) in PE6.
Be careful with your wording.
A PANID is something you set within the module. Only modules with the same PANID will talk to each other.
Your "ABC" is a QUALIFIER.
It might not matter what you call these things in this thread but if you ever have a conversation with somebody else or start a new thread and ask about PANID, you will be told about PANID and not qualifiers.

To set the baud rate of your ERF, use the PE6 wizard if you are concerned about using AT commands.
At the PC end it is simply a question of running the wizard.
At the PICAXE end, the wizard will generate code for you to download that will set the baud rate. (or use the wizard with USB/serial adapter eg the download cable)

Hi

Thanks for your help and advice on this. I have managed to get my ERFs to talk, I have also managed to configure the ERFs using the wizzard, which was pretty easy once I got down to it.

I think everyone has helped me greatly here and I have now come across another problem but I will start. Although its related to this project it a new hurdle all together. Thanks again for all your help.

JPU