Replies to This Discussion

Permalink Reply by Michael Colton on August 19, 2012 at 10:00am

Hi, I'm having the same problem. It looks like on the APM1 that you used the 2560's ISP headers. But I read that on the APM2 there was some conflict with using those pins so you had to connect to the pins on the GPS shield. (Those connected to PJ0-2)

I opened up Eagle too, to see where those pins go on the APM2.5 and they are entirely too small to solder anything to. I guess that means we need to connect it somewhere else. I'm hoping that the conflict that existed on the APM2 has been resolved and we can just hook into the ISP pins again. But then, I thought the 2 and the 2.5 were software identical, maybe that's not the case.

Anyway, I really need to figure this out too!

Thanks!

• ▶ Reply

Permalink Reply by Jeff Smith on August 19, 2012 at 11:02am

Yah, from what I've gleaned in 6 hours of soldering, reading, schematics, ect. is that the Optical flow needs to be landed on the 3.3v side of the SPI voltage stepper ($U14) which only leaves board leveling soldering to make this work... Someone screwed the pooch on 2.5 or I'm missing something.

I'm working on landing the wires at the board level. I'll either have it working or be bricking an brand new never flown $180 component... not real happy right now :-/

• ▶ Reply

Permalink Reply by Michael Colton on August 19, 2012 at 11:16am

I'm away from my computer so I can't look, but your comment about being on the 3.3v side of a level shifter makes me wonder if we can add another shifter and solder to somewhere reasonable. I know that adding level shifting is going to be a pain for most people.

In my case, I'm gearing up for a mass produced product so adding some extra circuitry is no big deal but soldering to traces or tiny pads is unacceptable.

I'll look more in to it when I can. This is the first time I've played with the optical flow sensor so I need to get myself up to speed.

• ▶ Reply

Permalink Reply by Jeff Smith on August 19, 2012 at 3:29pm

well, I can tell you that landing the OF on the 3.3v side does not work for me. It garbles the MOSI line with ANY extra capacitance on the line... even my oscilloscope is enough to throw the gyro into loops viewing it in Mavlink.

I may have a bad component, but it works well without any extra wiring, makes me think there is something not engineered correctly?

I'm going to keep persuing it but I think the level converter might be the solution reguardless.

• ▶ Reply

Permalink Reply by Jeff Smith on August 19, 2012 at 6:29pm

Edit, got it to work :-)

Had to wire straight to the Data Flash, which it turns out is run on SPI. Took a little digging in the post's, guides, and Eagle files.

It's about the ugliest thing I've ever done to a board, but the proof is there. It initializes and tests good in the CLI.

P.s. there is a reference to TXI-3 and TXO-3 that are 2 of the circuits being used, but I cannot locate and TXx-3 on the board??? If you can locate where they are you may have the awnser to where the OF is *supposed* to go. I'll look a little more, hate what I have right now...

• ▶ Reply

Permalink Reply by Michael Colton on August 19, 2012 at 10:59pm

I see you posted on the main APM2.5 thread, I added some thoughts there as well. Basically asking if the ISP header would work with level shifting (maybe just a voltage divider to drop the MOSI down to 3.3, I imagine the atmega is fine with 3.3 on MISO) 

Also, it looks like UART2 is available (and can be run in SPI mode I think) 

Either way, I think a software modification to the Optical Flow library will be needed to reroute the SS line (maybe to one of the A pins) and the UART2 if we use that.

Hopefully I'll have some time over the next few days to try some of this out.

• ▶ Reply

Permalink Reply by Jeff Smith on August 19, 2012 at 11:35pm

Thanks Michael, I'm hoping that there is some fore-thought on this and it's not a pop up issue that needs hacking :-)

I've posted all over the place, usually I would try to keep my stuff more compact but this one seems like it would cover a lot of groups on different lots of different platforms...
That and I was hoping someone knew what to do before I tried the impossible (well, just barely possible I guess :-)

• ▶ Reply

Permalink Reply by Michael Colton on August 25, 2012 at 2:01pm

I think I have what we are looking for:

From http://code.google.com/p/arducopter/wiki/AC2_OptFlow before the APM2.5 came out:

Slightly anecdotal but I've managed to get the optical flow and MPU6000 to play well with each other if I attach the MISO pin of the optical flow sensor on the 3.3v side of the shifter.

I think the final solution is going to be one (or both of the following):

1. ) modify the APM2 so that the external SPI pins can be on the 3.3v side of the level shifter. This causes some problems because those same pins are used to load the bootloader onto the 2560 at the factory.

This does seem to be part of the APM2.5. That's the jumper on the bottom side of the board near the USB jack.

That suggests to me that the solution is to set that jumper to 3.3v (basically putting MISO on the other side of the level shifter) and then using the old (non APM2) library, except changed to put the Chip Select line at A3.

I'm trying to get it working right now, but I am not getting anything on my SCLK line of the SPI and I'm not yet sure why. I'm hopeful that once I figure out why that is happening, that we might be on our way.

• ▶ Reply

DeveloperPermalink Reply by Randy on August 25, 2012 at 5:30pm

Jeff, Michael,

     Thanks for the info above.  I'm planning to try to hitch up the optical flow to the 2.5 shortly to see how to make it work.  I hadn't noticed that "MISO LVL" jumper and that cannot be a coincidence.  So I expect that Michael is right on how it'll work.

     One gotcha with simply trying to use the old APM1 library is that we also modified the chip select pin between APM1 and APM2.  It was "PC3" on the APM1 but we moved it to "A3" for the APM2.  This was just because the position of the pins made it more conveninent to change between the models.

Permalink Reply by Jeff Smith on August 25, 2012 at 7:51pm

By all means try the jumper :-)

(posting in dual threads at this point, here and the Wiki...)

I did try landing the OF on the 3.3v side of the level shifter on the MPU-6000 side. It's a no go, as soon as you touch the SCLK line it all goes haywire. Just look at the horizon in the MP and watch what happens when you touch the SCLK with a test lead (not even hooked to the meter), the gyro drifts off and flips the horizon :-/

But, please look into it as I am certainly no expert in microprocessors or SPI :-)

• ▶ Reply

Permalink Reply by Michael Colton on August 25, 2012 at 11:33pm

The comment I found earlier about someone getting it to work, and that jumper there, make me think this is the way they had planned on it working (it's too soon to say whether it will...)

I've got the library and the test code modified now so that I can run the sensor on the SPI header (still using A3 as the Chip Select.) That works fine on it's own. I had to make a bunch of changes to the Arducopter to get it to try to use the modified code. I still don't think I have that right.

I'm about done for the day, at this point I am seeing the crazy horizon effect you described, but I'm not yet convinced that it's a sensitivity in the line because when I run the unmodified Arducopter code, with the OF sensor still attached, the horizon is nice and steady. I'm starting to suspect that there is a flaw in the Chip Select stuff. Maybe CS for the MPU-6000 isn't being turned off when OF reads take place, or visa-versa.

I left my good scope at work, so it's hard for me to get a closer look until later.

My thinking is that if the two parts can both be attached to the same bus and both work (but not yet at the same time) then I think that we'll be able to find a solution in software.

• ▶ Reply

Permalink Reply by Jeff Smith on August 26, 2012 at 7:09am

I think the problem is two fold on the ISP for the 6000/baro, first I do believe there is a hardware issue on the SCLK line, but I don't get exactly what is wrong so I could be off on that one.

Then also I think there is an issue of integrating with the slave select function as well, the OF sensor would need to be held to high impedance when the 6000/baro were called. So at the very least we would need to enable an SS to drive the OF sensor...

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page