I am NEW to IDE programming, and need some help.
I'd like to enable my grandsons to be able to drive the bot fluidly/continuously — not in predetermined chunks or steps — around in a pattern of their making using the arrow keys.
I imagine a variant/expansion of the Drive_WithRemote, with changes like:
1. instead of setting a fixed distance in the MoveWithOptions() parens, I'd like the bot to continue moving fwd or back as long as the up- or down-key is pressed, and stop when no key is pressed [i.e., released].
2. instead of making single 90° turns when a left-/right-key is pressed, the bot would make perhaps 5° or 10° turns as long as a key is pressed, and stop turning when the key is released.
Do you or anyone else have any suggestions how I get started or collaborate on accomplishing this? I have had my Ringo for 24 hours and no previous Arduino/IDE coding experience. I get how IDE works in general, but I don't have any experience with the calls or libraries, much less experience building out-of-the-box solutions. I have read the code in Tabs like RingoHardware and Behavior, but I am stumped. I dont know if I need to be thinking about different functions, and the 'If…else…' issues for the IR button press utterly escapes me.
Thanks, John
Drive by Remote- expanded
-
- Posts: 180
- Joined: Tue Jul 28, 2015 12:56 am [phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1266: count(): Parameter must be an array or an object that implements Countable
Re: Drive by Remote- expanded
Hello John,
I think this would be possible, and I'm really glad to see someone starting to grow the existing code. I hope to see more of this.
Study the existing drive with remote sketch. A few random thoughts...
While the button is pressed, the remote sends the command over and over. This can tend to flood the IR receive function. I think you would want to introduce a slight delay of maybe a few milliseconds before restarting the IR receive handler after a previous command was received.
You can probably edit the existing drive with remote and make the movements much smaller. Look at the navigation chapter in the guide. This will tell you how the functions in the existing move with remote work. Just make their numbers smaller to get smaller movements.
Ideally, I'd try to reset the receive handler before kicking off the function to actually move, so when you're done with the move, the IR handler has already received and buffered another packet from the remote.
You may want to use the serial print functions to echo out the received IR packet so you can see if it's coming across okay. I do think the existing handler is a bit buggy. Sometimes it misses a packet or receives garbage data. I've put the actual receiving sensor on the scope and there is a good clean signal coming out, so it must be something in software with the IR Receive function. Hopefully I or someone else can have a look at that soon.
Your task is slightly on the complicated side but certainly possible.
-Kevin
I think this would be possible, and I'm really glad to see someone starting to grow the existing code. I hope to see more of this.
Study the existing drive with remote sketch. A few random thoughts...
While the button is pressed, the remote sends the command over and over. This can tend to flood the IR receive function. I think you would want to introduce a slight delay of maybe a few milliseconds before restarting the IR receive handler after a previous command was received.
You can probably edit the existing drive with remote and make the movements much smaller. Look at the navigation chapter in the guide. This will tell you how the functions in the existing move with remote work. Just make their numbers smaller to get smaller movements.
Ideally, I'd try to reset the receive handler before kicking off the function to actually move, so when you're done with the move, the IR handler has already received and buffered another packet from the remote.
You may want to use the serial print functions to echo out the received IR packet so you can see if it's coming across okay. I do think the existing handler is a bit buggy. Sometimes it misses a packet or receives garbage data. I've put the actual receiving sensor on the scope and there is a good clean signal coming out, so it must be something in software with the IR Receive function. Hopefully I or someone else can have a look at that soon.
Your task is slightly on the complicated side but certainly possible.
-Kevin
-
- Posts: 15
- Joined: Sat Oct 17, 2015 9:57 pm [phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1266: count(): Parameter must be an array or an object that implements Countable
Re: Drive by Remote- expanded
Kevin
I think I understand the point you made in paragraph #3 above, but I have no idea how to do it. If I do understand, for my purposes I think I'd still need some kind of conditional on the fact of the button being pressed, and despite several attempts I have not been able to secure the correct statement to include in an if…then… or do …while… function, both of which I tried unsuccessfully. I am sure it is my lack of understanding that is limiting me!
Going the route you suggest in paragraph #4 is conceptually different from what I want to accomplish, though I did try that earlier just to see if I understood the functions themselves.
INSTEAD I have made some [partial] progress by going the following route:
In the Behaviors tab, for cases 11, 14, 12, & 13 I deleted the MoveWithOptions() and the RotateAccurate() functions and substituted Motors() function statements, respectively
Motors(150, 150) for fwd case 11
Motors(-150, -150) for reverse case 14
Motors(0, 75) for left case 12
Motors(75, 0) for right case 13
and since all the flashing leds and chirps are not of particular interest to me here, I re-purposed case 21 as follows
case 21: // "X" key, stop motors
PlayChirp(NOTE_C7,100);
Motors(0, 0);
delay(10);
OffChirp();
break;
The net effect of all this is that after button1 initiates the newly defined DriveWithRemote block, pressing any of the directional arrows on the IRRemote will initiate a continuous [motor] behavior in the expected direction. Pressing another arrow key will substitute that new direction for the previous one, and pressing the "X" key stops Ringo.
I am experiencing what I think may be a Ringo hardware limitation. Ringo itself [does it have a gender?] only receives/acknowledges/accepts a fraction of the IRRemote button presses we make. This makes Ringo's on-the-floor behavior VERY UNRELIABLE and for my grandsons VERY FRUSTRATING. Is this curable in software [adding a delay or some such]??? Or do we perhaps have bad hardware??
For example, my right arrow and left arrow commands cause Ringo to rotate continuously rt and left. Trying to get Ringo to stop rotating so as to go fwd or rev in a specific new direction is almost impossible. There is over-shoot and just plain non-response to the IRRemote. So, I further re-purposed case 18 ["A" key] and case 19 ["B" key] to allow us to interrupt Ringo from fwd or rev motion and then rotate only a given angle [I am using 45° right now] and then remain stopped so we could determine whether he was pretty much headed the new direction we wanted:
case 18: // "A" key, turn left 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(-45, 1000); //rotate 45° anti-clockwise for a max of 1 second
break;
case 19: // "B" key, turn right 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(45, 1000); //rotate 45° clockwise for a max of 1 second
break;
I chose "A" and "B" keys for this due to their physical location on the IRRemote - on either side of the up-arrow key.
So far, we love the sophistication in possibilities. Ringo's sensors can accomplish fabulously complex response with extremely good precision — PreLoaded Behavior 10 is fabulous. And having the code for DriveWithRemote in the PreLoaded file to begin with was terrific. I could never have gotten going without all that help!!
But we humans find we cannot drive Ringo with sufficient precision around on the floor due to the unreliability of the IRRemote-to-Ringo 'connection'.
J
I think I understand the point you made in paragraph #3 above, but I have no idea how to do it. If I do understand, for my purposes I think I'd still need some kind of conditional on the fact of the button being pressed, and despite several attempts I have not been able to secure the correct statement to include in an if…then… or do …while… function, both of which I tried unsuccessfully. I am sure it is my lack of understanding that is limiting me!
Going the route you suggest in paragraph #4 is conceptually different from what I want to accomplish, though I did try that earlier just to see if I understood the functions themselves.
INSTEAD I have made some [partial] progress by going the following route:
In the Behaviors tab, for cases 11, 14, 12, & 13 I deleted the MoveWithOptions() and the RotateAccurate() functions and substituted Motors() function statements, respectively
Motors(150, 150) for fwd case 11
Motors(-150, -150) for reverse case 14
Motors(0, 75) for left case 12
Motors(75, 0) for right case 13
and since all the flashing leds and chirps are not of particular interest to me here, I re-purposed case 21 as follows
case 21: // "X" key, stop motors
PlayChirp(NOTE_C7,100);
Motors(0, 0);
delay(10);
OffChirp();
break;
The net effect of all this is that after button1 initiates the newly defined DriveWithRemote block, pressing any of the directional arrows on the IRRemote will initiate a continuous [motor] behavior in the expected direction. Pressing another arrow key will substitute that new direction for the previous one, and pressing the "X" key stops Ringo.
I am experiencing what I think may be a Ringo hardware limitation. Ringo itself [does it have a gender?] only receives/acknowledges/accepts a fraction of the IRRemote button presses we make. This makes Ringo's on-the-floor behavior VERY UNRELIABLE and for my grandsons VERY FRUSTRATING. Is this curable in software [adding a delay or some such]??? Or do we perhaps have bad hardware??
For example, my right arrow and left arrow commands cause Ringo to rotate continuously rt and left. Trying to get Ringo to stop rotating so as to go fwd or rev in a specific new direction is almost impossible. There is over-shoot and just plain non-response to the IRRemote. So, I further re-purposed case 18 ["A" key] and case 19 ["B" key] to allow us to interrupt Ringo from fwd or rev motion and then rotate only a given angle [I am using 45° right now] and then remain stopped so we could determine whether he was pretty much headed the new direction we wanted:
case 18: // "A" key, turn left 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(-45, 1000); //rotate 45° anti-clockwise for a max of 1 second
break;
case 19: // "B" key, turn right 45°
NavigationBegin();
ZeroNavigation();
PlayAck(); // flash green fwd LED as acknowledgment of IR command
RotateAccurate(45, 1000); //rotate 45° clockwise for a max of 1 second
break;
I chose "A" and "B" keys for this due to their physical location on the IRRemote - on either side of the up-arrow key.
So far, we love the sophistication in possibilities. Ringo's sensors can accomplish fabulously complex response with extremely good precision — PreLoaded Behavior 10 is fabulous. And having the code for DriveWithRemote in the PreLoaded file to begin with was terrific. I could never have gotten going without all that help!!
But we humans find we cannot drive Ringo with sufficient precision around on the floor due to the unreliability of the IRRemote-to-Ringo 'connection'.
J
-
- Posts: 2
- Joined: Sat Feb 27, 2016 12:30 am [phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1266: count(): Parameter must be an array or an object that implements Countable
Re: Drive by Remote- expanded
Hey John,
Did you try the latest updates that Kevin posted on kickstarter ?
It seems to have a fix for those remote controlling troubles !
Arnaud.
Did you try the latest updates that Kevin posted on kickstarter ?
It seems to have a fix for those remote controlling troubles !
Arnaud.
Who is online
Users browsing this forum: No registered users and 1 guest