Predictable Movement??

Ringo setup, hardware, basic programming. User to user support.
cbw060
Posts: 23
Joined: Wed Aug 26, 2015 6:21 pm

Predictable Movement??

Postby cbw060 » Tue Oct 13, 2015 4:00 am

I am back trying to get consistent, predictable movement to implement a simple "turtle-type" movement for my young grandson to do some simple maze navigation.

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?
Attachments
CBW_Ringo_turtle_03.zip
(38.15 KiB) Downloaded 104 times
CBW_Ringo_turtle_04.zip
(38.16 KiB) Downloaded 92 times

DustinSoodak
Posts: 6
Joined: Sat Aug 08, 2015 11:16 pm

Re: Predictable Movement??

Postby DustinSoodak » Tue Oct 13, 2015 5:44 pm

RotateAccurate() uses units of absolute degrees (not relative to present heading).
In your second example (turtle_04), try changing
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().

DustinSoodak
Posts: 6
Joined: Sat Aug 08, 2015 11:16 pm

Re: Predictable Movement??

Postby DustinSoodak » Tue Oct 13, 2015 6:09 pm

Unlike the "turtle" game, we are working with real-world components and surfaces that are not necessarily perfectly smooth. RotateAccurate(90,3000) will try to get you to exactly 90 degrees (as measured by PresentHeading()) but if it overshoots more than 3 times it will be satisfied with 89 or 91 degrees.

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);

cbw060
Posts: 23
Joined: Wed Aug 26, 2015 6:21 pm

Re: Predictable Movement??

Postby cbw060 » Wed Oct 14, 2015 4:16 am

I am not trying to beat a dead horse ( I hope) but trying to get some understanding of the fundamental movement functions.
I made the changes in the attached version "*_05".

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.....
Attachments
CBW_Ringo_turtle_05.zip
(38.03 KiB) Downloaded 68 times

Kevin
Posts: 181
Joined: Tue Jul 28, 2015 12:56 am

Re: Predictable Movement??

Postby Kevin » Fri Oct 16, 2015 1:30 am

cbw,

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

cbw060
Posts: 23
Joined: Wed Aug 26, 2015 6:21 pm

Re: Predictable Movement??

Postby cbw060 » Fri Oct 16, 2015 3:43 am

The version 5, behaviour button 7 (move in square) does work as expected.

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?).
Attachments
CBW_Ringo_turtle_06.zip
(38.07 KiB) Downloaded 69 times

jedward
Posts: 16
Joined: Sat Oct 17, 2015 9:57 pm

Re: Predictable Movement??

Postby jedward » Sat Oct 17, 2015 10:48 pm

cbw060
I am not sure if you are building a sketch for the same behavior I want to accomplish?

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

cbw060
Posts: 23
Joined: Wed Aug 26, 2015 6:21 pm

Re: Predictable Movement??

Postby cbw060 » Thu Oct 22, 2015 12:22 am

Jedward:
If you load the sketch from Plum Geek "RingoPreloaded Behavious Rev5, there is a behaviour that will allow you to drive it using the remote [button 1].

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.

jedward
Posts: 16
Joined: Sat Oct 17, 2015 9:57 pm

Re: Predictable Movement??

Postby jedward » Thu Oct 22, 2015 4:26 am

cbw060
I may have missed something important - certainly not the first time.

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

Kevin
Posts: 181
Joined: Tue Jul 28, 2015 12:56 am

Re: Predictable Movement??

Postby Kevin » Thu Oct 22, 2015 5:50 pm

cbw,

I'm sorry I haven't had a chance to test your code yet but I hope to get to that soon. I'll try to cover a few of your questions quick....

cbw060 wrote:The version 5, behaviour button 7 (move in square) does work as expected.

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();



The reason we're doing a full calibrate each time is because we assume someone may pick it up during a calibration and cause the sensors to be all crazy. We were using this behavior at a Maker Faire and wanted to make sure we could just trap the bug for a second then he would resume normal operation. So doing a full calibrate isn't necessary as long as he's perfectly still during the first calibrate.

The pause and resume.... The navigation sensors will overflow their buffer if a navigation function isn't called every 80 milliseconds (I think that's the time anyway). This won't harm anything, it just means future readings after an overflow may not be accurate. Calling the pause just pauses the nav sensors, then resumes them later. This is good practice if you're doing something that will take longer than 80 ms. "delay" just sits in one spot for a while so that's why we pause and resume.

cbw060 wrote: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.


When you mentioned doing the "accelerometer" calibration - did you mean the gyro calibration? There is a sketch you can run one time to calibrate your gyroscope permanently. (attached to this post) Each gyro is slightly different internally. This is why the square is rotating. See the sketch attached. If you've already done this, then do it again and adjust it slightly further. If you haven't played with this sketch yet, it will solve your rotating square problem. As you dial it in, it saves the gyro offset to the semi-permanent EEPROM on the processor and automatically uses it for gyro functions going forward.

cbw060 wrote:Let me turn it around and ask if it is possible to move predictably ( more or less) without having to call ZeroNavigation and CalibrateNavigationSensors?


This should be no problem. I understand what you're' trying to do and I don't think you're expecting Ringo to be too accurate. ZeroNavigation just resets where Ringo thinks he is sitting. Every movement just updates his x,y, and heading coordinates. ZeroNavigation just resets these.

The gyro tends to be really accurate, for rotations, but the accelerometer is less so. This is mainly because the acceleration due to movement is very small compared to the acceleration due to graivity, so the bit of rocking front and back along the way introduces a decent component of front/back acceleration. Normally when we test driving a meter or so he's pretty accurate.

I would suggest calling CalibrateNavigationSensors from time to time when you're sure he is still. Over a period of a few minutes you'll see the sensors start to drift so it doesn't hurt to cal them. Just don't do it when the bot may be moving.

cbw060 wrote: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?).


We have and it worked pretty well. Note that he will try to return his nose to where his nose started because that's where the accelerometer is.


I seem to remember you had a question about a specific function. Can you post a bit of code right in the post using the "Code" block at the top and ask there? I may be able to help more quickly and directly that way.

Thanks!
-Kevin
Attachments
Ringo_CalibrateGyroscope_Rev01.zip
(36.74 KiB) Downloaded 75 times


Who is online

Users browsing this forum: No registered users and 1 guest