I've created an I2C digital signal sonar module to avoid the noise problems I have been having with the current analog signal sonar module.
Why?
Seeing all the problems we are having with noisy sonar data got me thinking
Where does the noise come from? Is it:
- RF noise from the ESCs affecting the sonar module directly ?
- RF noise from the ESCs affecting the analog signal line between the sonar and APM?
- Noise on the DC power supply affecting the Sonar module?
- Something else?
The current popular solution of remote mounting the sonar has probably eliminated DC power as the primary source of our noise. In other words - if noisy DC power was the ource of the noise problem then no matter where you mount the sonar you would still have the noise. Regardless if DC noise were still an issue Maxbotics has a solution to DC noise in their FAQ.
Personally I've found that remote mounting the sonar module has only partially solved my noise problems. This is probably due to the Sonar power and signal cable passing within 10mm of one of the ESCs near where it plugs in to the APM on my arducopter.
(This photo shows how close my ESC is to the analog port on the IMU Shield)
So I wondered if I could get rid of the analog signal path and see how the sonar noise changed. This has led me to put together a I2C sonar module. This communicates digitally between the sonar and APM using the I2C port on the APM IMU shield. It also allows you to use the PWM output from the sonar which Maxbotics recommends as "the most accurate"
Hardware
All that is needed is an Arduino, an I2C cable and some software.
The GPS cable supplies power and connects data lines between the Arduino and APM IMU Shield (you need to cut one end off the cable)
APM IC2 Function Arduino Mini
PIN1 <-----> GND <-----> GND
PIN2 <-----> 5V <-----> VCC
PIN3 <-----> SDA <-----> A4
PIN4 <-----> SCL <-----> A5
Three Wires connect the Arduino to the Sonar
Arduino Function Sonar
GND <-----> GND <-----> GND
VCC <-----> 5V <-----> V+
D5 <-----> PWM <-----> PIN2
Here is what it looks like mounted on the sonar - with double sided tape
The sonar is on a standard jdrones sonar mount
Software
The Arduino then needs to be programmed as an I2C slave.
Here is my code Sonar_I2C_Sender_v005.zip
You must use an FTDI cable to program an Arduino Mini
The code continuously reads and stores the sonar distance as a PWM signal from the module.
It responds to any I2C request for data with a two byte integer representing the current sonar range in cm.
Additionally it has the ability to return noise filtered sonar data.
Note the MaxBotix experts strongly recommend a mode or median filter not averaging filter.
Currently the code can be requested to return spike filtered, median or mode filtered data.
I have modified the Arducopter code to use this I2C sonar and started testing
Here is my sonar library APM_I2CSonar.zip
If the testing all works OK I'll see if Chris or Jason want to put it in the code repository
Results
To put it simply the results so far are great!
Indoor and outdoor tethered tests show no noise and no data problems
Here is a graph showing Sonar data in red and baro in green.
first segment is with motors running second with motors off
Its too windy to fly here today (in the Aussie vernacular: It's strong enough to blow ya dog off its chain!)
Stay tuned!
Andrew
Comments
I do not agree with wasting program space:
avr-size --mcu=atmega2560 --format=avr /tmp/ArduCopter.build/ArduCopter.elf
AVR Memory Usage
----------------
Device: atmega2560
Program: 214054 bytes (81.7% Full)
(.text + .data + .bootloader)
Data: 5544 bytes (67.7% Full)
(.data + .bss + .noinit)
There is still space, but not enough for wasting in my opinion!
btw I solved my noise issue, I had still the non I2c maxbotix conntected which causes noise on the new one on I2C.
For automatically detecting the sonar what we should do is have a very small detection class. This hopefully won't take very many bytes of RAM (eating program space is ok, we have enough). Then we call this detection class first..it can ping the i2c bus to see if there's a sonar there or not, if yes, it returns a true and we dynamically create the i2c sonar class and use it. if it's not there, we dynamically create the regular sonar class that uses the analog pin. This is how we've handled the GPSs anyway.
I have also just bought the i2c version of the max sonar. I already did some changes in the Ardupilot code regarding this. My concern of detecting it automatically is, that a dynamic creation would increase the code size. Right now I am using compiler flags (ifdefs). Moreover right now I get some strange data over the I2C bus on my ardupilot, looks like my i2c data gets corrupted but I do not have a oszi to check this right now. My same test code runs perfect on a spare Arduino Uno....Do you have changed anything regarding pull ups...
John,
By the way, there is a library written to connect to the maxbotix i2c sonars. You can find this in the AP_RangeFinder directory in the Libraries folder.
AP_RangeFinder_MaxsonarI2CXL.h
AP_RangeFinder_MaxsonarI2CXL.cpp
It works but I haven't made it so the code automatically detects whether there is an i2c sonar there and use it if it is. To do that the sonar object would need to be dynamically created instead of statically defined like it is now.
Just received MaxBotix new I2C XL MB1232 sonar in the post. Will test it on both APM and MultiWii controllers.
Regardless of the interface being I2C I will still hook it up with shielded wire around the four wires (connected to ground on one end). This seemed to make the most amount of difference to noise on the conventional MaxBotix sonar. Hopefully a reduced timeslice in the code using I2C.
Yes and I forgot to mention... my serial monitor first shows some random data when the apm is booting, then because after that it the GPS process and then it says ready to fly but my green LED does not glow.
And this is the eedump data...
http://dl.dropbox.com/u/16314442/eedump.rar
Maybe yuo can have a look in my code, I just changed included the libraries of the SRF08 sonar and made some adjustments in the AP_RangeFinder library and my code.
http://dl.dropbox.com/u/16314442/arducopter%20modified.rar
Thanks.
Hindole, did you perhaps add any new parameters that get added to the EEPROM storage? If so, that might be your problem. It's very easy to break the storage system, and then it won't boot. Look in the serial monitor after booting. If the board is just stuck there, blinking the yellow TX light, and nothing else, that's probably it.
-
1
-
2
-
3
-
4
-
5
of 5 Next