I encountered a small problem. In the case of a hardware or wiring problem with the PING, this code that works will hang at the getDuration call. Also, I noticed that a 20ms sleep works and a 10ms sleep does not with working hardware.
So my question is, can you give us a way to limit the time for the getDuration(). For example we know that the ping is only good to about 3 meters or 17.74ms. If we had a call like getDuration(msLimit), we could make the call getDuration(20) and know that it will return after 20ms. I had an intermittent power lead to the PING and my whole robot stopped. Thanks Duane On Sunday, April 27, 2014 8:24:19 PM UTC-7, Ytai wrote: > > Cool. If you can create a nice class for using the PING (where the ctor > gets a IOIO and two pin numbers, and there's a getDistance() method) and > share it on this forum, it would be a decent return for our efforts :) As a > side note, since you're doing the open-close trick, you might as well use a > single pin and open-close the digital output as well and not need the > driver chip, so you can even further simplify both your code and your > circuit. > > > On Sun, Apr 27, 2014 at 8:19 PM, Vic Wintriss > <[email protected]<javascript:> > > wrote: > >> I finally got it to work using your last suggestion. This code works >> that you recommended works perfectly. Thanks so much for sticking with us. >> We've got 30 or 40 kids using this code at the International Autonomous >> Robot Competition (iARoC 2014) coming up at the end of June. Check out >> iaroc.org. >> >> triggerHigh(); >> in = openPulseInput(); >> sleep(20ms); // wait until the pulse input module is ready for a pulse. >> triggerLow(); // kick off a measurement (falling edge does not trigger >> the pulse input) >> duration = in.getDuration(); >> in.close(); >> return duration; >> >> On Sunday, April 27, 2014 11:36:53 AM UTC-7, Ytai wrote: >> >>> Let me shed some light on the internals of PulseInput: >>> >>> - A timer is running on the IOIO set to 200Hz (5ms). >>> - As soon as the pulse input module is opened, and every time after >>> a pulse is captured the module will be put in the "ready" state. >>> - Every time the 200Hz timer triggers, each "ready" module will be >>> activated, i.e. put in a state where it is waiting for a new pulse. >>> - Once activated, the module will wait forever (or until closed) for >>> a pulse, then measure its duration, then sends the result to the >>> Android. >>> - So this means that effectively no matter what the actual pulse >>> rate is, you will never get more than 200 reports per second. This has >>> been >>> done on purpose to prevent a high frequency pulse train from saturating >>> the >>> connection between the IOIO and the Android. This also means that there >>> is >>> a potential "dead time" of up to 5ms after opening or between pulses, >>> during which a pulse would not be detected. >>> - On the Android side, every pulse report finds its way to your >>> PulseInput object. You can then read it in one of three ways: >>> - getDuration() will return the last report. It will generally >>> not block, then only exception is until the first report arrives. >>> - getDurationSync() will always block until a new report comes >>> in, then return it. So you can be sure that the report is new. >>> - getDurationBuffered() pulls pulses one by one from a queue. >>> When the queue becomes empty it behave like getDurationSync(), i.e. >>> waits >>> until a new report comes in. >>> >>> The Arduino approach cannot be directly applied to the IOIO API, since >>> you have to take into account that because of the communication between the >>> Android and the IOIO, much of the IOIO API has been designed to be >>> asynchronous in nature. If you were to bake the PING driver directly into >>> the IOIO firmware, you can use a similar approach to Arduino's (although >>> you'd probably want to implement it in a non-blocking way, since the IOIO >>> allows everything to be used concurrently). The reason why I have not done >>> that is because I tried to focus on generic use-cases rather than on one >>> peculiar sensor interface. >>> >>> >>> >>> On Sun, Apr 27, 2014 at 10:57 AM, Duane DeSieno <[email protected]>wrote: >>> >>>> My confusion is maybe over the way getDuration works. >>>> Does it delay 5ms before looking for the pulse or does it look >>>> immediately? >>>> I put 555 timer on the input pin and set it up for 3.15hz and 25.4% >>>> duty cycle or an 80.6ms pulse every 317.4ms. >>>> I called getDuration roughly every 100ms. It did not block and >>>> returned the same value several times before the next pulse occurred(not >>>> what I expected). >>>> >>>> Looked at the Arduino approach to using the PING and they use just one >>>> pin, changing from output after sending a pulse to ping to an input for >>>> their get duration call. >>>> Since they don't impose a 5ms delay, they get the duration of the >>>> return pulse. >>>> >>>> Thanks for you help on this. >>>> >>>> Duane >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ioio-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> >>>> Visit this group at http://groups.google.com/group/ioio-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "ioio-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/ioio-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
