I have read the arducopter manual and also reviewed some of the earlier forum posts and initially moved my sonar sensor (recommended Maxbotix) 3" away from the main electronics but still see too much noise for the sonar to work in Alt Hold properly, So I did some more research and think the following may be of interest to the group. I certainly hope it allows me to keep the sonar closer to the centre of my copter rather than out on an extended arm and nearer to the motors and props.
I found a simple solution from Maxbotix, that should eliminate the effects of excessive supply noise which can impact the Sonar sensor operation. Placing a 100 Ohm resistor in series with the V+ line along with a 100uF Electrolytic capacitor (6.3V +/- 20% tolerance) to ground, you create an effective filter for the sensor. This ensures that almost any noise introduced onto the line is captured and only clean stable power is supplied to the sensor. See the photo schematic below:
This combined with perhaps a shielded cable as described here may eliminate the need to place the sensor out on a long plastic arm as I have seen mentioned in another forum post and in the Arducopter manual.
The only concern I have is extending the ground plane to the sensor board and whether this may introduce other issues. For example, normally the signal receiving end ground plane would be tied to earth, But in the arducopter this is not possible being a flying platform.
Anyone care to discuss / comment the possible side effects of a floating ground between the APM and sensor acting as an antenna of some sorts if both ends are connected? In other words would connecting the signal wire shield to the GND on both the APM and Sonar (As described in the Maxbotics article) be ok? Note the postive, negative and Analogue signal would be inside the shield.
I plan to do some experimenting over the next few days and report back my findings.
One other quick question. How many people run with sensor filters enabled on the IMU shield (3 in total)? What are the cons if you use the filters? e.g some sensitivity loss in the detector / sensor?
Replies
How do I graph the sonar signal? Is it "localsnrdb" in "Graph This"? All I see is variable stair stepped signal with motors running with "tuning" checked. I see nothing related to sonar to check when graphing a log.
Am I correct, to ground the shields on the APM side?
The sonar thing is a problem for me too... i thought i had it all sorted, see my post here http://diydrones.com/forum/topics/sonar-noise
Here is the before
and here is the after
and all was looking sweet.
but now its gone back to worse than before!
the quad has changed alot since fixing the sonar, its been changed to an octoquad with coax motors and ive changed from mystery ESC's to JDrones esc's. but the main system is unchanged. the same Ubec is powering the AMP, all the mounting is the same, with the AMP, Sonar, and all the other accessories.
My problem is even without the motors running, the readings are bad... real bad! this is raising and lowering the quad from 0.5m to 1m
I need to check for a bad connection, but i have soldered all the connections so i dont think thats the problem. vibration cant be an issue because the motors arent running, have even tried with the ESC's removed (powering the APM, RC, and sonar with ubec from a battery and leaving everything else out)
Ahh that reminds me... ive changed Recievers.. to one with telemetry! and also changed the XBee to 38400 baud.. i wonder if one of these things will have changed anything???
Changing the Xbee to 38400 was to try and fix a connection issue with the ardustation but didnt change anything, so i will change that back to 56k anyway. and i can try without the receiver and arm using a joystick thru the Xbee. this will rule out both of these or show for sure if there is a problem with one of them!
Shame im offshore again for another month or so :(
Does anyone have online links to the resistors and capacitor mentioned here.
It's probably best if I continue my sonar noise research here.
I also have a BIG problem with sonar noise on my heli that I have been trying to fix. I have been doing methodical testing to find out what the cause is. I have the RC filter, heat, and shielded cable on my sonar, but the problem remains. So I started by shutting down all electrical noise sources and testing, and found that my problem is NOT a result of electrical noise or EM radiation at all. My problem is 100% related to vibration.
My final test proves it. I simply disconnected my sonar from the frame and mounted it on some foam. I ran the heli with the tail blades installed, but the upper head section removed. I tested response by moving my hand in and out of the sonar beam. Then I touched the sonar mount to the frame again, and you can see what happens in this single image. Not only does the sonar get noisy, but the distance it measures (on average) in inaccurate.
Sonar Test 7.JPG
I have got the sonar to work better with powering (5v) directly from the eksternal bec (not from sonar output at apm). I mesured 4,6 v from sonar output with 5,2v at apm input, I dont now how this sonar power line is constructed inside apm?
I have added the 10ohm resister and 100uF cap, shielded cable and extended sonar mount - it is undeniable to me how much of a difference this made for the stability of my quad. Thank you for the great technical post -- this is the kind of stuff that I love!
The main reason I am posting this is to detail the sonar mount, as it may be of interest to others:
Hey guys,
I don't do 'copters but it looks like while some people have solved many of the problems, a few of you still need some fresh ideas, and I have gotten some mil equipment past "noise" issues in years and decades past. You've got to get your head around a couple of different ideas. Electrical noise, magnetic noise, and mechanical noise.
1. Electrical noise. Putting a filter on the sonar power supply will keep power line noise from going into the sonar. But if it isn't power line noise, it does you no good. In fact, that 100 Ohm resistor is scary. Remember that when the sonar sends a pulse, it will draw a pretty big current. If that 100uF cap can not supply all the current needed then there will be a pretty big voltage drop on the power sonar's power line. That can adversely affect readings. You probably want a pretty big cap near the sonar, but a small, low ESR cap *right* near the sonar might be a good idea too. And as little R in series as you can get away with. A scope will help you track this and decide if you need it. (Cap type & size.) Come to think of it, it may not even be noise coming in the power line, it might just be voltage drop during transmission. Someone might try the cap alone, without any series R.
2. Magnetic noise. Y'all are running big and varying current through your ESC's. This creates big and varying magnetic fields. An electrical shield will do *nothing* against a magnetic field. Since you can't get rid of the magnetic field, you need to play it's own game. (This is what twisted pair is for.) With every twist of the wires, the induced voltage is the opposite of the voltage induced in the prior turn. The smaller (physical size, not strength) and closer the magnetic field, the more turns per inch (TPI) you need in your wires to cancel. So, make sure that the power and signal wires to the sonar make 2 or 3 turns per inch (or more) from the Ardu out to the sonar. Evenly spaced. Also, do your best to run those wires perpendicular to any high current wires. Do not run the sonar wires parallel to motor power wires, for example out an arm.
3. Mechanical noise. The piezo element in the sonar will generate voltage when shaken, just as if a sonar pulse is received. You can reduce sonar vibration not just by putting foam or absorbent material around it, but also by adding mass to it. Just like a an electrical filter -- for example the proposed one for the power supply -- has both R & C (or L and C) components, you put R (foam) between the shaker and your sensor, and you add storage (mass) out with the sensor. If you can double the mass of the sonar device you will have halved the frequency which it can be shaken at. Stick a couple ounces of lead on the back of the sonar...
The data output can be filtered -- I'm sure that it is in software -- to greatly reduce spikes that are sharper than any realistic acceleration of the airframe might cause. A single spike is not a worry. A series of spikes represents a different value.
I'm not using this filter, only a shielded cable and 3 ferrites inline. This is my test for about 5 minutes holding my hexa (with props and motors running) on my room, solid ground and changing some centimeters after 2 minutes, then 1, etc...
I guess these spikes are normal, right?
It looks like there's a few I2C SRF's out there already: http://www.acroname.com/robotics/parts/R287-SRF02.html
This should help minimize the noise on the signal when it's getting transferred from the sensor to the APM... provided that the EMI isn't large enough to throw off the I2C signals.
As an after thought, one of my professors here at the college keeps mentioning the usage of differential circuitry to transmit and recieve the lines. The concept is, since the EMI is common to both transmission lines, a simple unity buffer could be used to filter out the EMI.
The unity buffer would then essentially be an analog op-amp with both inputs connected to both transmission lines. In your case, you might be able to plug the cable shielding into one input (I'm thinking the - side) and your analog line into the other (the + side).
One thing that has been bothering me is, with shielding and the power filter, is there is still noise but the spikes have variable intensity and time base i.e they appear intermittent rather than a constant effect like a ripple on the power line.
So what is the connection? One thing I have not touched on yet is the actual analogue output from the Sonar itself. Could these intermittent noise spikes be correlated with motor / ESC behaviour and the change in the electrical dynamics over time. One thing I have observed is when I see e motor pulsating breiflyin ALT hold as a result of this interference it tends to be less frequent as the the battery discahrges and the motors and ESC's heat up well into the flight. In other words in a given log I see the effects for about 60% of the flight but they are hardly noticable near say the last 5 minutes.
I started wondering if the Sonar is some how either audibly or electrically sensing the ESC driven pops and clicks in the motors which you hear under lower throttle settings. For me I do not need much throttle to hover with 12 x 4.5 props and larger motors (880Kv from jdrones with their 30A ESCs) so I believe I have more of this aberrant noise at the moment than say someone with a standard arducopter running 850Kv motors). This could explain why some users report better results in ALT hold than others. Of course noting that lowering the ALT HOld P value might help in my case.
Now if you are following my logic so far then I wondered if the newer code outputing the PWM at a higher rate is generating more pops and clicks from the ESC's and hence becuase I have not focused on the signal filtering my sonar is dirty again. Or I have some new problem in my quad and probably will go insane before finding it :-).
This brings me to my next step with is two fold. First I am going to try Andrews I2C fix using the Arduino mini as a slave unit to process the Sonar digital output. It means I wont have to sacrfice the APM processing by blocking to read the Sonar digital output. The second approach is in fact trying to see if I can remove the intermittment interference from the signal using a low pass signal filter on the AD input using the following:
By Placing a 0.1uF capacitor near/at the analog to digital pin directly to the APM ground plane and next placing a 10K ohm resistor in series with the analog voltage output from the Sonar to the 0.1uF capacitor this will create a signal LPF. The time constant for this circuit will be 1mS. This will cause a 5mS delay to allow the voltage to settle. For slower readings and slightly less noise the resistor could be increased to 100K ohms and this will cause a 50mS delay.
This is where I am worried about the impact of the ALT Hold feedback. Would a 5 or even 50mS delay mean the Arducopter will not be able to compensate for altitude fluctions in realtime due to external influence as well as before placing a settling delay of 5mS on the sonar signal? Ultimately I want to determine if having an actual signal filter on the inout side will reject the other noise I have described earlier. Has anyone tried this already? I think I would need Jason to comment on the possible feedback loop effects in the code. I am no expeRt in this field hense my hesitation and questions.
A fina, thought for the day is the way the shielding is set up. At the moment I follow the Maxbotics recommended approach and have the shield only grounded at the receiving end and my power and signal wiring to the sonar are inside the metal shield. This makes me speculate if I should just use a single wire shielded cable and run the power seperately (Outside of the sheild) and use the poer filter I already have? S many variables
In closing I just want to pass on some new infromation I received froM Scott at Maxbotixs after their engineers looked into my questions. Firstly there is a recommendation that the Power filter should be contructed using a 10Ohm resister in series with the 100uF capacitor. Someone mentioned this earlier but I had Maxbotix confirm their diagram is wrong for the XL- Sonar EZ0. Second bit of information they oassed on is the recomended Sonar (XL-Sonar eZ0) is the most sensitive device they have in their range with a wider beam foot print. So is most prone to external noise.
I may be taking the Sonar off the quad thia weekend and hooking it up to my laptop using the available range finder software this was I can move the sensor around the quad and see if I can detrmine what the real source of my persistent interference issues are. Sorry for the long post hoepfully some of my thinking aloud resonates with yiur expereinces as well debugging this very sensitive device.