Motion command details

[dfarrell07]

@R00ney raised some good points about the interaction between high-level nav code and low-level code that will receive the motion commands. This is actually great timing, as I was just getting to this part of nav's development.

Here are the questions @R00ney raised.

• Given that high level code tells @ealamaster's code a vector, with direction and distance, what is the protocol that distinguishes between turn-in-place turns and forward-arc turns?
• @ealamaster, you are working on acceleration code, to relatively-slowly increase to some max speed. Who sets that max speed, and are you automatically ramping down as you approach the end distance?
• Is there a method for overwriting the current motion vector before you necessarily complete that distance and/or heading?

He then proposed that arc turns may be better served by high-level passing very frequent heading and speed commands, resulting in left or left right arcs.

My first questions are for @ealamaster. What code have you implemented in this domain? What are your assumptions?

I'll provide more information on nav's perspective on these questions as I think though them.

[ealamaster]

I don't have an "arc-turn" command, at least not in the sense that you guys would want. My assumption is that movement would be broken down into straight lines and in-place turns, so if you want that functionality you should try @R00ney's suggestion first. If this is something that is particularly useful, I can try and add it in if I have time. You could make an arc by giving non-zero relative heading, speed, and distance setpoints, but it wouldn't be a "controlled" arc, and I wouldn't recommend it unless the relative heading is fairly small.

Acceleration will work by increasing the speed setpoint by some dSpeed every dTime until the target setpoint is reached. Deceleration would work in a similar way, although I don't know if we really need that as much. For deceleration, we would need to either predict a time or distance where we'd start slowing down. dSpeed could be a constant, or could be configurable over the serial interface.

Issuing the 'set' command (or the various aliases of 'set') will currently reset the controller. If by the third bullet you mean change the heading setpoint in the middle of a movement, we're already planning on doing that. Likewise, we could also do that with the speed and distance setpoints.

[R00ney]

If we have the high level arc turn, where the controller passes many vectors with small changes, we need the motor controller not to try to decelerate in that process, or it will throw the turn off.

How can we be sure it won't try to decelerate? A specific command, or simply giving long distances that you never reach?

Neal

On Wed, Mar 27, 2013 at 5:37 PM, ealamaster notifications@github.comwrote:

I don't have an "arc-turn" command, at least not in the sense that you guys would want. My assumption is that movement would be broken down into straight lines and in-place turns, so if you want that functionality you should try @R00ney https://github.com/R00ney's suggestion first. If this is something that is particularly useful, I can try and add it in if I have time. You could make an arc by giving non-zero relative heading, speed, and distance setpoints, but it wouldn't be a "controlled" arc, and I wouldn't recommend it unless the relative heading is fairly small.

Acceleration will work by increasing the speed setpoint by some dSpeed every dTime until the target setpoint is reached. Deceleration would work in a similar way, although I don't know if we really need that as much. For deceleration, we would need to either predict a time or distance where we'd start slowing down. dSpeed could be a constant, or could be configurable over the serial interface.

Issuing the 'set' command (or the various aliases of 'set') will currently reset the controller. If by the third bullet you mean change the heading setpoint in the middle of a movement, we're already planning on doing that. Likewise, we could also do that with the speed and distance setpoints.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15554766 .

[ealamaster]

We can add acceleration rate as a parameter for 'set', 0 to disable ramping.

[dfarrell07]

I'm not convinced that we need an arc turn. Does anyone have a compelling reason that we should work towards one before Friday? I think it would be more natural on my end to send rotate and straight commands. @R00ney, would it be very hard to remove arc turns from the mprims?

[R00ney]

So, during a high arc turn, disable all ramping?

Would that lead to wheel slippage on the start of the turn?

Neal

On Wed, Mar 27, 2013 at 5:43 PM, ealamaster notifications@github.comwrote:

We can add acceleration rate as a parameter for 'set', 0 to disable ramping.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15555056 .

[ealamaster]

If that's a concern, you could just use a large dSpeed value.

[R00ney]

Daniel,

before I mess around with removing things from the primitives, I'd like to know how the test primitives I create work for the motion planning.

That'll give me a better idea of what weights to change, ect.

Neal

On Wed, Mar 27, 2013 at 5:49 PM, ealamaster notifications@github.comwrote:

If that's a concern, you could just use a large dSpeed value.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15555318 .

[dfarrell07]

Okay, I'll make it a priority to get you some results in the next few hours, @R00ney.

[R00ney]

Any luck?

Neal

On Wed, Mar 27, 2013 at 6:07 PM, Daniel Farrell notifications@github.comwrote:

Okay, I'll make it a priority to get you some results in the next few hours, @R00ney https://github.com/R00ney.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15556306 .

[dfarrell07]

Having to get more done than I expected. Still working on it.

[dfarrell07]

Okay, an example solution and environment file, along with the mprim file I used (one of the ones you provided), are in the mprim_test0 tarball in the Drive folder. I seems that Gists couldn't handle my 3.5MB environment file, lol.

The movement, as you'll be able to see, was from (x=1, y=1, theta=0) to (x=2, y=2, theta=0) (units are feet). Now that I've got this code build, I can easily generate more files between any two arbitrary points.

[dfarrell07]

If you have some request start and goal poses, just let me know. I doubt my code will run on Windows, so unless you're using a Linux box that I don't know about @R00ney, I'll have to build them for you (no problem).

[R00ney]

If you are still up, and plan to work, would you like to try a google hangout to talk about desired changes to the primitives?

Neal

On Thu, Mar 28, 2013 at 12:11 AM, Daniel Farrell notifications@github.comwrote:

If you have some request start and goal poses, just let me know. I doubt my code will run on Windows, so unless you're using a Linux box that I don't know about @R00ney https://github.com/R00ney, I'll have to build them for you (no problem).

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15567438 .

[R00ney]

The result looks nice as far as I can tell, but I don't know much about it. Is this the type of result you want?

I am looking specifically for anything that you would like to change to make the motion planning better.

I can change the weights on the turn in place, so that the planner prefers to use those over arc turns. Removing arc turns completely is quite involved, so if the other works we can stick with that.

Also, I can changes the number of discrete steps in each primitive, if that helps the planner at all.

Let me know, and I can make them.

Neal

On Thu, Mar 28, 2013 at 12:40 AM, Neal O'Hara ngo1991@gmail.com wrote:

If you are still up, and plan to work, would you like to try a google hangout to talk about desired changes to the primitives?

Neal

On Thu, Mar 28, 2013 at 12:11 AM, Daniel Farrell <notifications@github.com

wrote:

If you have some request start and goal poses, just let me know. I doubt my code will run on Windows, so unless you're using a Linux box that I don't know about @R00ney https://github.com/R00ney, I'll have to build them for you (no problem).

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15567438 .

[dfarrell07]

Since we don't seem to be planning on doing arc turns, let's try to either weight them to be nearly impossible or remove them. Generating one, without being able to accommodate it, would clearly be problematic.

Try to generate a range of mprims with different numbers of discrete steps, for each of the different resolutions. One of the tests that I'd like to write will test how long it takes to run various start->goal plans with different resolutions and mprim files.

[R00ney]

Alright, then in the morning I plan to make new mprims with priority on turn-in-place for

1/16, 1/8, 1/4, 1/2 inches

each with

3 5 10 20 40 steps for each primitive.

This sound ok?

BTW, this only takes however long it takes to runt the code 20 times, basically enter 16 times times 20 = 320 or so button presses.

Neal

On Thu, Mar 28, 2013 at 1:24 AM, Daniel Farrell notifications@github.comwrote:

Since we don't seem to be planning on doing arc turns, let's try to either weight them to be nearly impossible or remove them. Generating one, without being able to accommodate it, would clearly be problematic.

Try to generate a range of mprims with different numbers of discrete steps, for each of the different resolutions. One of the tests that I'd like to write will test how long it takes to run various start->goal plans with different resolutions and mprim files.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15569370 .

[R00ney]

Also, Ethan and I should be in the lab by 11:30ish, feel free to join us.

Neal

On Thu, Mar 28, 2013 at 1:36 AM, Neal O'Hara ngo1991@gmail.com wrote:

Alright, then in the morning I plan to make new mprims with priority on turn-in-place for

1/16, 1/8, 1/4, 1/2 inches

each with

3 5 10 20 40 steps for each primitive.

This sound ok?

BTW, this only takes however long it takes to runt the code 20 times, basically enter 16 times times 20 = 320 or so button presses.

Neal

On Thu, Mar 28, 2013 at 1:24 AM, Daniel Farrell notifications@github.comwrote:

Since we don't seem to be planning on doing arc turns, let's try to either weight them to be nearly impossible or remove them. Generating one, without being able to accommodate it, would clearly be problematic.

Try to generate a range of mprims with different numbers of discrete steps, for each of the different resolutions. One of the tests that I'd like to write will test how long it takes to run various start->goal plans with different resolutions and mprim files.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15569370 .

[dfarrell07]

Okay, sounds good to me. If I have time tonight, I'll get started on tests to use them.

[R00ney]

The new primitives are now in the google drive, under Mutli_Primitives_test.zip

Neal

On Thu, Mar 28, 2013 at 2:16 AM, Daniel Farrell notifications@github.comwrote:

Okay, sounds good to me. If I have time tonight, I'll get started on tests to use them.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15570382 .

[dfarrell07]

I'm kicking myself for not noticing this earlier, but @R00ney, in the mprim files the resolution_m variables on the first line of all of them are in meters, not inches (all SBPL and nav code uses/should use meters). Here are the resolutions defined in the first set of mprim files you gave me. Comparing the file names and the resolution variables, it's clear that they are in inches.

./prim_16thinch_16turns:1:resolution_m: 0.062500
./prim_16thinch_16turns_with_tip:1:resolution_m: 0.062500
./prim_2thinch_16turns:1:resolution_m: 0.500000
./prim_2thinch_16turns_with_tip:1:resolution_m: 0.500000
./prim_4thinch_16turns:1:resolution_m: 0.250000
./prim_4thinch_16turns_with_tip:1:resolution_m: 0.250000
./prim_8thinch_16turns:1:resolution_m: 0.125000
./prim_8thinch_16turns_with_tip:1:resolution_m: 0.125000

Sorry about the confusion! Any way you can generate a few in meters, even if you don't have time to do the full set again? I'm not ready for the full set anyway.

[R00ney]

Daniel, I said inches in the file name, however the primitives are just scalar.

The numbers only mean what you need them to mean.

So, the resolution is in 1/16th meter, 1/8th meter, ect.

I can generate them in terms of 10, if you prefer.

Neal

On Thu, Mar 28, 2013 at 5:59 PM, Daniel Farrell notifications@github.comwrote:

I'm kicking myself for not noticing this earlier, but @R00neyhttps://github.com/R00ney, in the mprim files the resolution_m variables on the first line of all of them are in meters, not inches (all SBPL and nav code uses/should use meters). Here are the resolutions defined in the first set of mprim files you gave me. Comparing the file names and the resolution variables, it's clear that they are in inches.

./prim_16thinch_16turns:1:resolution_m: 0.062500 ./prim_16thinch_16turns_with_tip:1:resolution_m: 0.062500 ./prim_2thinch_16turns:1:resolution_m: 0.500000 ./prim_2thinch_16turns_with_tip:1:resolution_m: 0.500000 ./prim_4thinch_16turns:1:resolution_m: 0.250000 ./prim_4thinch_16turns_with_tip:1:resolution_m: 0.250000 ./prim_8thinch_16turns:1:resolution_m: 0.125000 ./prim_8thinch_16turns_with_tip:1:resolution_m: 0.125000

Sorry about the confusion! Any way you can generate a few in meters, even if you don't have time to do the full set again? I'm not ready for the full set anyway.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15617938 .

[dfarrell07]

The resolution value in the environment configuration file is required to be the same as the resolution value in the mprim file, and the resolution in the env file is required to be in meters, so the resolution of the mprim files is required to be in meters.

In other words, when telling SBPL about the environment, it wants to know the cell size of the map in meters, and it wants the motion primitive files to be on that same scale.

[dfarrell07]

Here are the resolution values to use:

1/16 inch in meters = 0.0015875 1/8 inch in meters = 0.003175 1/4 inch in meters = 0.00635 1/2 inch in meters = 0.0127

[R00ney]

See Inch_in_meters_primitives.zip in google drive for new primitives.

Naming scheme is _16thinch is resolution in 0.0015875, and _step3 is 3 discrete steps in each primitive.

Neal

On Thu, Mar 28, 2013 at 7:32 PM, Daniel Farrell notifications@github.comwrote:

Here are the resolution values to use:

1/16 inch in meters = 0.0015875 1/8 inch in meters = 0.003175 1/4 inch in meters = 0.00635 1/2 inch in meters = 0.0127

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15621635 .

[dfarrell07]

@R00ney, I think your script for generating these mprims may have a bug. Notice that the name of the file suggests a different resolution than the file actually contains. Not a big deal, I'll just ignore the file names for now.

./prim_tip_priority_1.574803e+002inch_step10:1:resolution_m: 0.006350
./prim_tip_priority_1.574803e+002inch_step20:1:resolution_m: 0.006350
./prim_tip_priority_1.574803e+002inch_step3:1:resolution_m: 0.006350
./prim_tip_priority_1.574803e+002inch_step40:1:resolution_m: 0.006350
./prim_tip_priority_1.574803e+002inch_step5:1:resolution_m: 0.006350
./prim_tip_priority_3.149606e+002inch_step10:1:resolution_m: 0.003175
./prim_tip_priority_3.149606e+002inch_step20:1:resolution_m: 0.003175
./prim_tip_priority_3.149606e+002inch_step3:1:resolution_m: 0.003175
./prim_tip_priority_3.149606e+002inch_step40:1:resolution_m: 0.003175
./prim_tip_priority_3.149606e+002inch_step5:1:resolution_m: 0.003175
./prim_tip_priority_6.299213e+002inch_step10:1:resolution_m: 0.001587
./prim_tip_priority_6.299213e+002inch_step20:1:resolution_m: 0.001587
./prim_tip_priority_6.299213e+002inch_step3:1:resolution_m: 0.001587
./prim_tip_priority_6.299213e+002inch_step40:1:resolution_m: 0.001587
./prim_tip_priority_6.299213e+002inch_step5:1:resolution_m: 0.001587
./prim_tip_priority_7.874016e+001inch_step10:1:resolution_m: 0.012700
./prim_tip_priority_7.874016e+001inch_step20:1:resolution_m: 0.012700
./prim_tip_priority_7.874016e+001inch_step3:1:resolution_m: 0.012700
./prim_tip_priority_7.874016e+001inch_step40:1:resolution_m: 0.012700
./prim_tip_priority_7.874016e+001inch_step5:1:resolution_m: 0.012700

[dfarrell07]

Here's a test result that would be interesting to see the visualization for. It's from the start waypoint to the air waypoint using 1/16 inch cells and 5 steps per mprim.

[R00ney]

Ok, I fixed the naming bug, and can give you the new ones if you really want them.

Is this test result the output we want? I see it gets there eventually, but wouldn't a sharper angle be more optimal?

Is that something I can can/should change on the mprim side?

Neal

On Fri, Mar 29, 2013 at 3:55 AM, Daniel Farrell notifications@github.comwrote:

Here's a test resulthttps://docs.google.com/file/d/0B_7IPKiQjuIZSzNSLWJnR2gtbFk/edit?usp=sharingthat would be interesting to see the visualization for. It's from the start waypoint to the air waypoint using 1/16 inch cells and 5 steps per mprim.

— Reply to this email directly or view it on GitHubhttps://github.com/NCSUhardware/high-level/issues/16#issuecomment-15631911 .

[R00ney]

@dfarrell07 The new motion primitives (16th - 2th, and step 2, 5, 10, 20, 40) with correct file name and 10 decimal places on all floating point numbers are now in the drive, under mprims_with_variable_res_and_step

[R00ney]

I finished modifying the Matlab solution display. Take a look at this sweet output.

[dfarrell07]

Holy shit that's an awesome visualization, @R00ney. Great job!

[R00ney]

I just uploaded the new plot_3Dpath.m to google drive, so anyone with matlab can get a visualization of the solution files produced. Of course, if you don't have Matlab just give me a text and we'll set up a google hangout so you can see them in real time.

[dfarrell07]

Since we don't have any more specific issues in this regard right now, I'm going to close this. We can open another one about any specific issue we encounter in the future.