Build Localizer

[dfarrell07]

Localizer is currently just a stub. We need code that can use various forms of input (IR range sensors, encoders, ultrasonic sensors, anything else you can think of) to tell us which shooting block we are sitting on. I don't believe that Localizer should be more complex than that.

[JobenNC]

Do we have any information/documentation on the ultrasonic sensors you guys are currently in possession of? I checked the drive and the wiki, but I can't seem to come up with anything.

[dfarrell07]

The "Things to buy" (or 2013/"Shopping list") Docs are typically a good place to find equipment details. Here's the place we bought our ultrasonic sensors (x4) from. To confirm, I biked to the lab to take some pictures of them. They seem to match, as you can see.

[dfarrell07]

Actually, now that I'm not in a rush, it's pretty obvious that the US senor I linked to is not the one I photographed. The one in the photograph has four pins, the one behind the link has three. These US sensors, on the other hand, do seem to match. They are from the same spreadsheet (2013/"Shopping list"), I just needed to look down the page a bit more.

We may have some of both types of US sensors, I'll try to make it to the lab tomorrow to check (or someone else can).

[dfarrell07]

Can I get an update on this, @JobenNC? Have you been able to get data from the USs, and/or do you know how to do so? You many want to go ahead and take on issue #16, so you can assume the ultrasonic abstraction class works in Localizer, and then write your localization logic. Once we tie in actual US support, your code would work on the BBB.

[JobenNC]

Go ahead and give me #16. I just got a BBB in the mail and will be bringing it to Tuesday's meeting. That will probably be a nice opportunity for me to talk with some people who can help me begin investigating how the abstraction class will/should be implemented. We might be able to look into issue #15 as well. I have a very simple concept for how the localizer (abstracted above the hardware interface) might work, and I'll post some code/notes for review this weekend.

[dfarrell07]

...talk with some people who can help me begin investigating how the abstraction class will/should be implemented.

Yeah, we can definitely have a discussion about how the ultrasonic abstraction class can be implemented at Tuesday's meeting.

We might be able to look into issue #15 as well.

I will not be very helpful for this one, but I'd love to take part, as I'm quite interested in how we're going to get US data as well.

I have a very simple concept for how the localizer (abstracted above the hardware interface) might work, and I'll post some code/notes for review this weekend.

Looking forward to reviewing them. :smile:

[JobenNC]

Ok, the code I just posted makes a couple of assumptions:

1 - My understanding right now is that once the bot is over a firing position, it orients itself 'towards' the target. If the turret is meant to cover 360 degrees, and we aren't reorienting the bot, then this approach won't work.

2 - We're approaching the firing lines sequentially. I'm maintaining a list of discrete firing positions (defined by their distance from the 'right' wall) for each of the 3 lines.

So, as long as a consistent orientation can be assumed, and the line the bot is over is known, this approach should work.

The single SR04 will need two GPIO pins on the micro-controller.

This is the simplest possible implementation of a localizer I could come up with. It's obviously got some limitations. Let me know what you think!

[dfarrell07]

1 - My understanding right now is that once the bot is over a firing position, it orients itself 'towards' the target. If the turret is meant to cover 360 degrees, and we aren't reorienting the bot, then this approach won't work.

2 - We're approaching the firing lines sequentially.

These assumptions hold for all of the proposed strategies.

This is the simplest possible implementation of a localizer I could come up with.

A simple version is exactly what we should be shooting for. I think your proposed solution's scope is appropriate for the first iteration of localizer. It would get us interfacing with the US sensors and making decisions based on their data, which should give us good information about how well they will suit our purposes.

Keep up the good work!

[dfarrell07]

Based on my discussions with @PaladinEng at yesterday's meeting, I think he's going jump on this project as well. He's done with FSM planner for now, and this is a high-priority task that needs attention. @PaladinEng mentioned that he runs into you often, @JobenNC, but for the sake of everyone else, can you give us an overview of the current status of localizer, including features that are done and features that need to be done? Basically, I'm asking for a localizer brain dump, to help Alwyn get up to speed and to document it for the rest of us.

[PaladinEng]

Joe and I had a chance to discuss localizer, and it seems that the Python interpreter is slow enough that it is affecting the accuracy of the measurements. I'd like to get some input from other on the feasibility of alternate solutions. Is anyone interested in brainstorming with me? Having some advice from the electrical disciplines would really help me.

[dfarrell07]

I'd love to brainstorm with you, but I likely don't have the electrical expertise you're looking for. It might be a good start to give a bit more detailed explanation of the problem here, so that we can begin thinking about it.

[PaladinEng]

As I understand it, the python interpreter slows things down enough that the pulse width of the ultrasonics is too long for accurate measurements.

No have some questions & ideas, so it's not true brainstorming.

1) how do I verify the pulse width issue?

2) One possible solution is to write a program that does not compile at run-time via an interpreter, in C for example.

3) Another possible solution is to hand off management of the measurement to another micro controller, and have the BBB simply get position data.

So, specifically, I need help answering the first question and assessing the options, plus any other ideas are welcome.

Sent from my iPhone

On Oct 9, 2013, at 7:54 PM, Daniel Farrell notifications@github.com wrote:

I'd love to brainstorm with you, but I likely don't have the electrical expertise you're looking for. It might be a good start to give a bit more detailed explanation of the problem here, so that we can begin thinking about it.

— Reply to this email directly or view it on GitHub.

[dfarrell07]

1) how do I verify the pulse width issue?

Can you link us to the code in question? A simple suggestion is to print or log the time during each iteration of the loop, so you can check how fast it's running.

2) One possible solution is to write a program that does not compile at run-time via an interpreter, in C for example.

We can certainly do this, but I'd like to try giving an optimized Python solution a shot first. It would be interesting to write a version of this code in C and another in Python, then profile them both.

3) Another possible solution is to hand off management of the measurement to another micro controller, and have the BBB simply get position data.

@jfic is already doing this for the firing encoders, to avoid putting the load of counting very frequent ticks on the BBB. It seems like we could use that same board for the US pulses. On the other hand, I'd prefer to not split up the logic on to multiple boards if at all possible. We documented this multi-board setup as a mistake about last year's bot, as it caused a complex, difficult to maintain interface to develop between the boards. I'm not saying that we can't go down this route, but I do want us to approach it cautiously and be aware that we're treading on ground that has failed under us in the past.

As I understand it, the python interpreter slows things down enough that the pulse width of the ultrasonics is too long for accurate measurements.

I'm kind-of skeptical that Python is somehow too slow to handle this job. Can you give some more detail about the test you're running, your results, and why you came to this conclusion? As a stupid-simple test, I can get through at lest 50 loops in an ipython session, making a few lib calls in each loop, in less than a millisecond (I'm tempted to not even include this data because it's so non-representative, but I'll wait until I have more details about your test before trying to profile something more realistic).

In [15]: for i in range(0, 50):
    print int(round(time.time() * 1000))
   ....:     
1381368652813
1381368652813
1381368652813
# Same value for 50 prints

[dfarrell07]

Had a great conversation with @jschornick and @PaladinEng about this. Jeff's going to post to explain the details, but in short:

• The bone has Programmable Realtime Units (PRUs, two I think) that can run C or assembly code at a very low level, without dealing with the Linux scheduler. This is perfect for our US speed problems, since they are integrated into the bone, they run at 200Mhz, and they are cool tech that we should be excited to explore anyway. Alwyn has already volunteered to start learning about them, and will hopefully be giving us a report on his findings next Tuesday.
• We should consider moving from the file-like objects we use to get/set BBB hardware info, and instead directly use low-level registers and such. This buys us speed, and they are good changes to contribute to pybbb anyway (see #46).

[PaladinEng]

I found some really great explanations to get the PRU up and running. Looks like the most challenging bit is that there is no C compiler for the PRU, so everything has to be done in assembler.

I'll have a briefing ready for Tuesday.

Sent from my iPhone

On Oct 16, 2013, at 3:12 PM, Daniel Farrell notifications@github.com wrote:

Had a great conversation with @jschornick and @PaladinEng about this. Jeff's going to post to explain the details, but in short:

The bone has Programmable Realtime Units (PRUs, two I think) that can run C or assembly code at a very low level, without dealing with the Linux scheduler. This is perfect for our US speed problems, since they are integrated into the bone, they run at 200Mhz, and they are cool tech that we should be excited to explore anyway. Alwyn has already volunteered to learning about them, and will hopefully be giving us a report on his findings next Tuesday. We should consider moving from the file-like objects we use to get/set BBB hardware info, and instead directly use low-level registers and such. This buys us speed, and they are good changes to contribute to pybbb anyway (see #46). — Reply to this email directly or view it on GitHub.

[PaladinEng]

Here's the how-to on getting the PRU up and running: http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2

[napratin]

Here's something I've been thinking about: It'll be good if the localizer has easy access to the drive motors so that it can monitor encoder counts, as an additional source of information besides the US sensors. Since driver currently owns the motors (and I believe follower owns driver), we need all those components up in order to do any realistic localizer testing. Now, I don't know if this means we need any object ownership reorganization, or a start/server mode which starts this subset of components up.

[dfarrell07]

I pretty strongly discourage attempting to use the encoder counts in Localizer and its subclasses. Two reasons:

• Localizer's job is only to tell us which block we're over. Based on the ultrasonic testing @bjhoblit and I did, we should be able to get 3cm accuracy, which definitely seems like enough for that task. Attempting any more generic localization is scope creep.
• Watching the bot drive, it very much looks like there's a bunch of slip when driving sideways with the mecanum wheels. It seems very likely to me that encoder counts will have little value. Even with no slip, figuring out how to translate encoder counts into distances traveled when holonomic motion is possible seems like a nightmare.

[R00ney]

Hmmm. Encoder count is the speed the wheel turns. Speed times time is circumference. That circumference should be directly proportional to sideways movement.

What this proportion is will likely be easier to calculate by driving, measuring, and timing than by math.

[dfarrell07]

Wouldn't that proportion be different for various angles?

So for every angle a s/t 0 <= a < 90, the proportion at a, a + 90, a + 180 and a + 270 would be the equal, but for each a it would be different?

Doesn't this also assume constant slippage at any speed, which isn't realistic? So we would need the proportion for each of 90 values for a, for each speed 0 to 100?

[R00ney]

For all the angles a not 0 or 90, shouldn't the speed just be a vector of the forward speed and sideways speed?

As for slippage, I would image that slippage increases with speed of the wheels (ie 0.01% for speed 1, 1% for speed 99) but this can likely be approximated in a linear fashion. For example, go sideways at 25%, 50%, 75%, and 100% power. Find the measured distance/time = speed. I would hazard to guess that a line from point 50 to point 75 would leave point 25 above the line, and point 100 below the line. This is the proportional slippage in action. This is now a known measured deviation. Thus, when calculating sideways speed from the speed of the motors, it won't be sideways = k_wheelspeed, but instead sideways = (k + a(50 - wheel_speed)) * wheel_speed where a is the deviation amount

[dfarrell07]

A few things:

So for every angle a s/t 0 <= a < 90, the proportion at a, a + 90, a + 180 and a + 270 would be the equal, but for each a it would be different?

I realized this was formalized incorrectly while biking to the meeting (in the cold rain, boo!)

Should be more like 0 <= a < 180, a = a + 180, although I'm not putting too much thought into this given your post.

Regarding your explanation, I think I get what you're saying and it sounds plausible. However, two more things:

• I'm not optimistic that this would give us actionable results in practice. Not making a strong claim until we test it of course, but it's just hard to imagine this combination of measurements and math approximations giving us cm accuracy after driving a few meters.
• The much more important point: None of the encoder work is necessary if we can answer the question "which block am I on" using ultrasonics. If we had an abundance of dev resources I'd say that we should pursue both paths, but I don't think that's the case at the moment.

[dfarrell07]

After thinking about Localizer some more, and given what I now know about the targeting script, I'm not sure we even need one. The targeting script will take as input our position relative to the target and output the data needed by gunner, which was basically what we had in mind for Localizer (tell us which block we're on). Off-hand, I think adding a bit more logic to WheelGunner.auto_fire will do the trick. Instead of calling Localizer and looking up targeting data, it should call the US sensors and the work with the targeting script to get the turret's pitch and yaw.

[dfarrell07]

More and more convinced that we're not going to need a Localizer. I'll remove the Localizer code once I see gunner talking to the targeting script, but I'm going to go ahead and close this issue.