Attemp to integrate sonar (ultrasonic sensor)
Re: Attemp to integrate sonar (ultrasonic sensor)
but before all of this, i think we should choose a goal for each point (at this time and as said above, there many feature impl possibility):
for now, we have all sensor already impl in stable branch + echo/trigger generics with olaf code snippet (hcsr04, dyp me007, etc...), so we can work direcly on the feature with most of hardawre and sonarAlt is in cm in each impl
---- hardware impl
->is there other hardware to impl ? like serial sonar ? laser/lidar ?
->is error should be handled by "driver" or later by feature implementation ? (sonar are very sensitive and error generative with EMF, too close to motor, different ultrasonic absorption of ground, -> "despite of many effort, reading/shits will append, necesserly and obviously"
-> other idea ?
--- feature
there is some different request as this time so:
-> what kind of feature should we propose: keep distance to ground (relative alt hold), more alt precision (fusion with baro readings), mix of two with different marker for diferent behaviour ?
-> low alt warning (led/buzzer), trigger (airbag, landing gear) ?
-> more "general collision avoidance" like horizontal/wall detecting ?
-> other idea ?
--- implementation
it depends of feature but there is a leat a pid loop and acc_z usage
-> do we use the baro alt hold as working base (with acc_z impl) which mean sharing same pid loop ?
-> do we use tilt correction ? (since arducopter use it, i think it's not a bad idea and worth the try)
-> do we handled readings error here with lpf/hpf ? (which if shared with baro would be tricky since sonar is way less sloppy ?)
etc.... so before throwing many version and implemention, i think we should answer all theses questions and write code/impl after
for now, we have all sensor already impl in stable branch + echo/trigger generics with olaf code snippet (hcsr04, dyp me007, etc...), so we can work direcly on the feature with most of hardawre and sonarAlt is in cm in each impl
---- hardware impl
->is there other hardware to impl ? like serial sonar ? laser/lidar ?
->is error should be handled by "driver" or later by feature implementation ? (sonar are very sensitive and error generative with EMF, too close to motor, different ultrasonic absorption of ground, -> "despite of many effort, reading/shits will append, necesserly and obviously"
-> other idea ?
--- feature
there is some different request as this time so:
-> what kind of feature should we propose: keep distance to ground (relative alt hold), more alt precision (fusion with baro readings), mix of two with different marker for diferent behaviour ?
-> low alt warning (led/buzzer), trigger (airbag, landing gear) ?
-> more "general collision avoidance" like horizontal/wall detecting ?
-> other idea ?
--- implementation
it depends of feature but there is a leat a pid loop and acc_z usage
-> do we use the baro alt hold as working base (with acc_z impl) which mean sharing same pid loop ?
-> do we use tilt correction ? (since arducopter use it, i think it's not a bad idea and worth the try)
-> do we handled readings error here with lpf/hpf ? (which if shared with baro would be tricky since sonar is way less sloppy ?)
etc.... so before throwing many version and implemention, i think we should answer all theses questions and write code/impl after
Re: Attemp to integrate sonar (ultrasonic sensor)
penpen77 wrote:arducopter use tilt correction so i think it worth a try
As I remember it was commented there...
In any case I'm pretty sure and I checked this with at least hc-sr04, dyp-me007
Just do simple test... Start to tilt slowly and till 15-25 degree raw altitude value will be the same... after 15-25 it stops to return correct value at all...
thx-
Alex
Re: Attemp to integrate sonar (ultrasonic sensor)
tried on concrete floor, with hcsr 04 and srf08, raw reading wasn't at all the same.... may be at 10cm of the floor with ground multipath reflection, but at 1m and more, raw values aren't the same at all. And with tilting correction, readings became stable and precise even with tilt more than 30°/45°
anyway you can comment/uncomment it, so feel free to use it or not, maybe in some env it will works maybe not
other point, tilting correction is maybe in the wrong place, but it could'nt be in sonar_upate too, this function is hardware dependant and tilting correction is generic
so 2 way:
- independant function called immediatly after reading (of any kind of hardware)
- feature dependant and called inside/close to feature handling
anyway you can comment/uncomment it, so feel free to use it or not, maybe in some env it will works maybe not
other point, tilting correction is maybe in the wrong place, but it could'nt be in sonar_upate too, this function is hardware dependant and tilting correction is generic
so 2 way:
- independant function called immediatly after reading (of any kind of hardware)
- feature dependant and called inside/close to feature handling
Re: Attemp to integrate sonar (ultrasonic sensor)
I just had a try, with sonar alone and mixing with baro, even with 1/9 ratio, it's too much, we need raw values, absolutly
it's on concret in my basement since it's a little bit too windy outside for now
I've recorder with a keychain this time with the sr04 which is the cheapest avaible for those who want to try
so, 2 thing (again)
- we need raw value without filtering/smoothing/integrating or very little one (less than 1 to 9 averaging) if we want tu use acc_z/baro alt hold implementation
- if sonar alone, pid has to be agressive, if baro/sonar fusion, and sharing same pid, sonar will be a little sloppy, or we can use some "climbing rate"
by the way, tilting works perfectly, at least on concrete, even with the "bubled beam shape of sr08", tilting quad loose less alt with tilting correction
http://youtu.be/DSQ9LSuyU9s
working but really lazy on climbing and as it share baro pid, it cant be more agressive without impacting baro alt hold (the drifting is my fault, cg was bad and not trimmed)
This is essentially the same as my older code but without mess up version and up to date with r1177. I've refactoring the code, to be working with or without baro, added some commentary/questioning for improvement, moving element where they belong (at least logicaly) and removing filtering/smoothing (sorry but inefficient)
The config.h is also clean, don't forget to enable stuff as it should be (if using generic sonar, dont forget to uncomment the 3 define and set them, and if necessary for exotic pinout, change def.h macro)
it's on concret in my basement since it's a little bit too windy outside for now
I've recorder with a keychain this time with the sr04 which is the cheapest avaible for those who want to try
so, 2 thing (again)
- we need raw value without filtering/smoothing/integrating or very little one (less than 1 to 9 averaging) if we want tu use acc_z/baro alt hold implementation
- if sonar alone, pid has to be agressive, if baro/sonar fusion, and sharing same pid, sonar will be a little sloppy, or we can use some "climbing rate"
by the way, tilting works perfectly, at least on concrete, even with the "bubled beam shape of sr08", tilting quad loose less alt with tilting correction
http://youtu.be/DSQ9LSuyU9s
working but really lazy on climbing and as it share baro pid, it cant be more agressive without impacting baro alt hold (the drifting is my fault, cg was bad and not trimmed)
This is essentially the same as my older code but without mess up version and up to date with r1177. I've refactoring the code, to be working with or without baro, added some commentary/questioning for improvement, moving element where they belong (at least logicaly) and removing filtering/smoothing (sorry but inefficient)
The config.h is also clean, don't forget to enable stuff as it should be (if using generic sonar, dont forget to uncomment the 3 define and set them, and if necessary for exotic pinout, change def.h macro)
Last edited by penpen77 on Thu Oct 25, 2012 4:38 pm, edited 1 time in total.
Re: Attemp to integrate sonar (ultrasonic sensor)
penpen77 wrote:tried on concrete floor, with hcsr 04 and srf08, raw reading wasn't at all the same.... may be at 10cm of the floor with ground multipath reflection, but at 1m and more, raw values aren't the same at all. And with tilting correction, readings became stable and precise even with tilt more than 30°/45°
Ok, i will re-check this, but remember exactly and we agreed with other developers (from russian forum) that is independent from inclination... You can see that sonar has a conus-emitter which generates divergent beam... this why it independent for some angle range...
penpen77 wrote:- we need raw value without filtering/smoothing/integrating or very little one (less than 1 to 9 averaging)
yes, but you need to take into account and exclude values when sonar has errors... this why I took error-based sonar driver (from alexmos).
penpen77 wrote:- if sonar alone, pid has to be agressive, if baro/sonar fusion, and sharing same pid, sonar will be a little sloppy, or we can use some "rate"
I have took this into account but on "bad" surface with e.g. grass it produce additional wobbles... Probably make sense to apply this if SonarErrors=0, i.e. when surface is exactly clear...so as for now I turned it off...
Code: Select all
// Increase P-term if sonar is used
#if SONAR && defined(SONAR_BARO_PID_GAIN)
if(SonarErrors < SONAR_ERROR_MAX) {
error += constrain(error * (SONAR_ERROR_MAX - SonarErrors) / SONAR_ERROR_MAX * SONAR_BARO_PID_GAIN, -150, 150);
}
#endif
My current version 2.1_b4 will be posted with description soon in this thread: viewtopic.php?f=8&t=2371&p=25759#p25699
thx-
Alex
Last edited by mahowik on Thu Oct 25, 2012 5:26 pm, edited 1 time in total.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Attemp to integrate sonar (ultrasonic sensor)
Why not try two sonars (forward and aft) and compare the two readings? Yes, it is more weight.
Re: Attemp to integrate sonar (ultrasonic sensor)
copterrichie wrote:Why not try two sonars (forward and aft) and compare the two readings? Yes, it is more weight.
you can try, but cheap sonars (like hc-sr04, dyp-me007) need to be handled with interrupt... so if you have resources on your board for this, why not
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Attemp to integrate sonar (ultrasonic sensor)
mahowik wrote:copterrichie wrote:Why not try two sonars (forward and aft) and compare the two readings? Yes, it is more weight.
you can try, but cheap sonars (like hc-sr04, dyp-me007) need to be handled with interrupt... so if you have resources on your board for this, why not
This is where having a housekeeping co-processor would come in handy. I believe someone used an ATiny2313 and was able to connect many, not sure if that was Tommy.
Re: Attemp to integrate sonar (ultrasonic sensor)
tinygps only supports 1 ultrasonic sensor (at least last time I checked). atmega328 is a better option. not really worth saving $2 to deal with hassles of programming the attiny chip. or one can just use a promini (about $10 on ebay) and just solder the sensor lines to the board (if you build the board yourself, you will be spending close to $10 already anyway).
------------
Go Giants!
------------
Go Giants!
Re: Attemp to integrate sonar (ultrasonic sensor)
just have a try on grass/sand/ground/strange_orange_rubber_ground_of_athletism_stadium and had good behavior with above code. I've pushed more P and I term since i hadn't thing above my head. Still "sleepy/lazy" to climb/react, but different nature of ground hadn't so much bad influence, of course a little bit, but not as much i've expected. Even with activating at 10cm of the grass and doing some switch grass<->ground<->grass, it sill hold correctly. That's the behavior i had with the last version. In the other hand, of course i will never trust the sensor to perform some very low pass at high speed between two different kind of ground.
The only bad point is that still not avoid collision with crazy children who try to catch with hand rotating little saw of death even if you said dont touch, dont get too close"..... so i had to abort test....
http://youtu.be/Y26gE2xTxjo
The only bad point is that still not avoid collision with crazy children who try to catch with hand rotating little saw of death even if you said dont touch, dont get too close"..... so i had to abort test....
http://youtu.be/Y26gE2xTxjo
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Attemp to integrate sonar (ultrasonic sensor)
doughboy wrote:tinygps only supports 1 ultrasonic sensor (at least last time I checked). atmega328 is a better option. not really worth saving $2 to deal with hassles of programming the attiny chip. or one can just use a promini (about $10 on ebay) and just solder the sensor lines to the board (if you build the board yourself, you will be spending close to $10 already anyway).
------------
Go Giants!
My BAD, it is the I2C Sonar implementation that supports more than one.
viewtopic.php?f=7&t=1282&hilit=sonar+i2c
Re: Attemp to integrate sonar (ultrasonic sensor)
mahowik wrote:penpen77 wrote:The only erratics values was above 4/5m where tilting correction gave more wobbly readings.Code: Select all
#ifdef SONAR_TILT_CORRECTION
float temp = cos(float(angle[1])/10) * cos(float(angle[0])/10);
temp = max(temp+0.05, 0.707);
temp = constrain(temp,0.707,1.0);
temp = (float)sonarAlt * temp;
if(temp<sonarAlt) sonarAlt = temp;
#endif
It doesn't make sense to use tilt correction for sonar because raw data from sonar independent from inclinations in range of 15-25 degrees (depends on sonar ... see doc). If inclination more than sonar visibility you should catch this and switch to baro...
thx-
Alex
BTW, I pointed out elsewhere in this thread that the above sonar tilt correction code is incorrect, as cosine function requires radians and not degrees. Perhaps that is why the code is not working for you (besides it being in the wrong place, which I also pointed out).
------------
Go Giants!
Re: Attemp to integrate sonar (ultrasonic sensor)
this code is not longer used, it has been corrected
Re: Attemp to integrate sonar (ultrasonic sensor)
where is the corrected code?
perhaps I may be missing it, but the only code I know of is the one in magnetron branch. everything else is just a snippet here and a snippet there.
I think it is a good idea to actually check in the official code in the branch so others can get and test it and we are all referring to the same code.
------------
Go Giants!
perhaps I may be missing it, but the only code I know of is the one in magnetron branch. everything else is just a snippet here and a snippet there.
I think it is a good idea to actually check in the official code in the branch so others can get and test it and we are all referring to the same code.
------------
Go Giants!
Re: Attemp to integrate sonar (ultrasonic sensor)
doughboy wrote:where is the corrected code?
viewtopic.php?f=7&t=1033&start=140#p25760
what I am missing, wasn't mahowik going to post his sonar code ?
Re: Attemp to integrate sonar (ultrasonic sensor)
mahowik wrote:penpen77 wrote:tried on concrete floor, with hcsr 04 and srf08, raw reading wasn't at all the same.... may be at 10cm of the floor with ground multipath reflection, but at 1m and more, raw values aren't the same at all. And with tilting correction, readings became stable and precise even with tilt more than 30°/45°
Ok, i will re-check this, but remember exactly and we agreed with other developers (from russian forum) that is independent from inclination... You can see that sonar has a conus-emitter which generates divergent beam... this why it independent for some angle range...
Yes, I re-tested it (on parquet... about 1m) yesterday and now I'm sure on 100% that is independent from inclination... Probably this because your sonar not in the center of the copter and when you are tilt this you also changes the altitude...
doughboy wrote:BTW, I pointed out elsewhere in this thread that the above sonar tilt correction code is incorrect, as cosine function requires radians and not degrees. Perhaps that is why the code is not working for you (besides it being in the wrong place, which I also pointed out).
I'm not talking about that compensation code correct or not correct... I'm not using it in my implementation because it's doesn't make sense at all...
crazyal wrote:what I am missing, wasn't mahowik going to post his sonar code ?
soon soon...
viewtopic.php?f=7&t=1033&start=140#p25761
thx-
Alex
Last edited by mahowik on Fri Oct 26, 2012 6:25 pm, edited 1 time in total.
Re: Attemp to integrate sonar (ultrasonic sensor)
mahowik wrote:I'm not talking about that compensation code correct or not correct... I'm not using it in my implementation because it's doesn't make sense at all...
the trigonometry part makes sense, if you tilt it at an angle, taking cosine on both axes gives you the distance perpendicular to ground.
you are assuming the sound works like light reflection where it will bounce off to a different angle but not back to the source.
or you care to explain why it does not make sense?
------------
Go Giants!
Re: Attemp to integrate sonar (ultrasonic sensor)
doughboy wrote:or you care to explain why it does not make sense?
As I wrote before... You can see that sonar has a conus-emitter which generates divergent beam... this why it independent for some angle range...
and just check raw data form sonar and you will see
Re: Attemp to integrate sonar (ultrasonic sensor)
ok, you lost me there with "conus-emitter". I don't know what that is.
but yes, I checked the raw data and it works fine, just as with penpen77, and the arducopter folks.
so it seems you are alone, perhaps you got a bad sonar.
but yes, I checked the raw data and it works fine, just as with penpen77, and the arducopter folks.
so it seems you are alone, perhaps you got a bad sonar.
Re: Attemp to integrate sonar (ultrasonic sensor)
doughboy wrote:perhaps you got a bad sonar.
It seems all my five sonars are broken...
Last time: just check raw data from sonar but during the inclination make sure that sonar (but not copter) at the same altitude
p.s. pls. look to the directional diagram (beam pattern) http://jaktek.com/wp-content/uploads/20 ... C-SR04.pdf
It helps to understand why...
Re: Attemp to integrate sonar (ultrasonic sensor)
just a quick quick question.. is the sonar code included in the latest dev yet? it seems there is only i2c sonar.. not the serial ones...
tbx
tbx
Re: Attemp to integrate sonar (ultrasonic sensor)
there isn't (at last from what i know) any implementation for serial ultrasonic sensor. Most of serial/rs232/ttl sensor are from maxbotix and there aren't cheap....
for devantech serial, they all have i2c capabilities too if i'm right
for devantech serial, they all have i2c capabilities too if i'm right
Re: Attemp to integrate sonar (ultrasonic sensor)
for "tilting issue"
http://www.robot-electronics.co.uk/htm/sonar_faq.htm
http://www.robot-electronics.co.uk/htm/srf02tech.htm
by the way, it's just a tiny piece of code which is not driver dependant nor feature dependant, so, a #define with some blabla for saying "try, may not work" and that's all. No need to argue, let's looking for feature improvement
http://www.robot-electronics.co.uk/htm/sonar_faq.htm
http://www.robot-electronics.co.uk/htm/srf02tech.htm
by the way, it's just a tiny piece of code which is not driver dependant nor feature dependant, so, a #define with some blabla for saying "try, may not work" and that's all. No need to argue, let's looking for feature improvement
Re: Attemp to integrate sonar (ultrasonic sensor)
penpen77 wrote:there isn't (at last from what i know) any implementation for serial ultrasonic sensor. Most of serial/rs232/ttl sensor are from maxbotix and there aren't cheap....
for devantech serial, they all have i2c capabilities too if i'm right
ok.. so probably i have some misunderstanding about type of sonar now..
mine has trig/echo/vcc/gnd.. same as the one used in first post
but mine is HC-SR04
http://www.aliexpress.com/item/HC-SR04- ... 54103.html
thx
Re: Attemp to integrate sonar (ultrasonic sensor)
If anyone is interested I took penpen77 sonar code and implemented it into baseflight on my github branch. https://github.com/luggi/baseflight/tree/sonar
I got rid of the fade part and update Barohome continously when sonar is in range.
Any ideas what flaws this implementation could have ? I couldn't test it outside yet, due to bad weather and snow.
I got rid of the fade part and update Barohome continously when sonar is in range.
Any ideas what flaws this implementation could have ? I couldn't test it outside yet, due to bad weather and snow.
Re: Attemp to integrate sonar (ultrasonic sensor)
updated code to r1240 with sr04/dypme007/echo-trigger generic driver
be carefull, this is my current config.h, so check each define to adapt to your config
if you want to merge change, take care of crappy piece of code added to "emulate" Baro mode presence without baro
be carefull, this is my current config.h, so check each define to adapt to your config
if you want to merge change, take care of crappy piece of code added to "emulate" Baro mode presence without baro
- Attachments
-
- MultiWii_r1240_sonar.rar
- (122.12 KiB) Downloaded 2212 times
Last edited by penpen77 on Mon Nov 05, 2012 10:41 am, edited 1 time in total.
Re: Attemp to integrate sonar (ultrasonic sensor)
Why the HC-SR04 sonar is not a option in official dev. versions? It is quite a pain to try to integrate it every time!
Re: Attemp to integrate sonar (ultrasonic sensor)
Great work. I've tested the code today and it works very very fine. When I activate the sonar the quad holds the altitude in a perfect way, as a hummingbird. Thanks too much.
Really, somebody should consider including it in next release of Multiwii.
Really, somebody should consider including it in next release of Multiwii.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Attemp to integrate sonar (ultrasonic sensor)
rortega wrote:Great work. I've tested the code today and it works very very fine. When I activate the sonar the quad holds the altitude in a perfect way, as a hummingbird. Thanks too much.
Really, somebody should consider including it in next release of Multiwii.
Great news, what is the maximum altitude it will hold?
Thank you.
Re: Attemp to integrate sonar (ultrasonic sensor)
rortega wrote:When I activate the sonar the quad holds the altitude in a perfect way, as a hummingbird. Thanks too much.
Can you share a clip?
Re: Attemp to integrate sonar (ultrasonic sensor)
Here you are the video: http://youtu.be/4fwnxL15yCQ
Sorry about the quality, duration, ... Its all I can record with my smartfone while it is on the ground ...
Sorry about the quality, duration, ... Its all I can record with my smartfone while it is on the ground ...
Re: Attemp to integrate sonar (ultrasonic sensor)
KasparsL wrote:Why the HC-SR04 sonar is not a option in official dev. versions? It is quite a pain to try to integrate it every time!
same question here... since sr04 is much cheaper and easier to get... why isnt it in the official fork?
Re: Attemp to integrate sonar (ultrasonic sensor)
Hello,
is it possible to get information about how i can use it with my CRIUS AIO V1.0. The official Trigger Output should be PIN9 i think und the Echo Input PIN10. If i simply change them in def.h nothing happens and in debug mode there are no informations about measering. Must there been additional changes?
best regards
Christian
is it possible to get information about how i can use it with my CRIUS AIO V1.0. The official Trigger Output should be PIN9 i think und the Echo Input PIN10. If i simply change them in def.h nothing happens and in debug mode there are no informations about measering. Must there been additional changes?
Code: Select all
#if defined(SONAR_GENERIC_ECHOPULSE)
#define SONAR_GEP_TriggerPin 12 <<< PIN9
#define SONAR_GEP_TriggerPin_PINMODE_OUT pinMode(SONAR_GEP_TriggerPin,OUTPUT);
#define SONAR_GEP_TriggerPin_PIN_HIGH PORTB |= 1<<6;
#define SONAR_GEP_TriggerPin_PIN_LOW PORTB &= ~(1<<6);
#define SONAR_GEP_EchoPin 11 <<<< PIN10
#define SONAR_GEP_EchoPin_PINMODE_IN pinMode(SONAR_GEP_EchoPin,INPUT);
#define SONAR_GEP_EchoPin_PCINT PCINT5
#define SONAR_GEP_EchoPin_PCICR PCICR |= (1<<PCIE0); // PCINT 0-7 belong to PCIE0
#define SONAR_GEP_EchoPin_PCMSK PCMSK0 = (1<<SONAR_GEP_EchoPin_PCINT); // Mask Pin PCINT5 - all other PIns PCINT0-7 are not allowed to create interrupts!
#define SONAR_GEP_EchoPin_PCINT_vect PCINT0_vect // PCINT0-7 belog PCINT0_vect
#define SONAR_GEP_EchoPin_PIN PINB // PCINT0-7 belong to PINB
#endif
best regards
Christian
Re: Attemp to integrate sonar (ultrasonic sensor)
i'm using a crius for my test, the default def.h I left in the archive is made for crius pinout
Re: Attemp to integrate sonar (ultrasonic sensor)
Hmm, but why doesn't that works for me? Is it right, that in debug-mode Debug1 should show the altitude?
Do you also use the connections marked here as trigger and echo?
Do you also use the connections marked here as trigger and echo?
Re: Attemp to integrate sonar (ultrasonic sensor)
A new and better video that shows how it flies in ANGLE+SONAR/BARO+MAG mode: https://www.youtube.com/watch?v=eiv7_8GAN20
And this other only with acro mode: https://www.youtube.com/watch?v=J0Mz-SKEU-4
And this other only with acro mode: https://www.youtube.com/watch?v=J0Mz-SKEU-4
Re: Attemp to integrate sonar (ultrasonic sensor)
Excalibur, I reply to you in the public thread, so it will be usefull for others:
Here you are how it's defined in def.h file:
So, yo only need to connect Triger to signal pin 12, and Echo to signal pin 11, exactly the pins with same numbers as you see on the board. Also you need to connect vcc and gnd wires to the vcc pin and gnd pin 12 or 11, any of them is the same.
The image linked inside the thread of the forum is not correct, it use other pins. If you use the code above as it is defined, you must use pins 11 and 12 of your board. Thats all.
Don't forget to define generic sonar in config.h:
I use 450 cm as max range because this is the value in the specs from the supplier where i bought it.
Sorry for not sending an image of my quad, but I have to disassemble many parts to do a good photo, but if you do what I say it will work nice.
Here you are how it's defined in def.h file:
Code: Select all
#if defined(SONAR_GENERIC_ECHOPULSE)
#define SONAR_GEP_TriggerPin 12
#define SONAR_GEP_TriggerPin_PINMODE_OUT pinMode(SONAR_GEP_TriggerPin,OUTPUT);
#define SONAR_GEP_TriggerPin_PIN_HIGH PORTB |= 1<<6;
#define SONAR_GEP_TriggerPin_PIN_LOW PORTB &= ~(1<<6);
#define SONAR_GEP_EchoPin 11
#define SONAR_GEP_EchoPin_PINMODE_IN pinMode(SONAR_GEP_EchoPin,INPUT);
#define SONAR_GEP_EchoPin_PCINT PCINT5
#define SONAR_GEP_EchoPin_PCICR PCICR |= (1<<PCIE0); // PCINT 0-7 belong to PCIE0
#define SONAR_GEP_EchoPin_PCMSK PCMSK0 = (1<<SONAR_GEP_EchoPin_PCINT); // Mask Pin PCINT5 - all other PIns PCINT0-7 are not allowed to create interrupts!
#define SONAR_GEP_EchoPin_PCINT_vect PCINT0_vect // PCINT0-7 belog PCINT0_vect
#define SONAR_GEP_EchoPin_PIN PINB // PCINT0-7 belong to PINB
#endif
So, yo only need to connect Triger to signal pin 12, and Echo to signal pin 11, exactly the pins with same numbers as you see on the board. Also you need to connect vcc and gnd wires to the vcc pin and gnd pin 12 or 11, any of them is the same.
The image linked inside the thread of the forum is not correct, it use other pins. If you use the code above as it is defined, you must use pins 11 and 12 of your board. Thats all.
Don't forget to define generic sonar in config.h:
Code: Select all
/* Generic sonar: hc-sr04, srf04, dyp-me007, all generic sonar with echo/pulse pin
default pulse is PH6/12, echo is PB4/11
*/
#define SONAR_GENERIC_ECHOPULSE
#define SONAR_GENERIC_SCALE 58 //scale for ranging conversion (hcsr04 is 58)
//#define SONAR_GENERIC_MAX_RANGE 500 //cm (could be more)
#define SONAR_GENERIC_MAX_RANGE 450
I use 450 cm as max range because this is the value in the specs from the supplier where i bought it.
Sorry for not sending an image of my quad, but I have to disassemble many parts to do a good photo, but if you do what I say it will work nice.
Re: Attemp to integrate sonar (ultrasonic sensor)
Perhaps, if you upload megapirates code to your board you must use "the official pins 9 and 10". But for the code of this thread, use 11 and 12.
Re: Attemp to integrate sonar (ultrasonic sensor)
you can use others pin, but in this case, you'll have to change the other parameters/defs SONAR_GEP_TriggerPin_xxx (bit shifting, interrupt, etc...). The DEFINE list in GENERIC_ECHO_PULSE is made to make this easy: refere to arduino 2560 pinout: 12 is PB6 (so shifting 6), 11 is pb5, pcint5 so pcint0-7 range, so PCINT0/PCIE0 flag. Adapt that with your pin selection (but without overriding pin/io/interrupt used by multiwii "core")
Re: Attemp to integrate sonar (ultrasonic sensor)
Has someone used more than 1 sonar to implement object avoidance test?
Re: Attemp to integrate sonar (ultrasonic sensor)
Thanks to all, it's working now. Thought that i have to use PIN 9 and 10 in any case. Next step is to get code for autolanding by sonar.
P.S.: Where can i get more information about all the definitions that are used to define the pinouts, so that i would be able to change or add pin's? Are there describtions or tutorials?
P.S.: Where can i get more information about all the definitions that are used to define the pinouts, so that i would be able to change or add pin's? Are there describtions or tutorials?
Code: Select all
#define SONAR_GEP_TriggerPin_PIN_HIGH PORTB |= 1<<6;
#define SONAR_GEP_TriggerPin_PIN_LOW PORTB &= ~(1<<6);
#define SONAR_GEP_EchoPin_PINMODE_IN pinMode(SONAR_GEP_EchoPin,INPUT);
#define SONAR_GEP_EchoPin_PCINT PCINT5
#define SONAR_GEP_EchoPin_PCICR PCICR |= (1<<PCIE0); // PCINT 0-7 belong to PCIE0
#define SONAR_GEP_EchoPin_PCMSK PCMSK0 = (1<<SONAR_GEP_EchoPin_PCINT); // Mask Pin PCINT5 - all other PIns PCINT0-7 are not allowed to create interrupts!
#define SONAR_GEP_EchoPin_PCINT_vect PCINT0_vect // PCINT0-7 belog PCINT0_vect
#define SONAR_GEP_EchoPin_PIN PINB // PCINT0-7 belong to PINB
Re: Attemp to integrate sonar (ultrasonic sensor)
Goog morning,
back from testing and several problems detected. First of all, when i arm my copter it goes some times directly in failsafe mode as if there is not enough "power" left for the rest of the board. Sometimes it works. Is it possible that gps and sonar together need to much current?
Next prob was, that as i switched on level+bara it suddenly pitches backward. All qyros, acc and mag were calibrated but he still wants to drift in one direction backwards.
best regards Christian
back from testing and several problems detected. First of all, when i arm my copter it goes some times directly in failsafe mode as if there is not enough "power" left for the rest of the board. Sometimes it works. Is it possible that gps and sonar together need to much current?
Next prob was, that as i switched on level+bara it suddenly pitches backward. All qyros, acc and mag were calibrated but he still wants to drift in one direction backwards.
best regards Christian
Re: Attemp to integrate sonar (ultrasonic sensor)
Sorry for asking, but I can't find it in the thread... does there exist a working I²C-sonarcode? I really don't like the idea of connecting the sonar directly to the controller and want to use I²C to do so...
Re: Attemp to integrate sonar (ultrasonic sensor)
Hello,
so i have tested a while today because of the goog wheather. But the sonar function isn't realy working with my crius. In the MWC i can see the debugged values but the activated baro function doesn't work.
Do i have to activated angle or horizon as well? Is it normal, that when i have activated baro and then change my throttle stick, that the baro button in MWC blinks?
best regards
Christian
so i have tested a while today because of the goog wheather. But the sonar function isn't realy working with my crius. In the MWC i can see the debugged values but the activated baro function doesn't work.
Do i have to activated angle or horizon as well? Is it normal, that when i have activated baro and then change my throttle stick, that the baro button in MWC blinks?
best regards
Christian
Re: Attemp to integrate sonar (ultrasonic sensor)
GLB gets some TTL serial sonar now...
http://www.goodluckbuy.com/uart-ttl-ser ... dule-.html
i wonder except the connection.. what other differences are between ttl/i2c/ trig-echo?
http://www.goodluckbuy.com/uart-ttl-ser ... dule-.html
i wonder except the connection.. what other differences are between ttl/i2c/ trig-echo?
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Attemp to integrate sonar (ultrasonic sensor)
jy0933 wrote:GLB gets some TTL serial sonar now...
http://www.goodluckbuy.com/uart-ttl-ser ... dule-.html
i wonder except the connection.. what other differences are between ttl/i2c/ trig-echo?
In other to get this one to work, a serial port or Softserial is required.
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: Attemp to integrate sonar (ultrasonic sensor)
Hi,
I ordered HC-SR04... this one http://www.goodluckbuy.com/ultrasonic-w ... -sr04.html
Since we are using trigger and echo, almost any ultrasonic sensor with this will do the job, or not?
Cheers,
KV
EDIT: Yes... I saw now that some are already using it! Thanks.
I ordered HC-SR04... this one http://www.goodluckbuy.com/ultrasonic-w ... -sr04.html
Since we are using trigger and echo, almost any ultrasonic sensor with this will do the job, or not?
Cheers,
KV
EDIT: Yes... I saw now that some are already using it! Thanks.
Re: Attemp to integrate sonar (ultrasonic sensor)
My last video testing POSHOLD and RTH with GPS and serial sonar HC-SR04 integrated in r12340 version.
http://www.youtube.com/watch?v=Jmue9jEYwc8
http://www.youtube.com/watch?v=Jmue9jEYwc8
Re: Attemp to integrate sonar (ultrasonic sensor)
penpen77 wrote:if you want to merge change, take care of crappy piece of code added to "emulate" Baro mode presence without baro
can you point this workaround you added?
tnx
-
- Posts: 1
- Joined: Fri Feb 01, 2013 7:17 am
Re: Attemp to integrate sonar (ultrasonic sensor)
Hi all. I have been trying without success to get my Crius AIOP V1.1 board going with sonar. I am new to editing code so don't know very much about it. I'm using the HC-SR04 from Hobby King. I'm flying a quad in X mode. Can somebody post a copy of their working sketch please. Thanks in advance.
Lithium Bob.
Lithium Bob.