I am planning on making a magnetic levitation system with an arduino that checks the value of a hall's effect sensor twice per second (but I have tried even 1000 times a second though) and turns the electromagnet on or off based on the hall's effect sensor's value. I have managed to check the output voltage of the sensor and turn the electromagnet on/off too but when a magnet is placed below the electromagnet it either sticks to it (then falls) or falls immediately. Now I am starting to believe that my idea is impractical but before I abandon my project, I'd like to know: is my idea practical? Can it be done? If so do you have any advice on what could be wrong? If not what can I do to make it practical?
Making a magnetic levitation system with arduino
arduinodesignelectromagnetismmicrocontrollersensor
Related Solutions
Update from OP.
Current: Needs to be no more than 30mA.
Distance: A 4mm air gap.
Minimum data rate: Around 256Bits/second. Size: Needs to be as small as possible.(Must fit into 5x10x5mm spot)
Cost: Looking to keep it under $1.50
Is that 30 mA receive or 30 mA transmit.
Unidirectional?
Cost of $1.50 covers what? TX & RX, just one (which?),Hall cell in that price.
How many? 1 10? 100? 100,000?
MUCH more information allows us to provide a single instant answer without playing death of 1000 cuts / iterations.
The Hall cell chosen is completely unsuitable for this task.
This is because it is a sampling type which sleeps for most of the time and wakes to take a reading occasionally.
Th data sheets hows that it has a 0.1% on time and 99.9% off time.
Cycle time is 45 to 90 ms and on time is 45 to 90 uS.
So you can only signal at most at 1 bit per on time if you are careful or at about 10 bps max and probably less.
There are many Hall cells available which are not the sampling type and low enough current.
[This is Digikeys cheapest at about 58c/1.]http://www.semicon.toshiba.co.jp/docs/datasheet/en/Sensor/TCS20DPR_en_datasheet_110207.pdf)
This has 4.4 mT sensitivity worst case.
Mutiply T by 10,000 to get Gaus.
4.4 mT x 10,000 = 44 Gauss = about te same as before.
Doable at range and size specified. Implementation details depend on all answers not yet known.
More when more known ...
This question is eminently answerable but rather than giving you a single "this will work" answer, having more information will lead to a much better answer.
What range do you want to work over from the face of the Hall cell to the face of the inductor?
Is there anything in the way obstructing, spinning, cutting ...?
Is it in seawater, embedded in a block of steel or a lava field, ...?
What maximum data rate do you require?
Be as specific as possible re constraints on cost, size, and anything else you can hink of. DO NOT have us say xxx meets your needs and then say "Oh, but it must be British Racing Green and work at 2000 feet underwater" or whatever :-)
Don't let the following worry you. The answer is a piece of ferrite and some wire - but this is "what lies underneath":
IF there is a need to wind a coil and activate the sensor at a distance, then it may come down to formulae like this:
Relating to an inductor like this:
(http://www.netdenizen.com/emagnet/solenoids/thinsolenoid.htm)
From here
Or it's big brother which has finite thickness, from here
BUT probably not.
Adding a core increases the field by the permeability of the core - but, we'll come to that.
FWIW those formulae are about the nicest I've seen for a common problem that usually get's a horrendously complex answer. This is mainly geometry. Most analyses are for the field INSIDE the solenoid and few deal with it beyond the ends.
There are a few issues with your implementation.
- You need a flyback diode across that coil if you don't want an overheating transistor and massive interference. Your current schematic at least doesn't show one. I'd suggest using a schottky diode, as they are fast and have a low voltage drop.
If you are having trouble getting the magnet stable, keep in mind that it might have nothing to do with your PID gains and everything to do with the update rate of the control loop. When I did my magnetic levitatior, the bare minimum that I got to work was 200 Hz. Especially if you are using floating point math for the PID controller on an AVR, I bet you can't get stable levitation. Do everything with 8-bit and 16-bit integer math instead (known as fixed point), and you'll easily be able to reach cycle times below a millisecond.
Both the input and output of your PID controller are non-linearly related to what you want to control (you want to sense distance and control upwards force). Instead, the hall effect sensor output is proportional to the multiplicative inverse of distance squared, and the force exerted upon the magnet by the electromagnet is not only proportional to coil current, but also inversely proportional to distance squared.
PID controllers don't like this nonlinearity. You should compensate for the nonlinearities in your control system, so that the controller operates in a linear space. For the input, calculate a linear distance from the hall effect sensor output and feed that to the controller instead of the raw value. For the output, apply less current for a given requested force when the magnet is nearer, so that the attraction is independent of distance.
There's also better way for eliminating the contribution of the electromagnet from the hall effect sensor output:
Sample the hall effect sensor output synchronously with your PWM output, so that the flux is measured only when the coil current has decayed to zero at the end of each PWM period. Much simpler hardware wise, the only drawback is that you need to program at a lower level, starting the analog-to-digital conversion each cycle in a timer interrupt. Don't low pass filter the ADC input if you do this though.
Best Answer
Your design is fundamentally a feedback control loop where the position is actuated by an electromagnet and measured by a pair of Hall effect sensors. At the core, such a design is practical but there are some critical details that merit close attention:
In short, it is possible but far from trivial.