Mmm I don’t think that parabolic sound reflectors and shotgun microphones are really an option for my 9 cm3 robot…
I only conducted experiments in two rooms in my house. The reason I suspect an ultrasound noisy environment is that the sensor returns very low values only in the kitchen. The sensor appears to work fine in my office, and the distances to the “phantom” objects appears to be random.
You would think that clutter and cheap electronic etc would affect the sensor no matter where its is (?). My office is small so the field of view would be a particular issue there.
My tubes were not an attempt to amplify the signal coming from the trigger, but to eliminate sound from other sources that may cause the ECHO cone to resonate. The failure in my thinking is not to realise that the noise will be coming from everywhere including from directly in front of the sensor, because its bouncing of the walls ceiling floor furniture and so on.
I forgot to mention that I implemented a High Pass filter in the distance measurement - Currently the 10 estimates of the distance is taken and only the highest estimate is kept - maybe all I need to increase the number of distance readings. This of course will slow things down so I was reluctant to go much above 10.
I’ll consider all the stuff you posted, but I am thinking: ditch the SR04 or use the robot in another room!
Yes, we are in agreement. I was trying to explain why the tubes wouldn’t do what you want, showing that trying to fit working directional sound reception into your tiny robot (relative to the size of the sensors) wouldn’t work, and I led with:
Another advantage of the TOF sensors; if you wire up the interrupt pin on them and set in alert mode you can have your robot deep sleep until something crosses it’s line of sight and then wake.
You can even configure the sensors to tell you if the movement was left-to right or vice.versa; so you can do interesting reactions to movement etc.
I am a novice to all of this. I started this project a few weeks ago, but I have been collecting the parts for the robot for a long while. The choices that I made were largely based on what I saw others using on YT. This includes the DC motors, the motor driver, the HC-SR04, and the optical encoders.
While I am grateful for the generosity of the YouTubers, it seems that none of them take the time to discuss the limitations of their choice of components, or the fiery hoops they had to jump through to get them to work.
If I ever publish QB like I intend to, I think that I will also need to publish a list of known issues and limitations alongside the current version of the design.
@mcdanlj - I gave the QB project a little bit more of my time today. You may recall that the ZK-5AD motor driver that I am using needs 4 PWM capable pins to control the speed and direction of the 2 motors I was using pins 5,6,9,10 on the Arduino to control Left Motor FWD, Left Motor REV, Right Motor FWD, and Right Motor REV respectively. The trouble is that the PWM frequency of pins 5 and 6 are controlled by Arduino’s Timer 0 and the PWM frequency of pins 9 and 10 are controlled by Timer 1 which also controls functions like delay and millis. The two frequencies are different and the difference makes a huge difference to the motor speed even when sending the same PWMvalue to the pins using analogwrite().
I thought that I had changed the PWM frequency of Timer 1 to match that of Timer 0, but I was wrong. As a results I’ve been having a torrid time of matching the motor speeds so that the robot travels in a straight line.
So I decided to try what you suggested Michael, which is to connect pins 5,6,9,and 10 to Left Motor FWD, Right Motor FWD, Left Motor REV and Right Motor REV respectively. So now the PWM frequency of the Forward Control Signals out of pins 5,6 is the same and QB travels forward in a straight line, and the PWM frequency of the Reverse Control Signals out of pins 9 and 10 is also the same and QB travels in reverse in a straight line - no speed compensation required because left is pretty much equal to right at all PWM values.
The reversing speed is lower than the forward speed, but that’s not a big deal.
QB does not spin quite right yet, but it’s all coming together!
UPDATE: Gave up on the ZK-5AD motor driver and installed a dual TB6612FNC motor driver - smaller, just as power efficient and its a lot like the ubicutous L298N driver. The TB6612 works a treat! Now I have speed control over the full 0-255 PWM setting range so that QB can run at very low speeds, and PID speed control using low pulse count/revolution encoders is realistic. I only changed it because it needs only 2 PWM capable pins as opposed to 4 for the ZK-5AD but the TB6612 is far superior in many other ways.
I also solved the problems I encountered with the HC-SR04 distance sensor… well, sort of. It turns out that the field of detection of this unit is shaped like an elongated tear drop, with a 30 degree cone and a 4 m length. The diameter of the cone is about 20 cm at about 1 m from the sensor. This means that the sensor is set close to the ground, there will be a lot of echoes from the floor. I have now set QBs HC-SR04 much higher up. Makes it look a little different, but that should reduce the incidence of the floor being detected as an object. Unfortunately this also means that QB is blind to low objects that are less than 12 cm away. Ce la vie…
I’ve also given QB an HC-06 bluetooth module which brings in the possibility of remote control or even better - sending a series of remote commands for QB to obey. Think: go forward four “steps” - turn right - collect object - return to base - play a sound.
I’m hoping to Open Source QB so that anyone can build and improve him. I think he’s almost “Ready for the World”
It’s short for “Too long; didn’t read”
