]]>
A quick note on the predictable movement, is that it seems to have a significant effect if Ringo rocks from one pad to the other when starting movement, as that rotation actually adds a significant component to the inertia of the accellerometer. You may try pressing the motors further up in the clip. Press on the side of the motor can, not the shaft itself because it can press the black cap off the back end.
This will lower Ringo a bit to the surface and remove some of the rocking. This has always helped me. Normally you should get fairly accurate and repeatable movement so if you're getting majorly inaccurate or random movement, let me know how far it is actually missing by.
About the MoveWithOptions and the *edge function... I don't totally understand this either. Dustin included it as something that could be expanded by people who really wanted to hack on it. I believe you simply include the name of the function you want to call when seeing an edge but without the () signs. So if your function was StopAndBackUp() then you'd put StopAndBackUp for this term.
Have a look at the Pre Loaded Behavior #10 which is antonymous roaming. I believe this uses that function so you can see an actual working example. I've recently fixed a few other buggy issues and hope to post a new Base Sketch soon, but this is the next item on my list to really understand and see if it can be implemented in a better way.
Thanks,
-Kevin
Statistics: Posted by Kevin — Sat Nov 21, 2015 2:27 am
]]>
Sorry for not replying, I had not set the "notify me when a reply is posted" option.
Perhaps the easiest way to do what you want is
1) detect button press and move accordingly
2) keep moving until new button is detected ( i.e. "stop" button or new direction)
I will try something and post it soon.
Statistics: Posted by cbw060 — Tue Nov 10, 2015 8:38 pm
]]>
I think my function question was regarding MoveWithOptions and how the edge detection option works. If I understand from my poking into your code, i put the name here of my own function to be called on an edge detection?...not sure exactly the syntax/how to do it.
Cheers,
Statistics: Posted by cbw060 — Thu Oct 22, 2015 6:21 pm
]]>
Statistics: Posted by Kevin — Thu Oct 22, 2015 5:50 pm
]]>
I have loaded and re-loaded the Ringo Preloaded Behaviors sketch several times; I have initiated with button #1.
Ringo rotates a fixed right 90° and left 90° with the related arrow keys, as specified in the RotateAccurate(±90, 1000) code from the Behaviors tab.
Ringo moves forward and backward in two or three inch increments, as prescribed in the MoveWithOptions(0, 100, 200, 2000, 500, 0, 0) command in the code in the Behaviors tab. One press, one increment.
I want to have Ringo move forward continuously as long as the up arrow key is pressed, and then stop when released. Same for backward. And I'd like right and left rotation to be continuous as long as the arrow keys are held down, and then stop when the respective key is released [to achieve both < and > 90° rotation].
Are you getting what I want in your Ringo hardware/software?
My specs would seem to call for some 'If…then…' statements and some ways to produce continuous-conditional movement with the Motors( ) command and a way to terminate or break the Loop on release of the relevant button. I cant seem to get a handle on how to accomplish this and was hoping that a wise-head might help me out.
J
Statistics: Posted by jedward — Thu Oct 22, 2015 4:26 am
]]>
So, once you load this sketch, turn on Ringo, you just hit button #1, Led will flash, then you can drive it using the arrow keys.
Statistics: Posted by cbw060 — Thu Oct 22, 2015 12:22 am
]]>
I'd like to enable my grandsons to be able to drive the bot fluidly around in a pattern of their making using the arrow keys.
I imagine a variant of the Drive_WithRemote, except for the following changes:
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.
Thanks, John
Statistics: Posted by jedward — Sat Oct 17, 2015 10:48 pm
]]>
the difference between this code and mine is that yours is
1) uses the "pause" & "Resume" calls around the Delay call
2) after each turn, CalibrateNavigationSensors(); are called ZeroNavigation();
In the description of the Movewith Options and RotateAccurate function and the previous suggestions in this thread, I don't see any reason why it is necessary to Calibrate and Zero after each turn.
I've attached my ..._06 version, which basically replicates the same code as in the standard behaviour for square movement.
My observation:
I don't expect Ringo to be super accurate. I marked the position of his nose at start and after the end of each square and there is about 50mm variation after 4 runs. Also the "square" rotates , i.e. if I was plotting the track, the square would be slowly rotating to the right.
I did do the accelerometer calibration before I started all of this.
Let me turn it around and ask if it is possible to move predictably ( more or less) without having to call ZeroNavigation and CalibrateNavigationSensors?
New Question:
Have you done any testing with having Ringo move for a while then issue command to return to original X, Y ( i.e without having to ZeroNavigation?).
Statistics: Posted by cbw060 — Fri Oct 16, 2015 3:43 am
]]>
That does sound strange. Considering all the possible issues....
1) If there was a problem with the accelerometer or gyro going off line, the program would hang when it tried to query the sensor, so that tells me the sensors are running and giving data in the expected format. Whether that's accurate or not would be unknown though.
2) There could be something wrong internally to the sensors, though I've only ever found one unit in testing that went squirrly for no good reason. I never was able to solve the problem on that particular unit. Our production test has Ringo drive in a square 10 cm to a side. It goes around 3 times and needs to be pretty accurate to pass, so I would have expected to see a problem at that time if this were the case, so I doubt this. (Anything's possible though I guess).
3) I have seen the bot go much further than expected before. I believe this happens when the bot rocks forward, then as it moves away, it rocks to its rear pads. The upward (or downward) movement actually induces a component of forward/backward acceleration that is more than the acceleration from actually horizontal movement.
Does the robot rock front/back excessively? Sometimes the motors can be pushed out of the clip a bit which raises the bot up and would result in more rocking. They should be almost flush with the outer bottom edge of the clip. You should still get some rock, but not major rockage. If you need to adjust motors, don't press in on the shaft - press on the front face of the motor body. There's a page about this in the Motors section of the Ringo Guide.
One other thing to try, go download our latest pre-loaded example. It's rev 5. Try example 7 "Drive Square" and see what happens. I do see bots occasionally over-shoot in this example but it's usually fixed by pressing the motors up inside the holder a bit. This will at least rule out some random accidental change that may have happened in your own code.
I will run your examples on our bots tomorrow and see what happens.
Could you post a specific movement function example and ask more specific questions about how it works? I can probably answer better if I have a better idea of the question.
We'll get you worked out.
Thanks,
-Kevin
Statistics: Posted by Kevin — Fri Oct 16, 2015 1:30 am
]]>
Ringo will travel the 3 sides of a square, on the last side , i.e. after the 3rd right turn, the distance traveled in a single
"Forward" call will suddenly go to 3 or 4 times the expected ( i.e. dist = 170mm); then it will go back to "normal" and start over again.
As I let it cycle, the behaviour gets more and more erratic(turning in circle,etc), so I assume there is some inherent accumulating error or something that I need to be taking care of by some call??
Thanks for your patience.....
Statistics: Posted by cbw060 — Wed Oct 14, 2015 4:16 am
]]>
In order to keep these errors from building up over time, you may want to define a global variable
int Direction =0;
then replace my suggested change
RotateAccurate(PresentHeading()+90, 3000);
with 2 lines:
Direction=Direction+90;
RotateAccurate(Direction, 3000);
Statistics: Posted by DustinSoodak — Tue Oct 13, 2015 6:09 pm
]]>
RotateAccurate(90, 3000);
to
RotateAccurate(PresentHeading()+90, 3000);
In your first example, ZeroNavigation() is resetting PresentHeading() to 0 each time so you get the same result, though you sacrifice the ability to keep track of total rotation with PresentHeading().
Statistics: Posted by DustinSoodak — Tue Oct 13, 2015 5:44 pm
]]>
I've attached 2 code examples, in CBW_Turtle_3, I am using "ZeroNavigation" in the functions, which works. In CBW_Turtle_4 I am using the Pause/Resume calls as suggested in another posting. This cause Ringo to do a 180 turn at the 3rd command ( to turn Left90 degrees), then it spins and will either to the right or left, it is not consistent.
I want to understand why Turtle 4 is not working; in future I may want to move and keep track of X, Y positions as it moves. I understand that using ZeroNavigation will reset those values.
Can you see any reason why the Turtle 4 version does not give same movement as Turtle 3?
Statistics: Posted by cbw060 — Tue Oct 13, 2015 4:00 am
]]>