Why don't we just switch to ArduRover??

[Michael Shimniok]

Have you started thinking about / working on your AVC entry?

Are you going to use APM:Rover (ArduRover) ?

If you already have code like me, why not switch?

APM:Rover has a lot to offer. You get MAVlink telemetry. You get one (or
more?) Ground Control Stations making it easy to configure, monitor,
etc. wirelessly. I think you get Hardware-In-Loop and Software-In-Loop
testing ? Lots of support. Probably a bunch of stuff I'm forgetting.

[Wayne Holder]

Yes, but what's the fun in that?

For me, the whole point of the AVC is not to compete against others (although that's fun, too), it's to have a reason to experiment with and learn new things.

Wayne

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/528D020F.3010708%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ted Meyers]

Yeah, it may be interesting to try ArduRover, just to see what it does (and I'm sure it is a great starting point), but I totally agree with Wayne; I really want to roll my own stuff.  If I were just interested in winning, I would take a completely different approach (and _probably_ do a lot better).  I think that approach is obvious to anyone who has attended the AVC -- spend a chunk of money on some key components and you'll do well.  Not that I have anything against those who have the big buck bots, I think they are awesome -- I'm just not interested in going that route (well, I may get a LIDAR system some day...).

Ted

[Ted Meyers]

Yeah, so what am I working on?  The past month I've been very carefully building an odometry system.  I like odometers because their are no invisible fields (magnetic or RF) and I can in theory see everything that is going on.  So far, distance is great, but direction is still not where I'd like it to be.  I'm currently rebuilding my suspension system to shore up my wheel base.  I have a few more things to test: a wheel encoder trailer and optical mouse based odometry.

After that I'd like to do some testing on gyros and magnetometers and compare them all.  If I don't need it, I will probably dump GPS altogether -- I have not yet been able to get satisfactory results from it.

Another ongoing project is building a controller (for a ground station).

Ted

[Jon Watte]

You get one (or more?) Ground Control Stations making it easy to configure, monitor, etc. wirelessly

I believe those are not allowed during the AVC competition, but for testing, it's great to have remote telemetry and instrumentation!

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/257e58f8-2b74-4abb-a383-9d1298285d9a%40googlegroups.com.

[Jon Russell]

Yes. I agree. If I actually wanted to win is buy an off the shelf solution. :-) For me this is about building something myself and learning how to do it. The AVC is just a deadline to do it by rather than the reason for doing it. :-)

[Linus Penzlien]

Hi,


im actually using APMrover2 because programming my own is no option with
my current programming skills :)


Regards,
Linus

[Ted Meyers]

Hey Linus, I'm glad to hear that using APMrover2 allows you to participate, that's great!  Some of us have different skill sets than others!  Me, I'm a lot better at the software side than the hardware.

On another topic -- I hate snow, it really interferes with rover testing ;)   One of these days, I'm going to have to make a "winter rover" (with tracks maybe).  Reminds me of the first AVC that I went to, when it was snowing in Boulder!

Ted

[jesse brockmann]

It is great to have people with different skill sets. :)    I think the point of the question is...    APM:Rover has proven to be a good solution.   But like some people have said, we want something different... better.      So, do you start from APM:Rover, or start from scratch?   Who is willing to help contribute to a new base designed for the tinker from the ground up?   What do you have now?  Are you willing to share?

My plan is to use an indoor bot for the winter.  A smaller Slash 1/16th scale truck allows me to do testing indoors without taking out walls, etc.   I've geared mine down, so it runs very slow in a predictable manner.   Stock it was designed for speed.  Now, I can crawl along barely moving in controllable way.      I'd bet running slower is actually harder!   Traxxas has now released sensors for hardware for RPM monitoring.  So, I have a decent encoder without having to engineer my own mount, etc.    GPS isn't going to be of much use indoors.  But it gives me a chance to focus on the other sensors, and get a best possible solution without them.  Maybe so good I determine I don't need GPS?

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/6c18af01-7bbe-404a-addc-3a1b44a1aa9d%40googlegroups.com.

[Linus]

Hi Ted,

i most enjoy the learning, fun while tinkering and getting in contact
with great people.
But it takes more than just the code as you all probably know to compete
with the diy-elite at AVC 2014 :)

Maybe a Hover-Rover so you can drive the lake in Boulder ;)

Linus

[Michael Shimniok]

On 11/20/2013 11:59 AM, Wayne Holder wrote:

Yes, but what's the fun in that?

For me, the whole point of the AVC is not to compete against others (although that's fun, too), it's to have a reason to experiment with and learn new things.

Agreed.

So.... How much time did each of you get to spend on the interesting algorithms? Versus this stuff... :)

- Drivers for sensors
- Drivers for control
- Logging
- Log parsing/playback (desktop)
- Filesystem
- Telemetry
- Navigation, path following, waypoints
- Mapping / route planning (desktop)
- Simulation

What if you had all the above taken care of and it was better than you could accomplish in a short time?

I reused where I could but had to write a lot from scratch. I spent enough time that Nov '10 thru Apr '11, I hardly spent any time on the estimation!

So what's the reason for my questions?  Jesse and I are planning to fork APM:Rover2, port it to other platforms, and make it more hackable.

Hardware platforms could include:
- Teensy 3.0,
- mbed LPC1768 (or others),
- LPCXpresso LPC1769,
- chipKit MAX32,
- STM32F4 Discovery, and others.

So... would you entertain joining us in this adventure? 

What concerns come to mind?

My initial concern was, I have 20k lines of code, most of which I'd have to throw away.  Then again it's not much of a loss as long as I can get the interesting algorithms incorporated and play with them. And doing so, I gain all this other stuff mentioned before. Like this:



Another concern yet to be determined is whether I'll get enough log detail to troubleshoot. We can fix that easily enough if it's a problem (which it probably isn't).

How hard is porting? I think it's just a matter of writing a HAL module for your board. I'll know more soon.

Michael

On Wed, Nov 20, 2013 at 10:40 AM, Michael Shimniok <shim...@gmail.com> wrote:

Have you started thinking about / working on your AVC entry?

Are you going to use APM:Rover (ArduRover) ?

If you already have code like me, why not switch?

APM:Rover has a lot to offer. You get MAVlink telemetry. You get one (or more?) Ground Control Stations making it easy to configure, monitor, etc. wirelessly. I think you get Hardware-In-Loop and Software-In-Loop testing ? Lots of support. Probably a bunch of stuff I'm forgetting.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/528D020F.3010708%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAB%2BjonDKauVj6ejwW3m9ytAxTfo0RqsZKtToJDhN4LDR62CLjA%40mail.gmail.com.

[Ted Meyers]

Okay Michael, you make some very good points.  I'm in.  Let's try to get this thing ported.  I will probably focus first on getting it running on a Teensy 3.0, as that is currently my favorite (shouldn't be that hard, the Teensy is very arduino compatible).  But first I need to figure out what this ArduRover thing is.

And beware that I am easily distracted by new projects =)

But you probably already know that.

Ted

[Michael Shimniok]

I'll even make you a rover baseboard like the one we are using for lpcxpresso if you want. 

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/a24c486d-23d6-411e-aea5-5b9f7146719b%40googlegroups.com.

[Joe Dvorak]

I've been looking around for a good base to build a ground vehicle autonomous system from and came across APM also. I've decided that is probably the best way to start for all the reasons mentioned above by others. Here is some info I've come across:

The APM code has actually already been ported away from the Arduino platform. See the release notes for 2.43: http://diydrones.com/group/ardurover-user-group/forum/topics/apmrover2-2-43-released. The latest suggested platform is the Pixhawk which is based on an ARM Cortex-M4 and runs a real-time operating system. I ordered a Pixhawk, but it still hasn't come in and apparently won't for several more weeks so I don't know how the system is set up with APM and the real-time OS. It has to be a very different model from base Arduino though.

I just wanted to point out that this port had been done since if you are looking at moving to a Cortex-M3 like the LPC1769, it should be similar to the Cortex-M4 that is in the official version.

Joe

[Tom Coyle]

@Joe,

 

I am already running the ArduRover2 v2.43 PX4 code on my PX4 FMU/IO equipped Traxxas 1/16 Fiesta Rally chassis. So far I have just used it in the Manual mode, but if it quits raining here in Florida, I plan to run it in the Auto Mode over a waypoint course as soon as I can.

 

Regards,

Tom C ArduRover2 Developer

[Michael Shimniok]

I forgot to say...

You may wonder what is the point of building my own hardware?

It's to allow flexible choices for sensors. I intend the platform to be
easy to choose different devices. RoverBaseboard has no sensors on it,
just ports for I2C, Serial, Analog, Digital.

It's sort of like how PCs are flexible versus circa 1987 all-in-one Mac
where you're locked into *all* the hardware.

Want to add an encoder? Two? Four. Ok. Want an LSM303DLH, DLM, HMC4853,
something else? Ok. How about a Venus GPS? uBlox6? 7? SirfIII? All fine.
MinIMU9? Sparkfun 5DOF? MPU6xxx ? Ok.

On 11/22/2013 09:00 AM, Joe Dvorak wrote:
> The APM code has actually already been ported away from the Arduino
> platform. See the release notes for 2.43:
> http://diydrones.com/group/ardurover-user-group/forum/topics/apmrover2-2-43-released.
> The latest suggested platform is the Pixhawk which is based on an ARM
> Cortex-M4 and runs a real-time operating system. I ordered a Pixhawk,
> but it still hasn't come in and apparently won't for several more
> weeks so I don't know how the system is set up with APM and the
> real-time OS. It has to be a very different model from base Arduino
> though.

I'm really curious to learn more about that. Perhaps Tom and you can
shed light on this. Ideally I'd like to run with an RTOS so will look at
what the PX4 code looks like.

> I just wanted to point out that this port had been done since if you
> are looking at moving to a Cortex-M3 like the LPC1769, it should be
> similar to the Cortex-M4 that is in the official version.

Thanks. I think you're right that a lot of the work has been done. I
know with CMSIS and common ARM core there's some similarities, but I
understand the peripherals are a bit different across companies. STM has
a standard peripheral driver library. I'm not sure what NXP has. I'm
still trying to crack that nut on the LPC Cortex devices. Mostly I've
just used the mbed SDK which is infinitely simpler to deal with than
LPCXpresso and CMSIS.

Ultimately we'll probably stick a beefy STM32F3 or F4 on the baseboard.
Then again, maybe we decide to use the 3-core NXP LPC4370 with an M4/FPU
and TWO M0's onboard. >:)
http://www.nxp.com/products/microcontrollers/cortex_m4/LPC4370FET100.html

Michael

[Jon Watte]

Another nice board at the Cortex-M3 level is the OpenCM9.04. Its most amazing feature: It's only $10!

And while it doesn't have hardware floating point, it can still do almost a thousand full IK solutions for my four-legged walker per second, which is more than I need :-)

The board uses the STM32F3.

The F4 / M4 level is nice, with its FPU, I have to admit, if you have a need to use it. But, if you have those needs, the step up to the gigahertz/multi-core/linux based boards really isn't that far... and then you lose the real-time microsecond timing. I think that the "two computers" solution of something beefy, and something real-time, is a pattern that will stay with us for a long time.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/528F9011.5080203%40gmail.com.

[Michael Shimniok]

On 11/22/2013 12:33 PM, Jon Watte wrote:

Another nice board at the Cortex-M3 level is the OpenCM9.04. Its most amazing feature: It's only $10!

And while it doesn't have hardware floating point, it can still do almost a thousand full IK solutions for my four-legged walker per second, which is more than I need :-)

Good tip! You've mentioned that one before. I'll take a look. Any interest in joining our little adventure?

The board uses the STM32F3.

I thought all the F3's were M4 with hardware DSP/FPU on board. ( http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1576)

What options are well used for IDE/toolchain?

Michael

[Thomas Roell]

On Friday, November 22, 2013 12:33:03 PM UTC-7, Jon Watte wrote:

Another nice board at the Cortex-M3 level is the OpenCM9.04. Its most amazing feature: It's only $10!

And while it doesn't have hardware floating point, it can still do almost a thousand full IK solutions for my four-legged walker per second, which is more than I need :-)

The board uses the STM32F3.

The F4 / M4 level is nice, with its FPU, I have to admit, if you have a need to use it. But, if you have those needs, the step up to the gigahertz/multi-core/linux based boards really isn't that far... and then you lose the real-time microsecond timing. I think that the "two computers" solution of something beefy, and something real-time, is a pattern that will stay with us for a long time.

Sincerely,

jw

The STM32F3 has a bunch of oddities. Only half it's pins are 5V tolerant, there is only one timer block with 32bit counters ... OpenCM9.04 however is a STM32F103, which is a Cortex-M3.

- Thomas

[Jon Watte]

OpenCM9.04 however is a STM32F103

Oops, my mistake -- I knew there was a 3 at the end :-)

Robotis has a franken-IDE that combines the Maple runtime with the Arduino IDE and GCC-for-ARM (some old version -- 4.5 I think,) and lets you build and upload programs quite easily over the USB port.

They call it simply "CM9" and is downloadable for all three platforms (Windows, Mac, Linux.)

The main annoyance is that the "bootloader" part is about 12 kB. On the previous 64k boards, that hurt; on the newer 128k boards that's not as bad.

Also, the Maple-based support libraries are hit-or-miss in quality. Some bits are great!

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/ea5cf2c0-f7af-4091-b72e-af5cac5f4dba%40googlegroups.com.

[JP B]

APM:Rover is a great template, but had I used it completely or as a major base I would not really understand how things actually worked.  My own rover code is nowhere near as sophisticated as APM:Rover, but for my needs it doesn't need to be - I understand it, I have full developmental control now and going forward, and the satisfaction from seeing my own creation work is the best bit.

I am however really grateful there is a great reference in the standard, for ideas, code and inspiration.

[Ted Meyers]

Yes, I've been looking at the APM:Rover code and it is very sophisticated (I'm surprised that it fits on an arduino -- there's a LOT of code there!).  I've already found some things that I want to borrow from their code.

Ted

[Michael Shimniok]

On 11/25/2013 05:01 PM, Ted Meyers wrote:

Yes, I've been looking at the APM:Rover code and it is very sophisticated (I'm surprised that it fits on an arduino -- there's a LOT of code there!).  I've already found some things that I want to borrow from their code.

~80k lines of code. Ack! Of course some of those lines are hardware abstraction layers for various platforms so you'd only get one set of those but still.

It looks doable to port the thing to Teensy or to LPCXpresso or mbed (or really anything). I've been trying to understand the basics of how things go together and the key routines.

We're currently working on getting familar with the LPCXpresso tools. We have a git repo here: https://github.com/shimniok/diyrovers

On the Teensy I can go one of two ways, either an adapter board that adapts Teensy to LPCXpresso/mbed pinout, or a RoverBaseboard dedicated to Teensy 3.0.

My own code is a mere 20k lines (which I thought was huge). It's much simpler. No telemetry, no on-the-fly configuration, no "modes" of operation, just autonomous and stopped. :)  It uses a unix-y sort of shell to find and download logfiles. Simple text file configuration. Definitely learned a lot and felt pretty happy about having my own from-scratch code on the robot.

Michael

[Tim Myrtle]

Michael, you've convinced me.  I'd like to help out with this.

Looks like you have decided on the LPCXpresso.  Any particular reason for choosing it?  It does look interesting.

With the APM:Rover already running on STM32, seems like a Discovery board (or similar) would be the easiest choice.   You might be able to skip the whole porting exercise completely and move directly to baseboard development and higher level stuff.

-Tim

[JP B]

I say this from a purely ignorant point of view - interested in benefits any other hardware platform may offer over the forthcoming 3DR pixhawk platform, which I can see the community taking forward with new software features whilst fixing the offering able to run on current APM hardware.  Looking ahead, going with the pixhawk which will attract an existing developer base is an attraction.

[Michael Shimniok]

On 11/26/2013 11:18 AM, Tim Myrtle wrote:
> Michael, you've convinced me. I'd like to help out with this.

Sweet! Glad to have you.

> Looks like you have decided on the LPCXpresso. Any particular reason
> for choosing it? It does look interesting.

We kind of got here roundabout. I had originally wanted to stick with my
original mbed code. The path to LPCXpresso was shortest. Then Jesse
(finally) convinced me that starting with APM:Rover2 made sense. So here
we are.

We're not really married ot it. It's more of a path to somewhere else.

I already have a few baseboards built.

Ted is going to use a Teensy 3.0 which has an Arduinoish IDE / SDK.

> With the APM:Rover already running on STM32, seems like a Discovery
> board (or similar) would be the easiest choice. You might be able to
> skip the whole porting exercise completely and move directly to
> baseboard development and higher level stuff.

Tim, that's a very good point. Were you already planning on running
STM32F4 Discovery?

Michael

[Thomas Roell]

Being the newbie here ... Pixhawk does not seem to be cost effective. For $199 you get A Gyro/Accel/Compare system with a Cortex-M4 (the rest is not that useful for rovers). That is about the same as you get off the STM32F303 Discovery board, or the newer STM32F401 Discovery board (each less than $15).  

[Michael Shimniok]

Cost, Experimentation, and targeting at Rovers instead of planes.

Theirs: $200, my baseboard will be less.

The whole point of this porting project is flexibility so you can
experiment.

PIck your own sensors, mount them wherever you want, try different
sensors, experiment. Multiple UARTs, multiple I2C,

You don't need a barometer on a car. You might need wheel encoders... etc...

Michael

[Tim Myrtle]

No, I've been using Teensy3 and FreeRTOS for the last few months.   The Teensy is great, but if I'm going move to APM:Rover and throw out my code, I'm open to considering other platforms.

I also wouldn't mind stepping up to something with JTAG/gdb.

[Jon Watte]

One peripheral that would be great, would be quadrature decoders. Ideally four of them, one for each wheel!

Is there any simple ARM board that has those?

If not, does anyone know of a good I2C or SPI based part? (If it were available in DIP that'd be heaven.)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f393b214-cd90-4396-b742-a7a2594c2471%40googlegroups.com.

[Michael Shimniok]

On 11/26/2013 02:10 PM, Jon Watte wrote:
> One peripheral that would be great, would be quadrature decoders.
> Ideally four of them, one for each wheel!
> Is there any simple ARM board that has those?

FWIW, RoverBaseboard has ports for 4 encoder channels, either 4
incremental encoders or dual quadrature, however you want to code it.
And it has multiple GPIO broken out, too, for additional inputs. I
believe the LPC176x series has a single quadrature encoder peripheral,
so not all that helpful. I don't know what's available on STM32F4, etc.
... anyone? I just counted pulses with external pin interrupts on the mbed.

> If not, does anyone know of a good I2C or SPI based part? (If it were
> available in DIP that'd be heaven.)

In fact, I'm thinking about making one.

Back of the napkin sketch -- thinking it'd be ATtiny84A-based (14-SOIC),
small, cheap, and it'd run SPI or I2C or Serial, your choice. And
programmable with Arduino or bare metal AVR. I'd run it at 16 or 20MHz
but I'd have to run numbers to figure out exactly how fast it could
operate. Curious, why DIP? I would lean towards a 4-pin S1, S2, +, - on
one end and SPI/I2C on the other. And mounting hole(s).

Also been thinking about QRE1113 breakout boards with Schmitt triggers.
Or maybe the Schmitt triggers would go on the quad decoder board. Can't
decide.

Anyone else need something like this?

Michael

[Michael Shimniok]

On 11/26/2013 11:45 AM, Thomas Roell wrote:

Being the newbie here ... Pixhawk does not seem to be cost effective. For $199 you get A Gyro/Accel/Compare system with a Cortex-M4 (the rest is not that useful for rovers). That is about the same as you get off the STM32F303 Discovery board, or the newer STM32F401 Discovery board (each less than $15). 

Also good point. I'd use one but I don't like the form factor. It'd be neat to have a small breakout on each side of the double-row pins to break out UARTs, I2C, GPIOs, ADCs, for Rover use.

On the topic of cost, hard to beat subsidized $15 :)  Regarding my "cost" claim from earlier, my RoverBaseboard is priced at $25, then add in a $40 Pololu MinIMU9v2 and an LPCXpresso LPC1769 at ~$30. So that's $95 total. Not exactly a pittance. But it's still cheaper than PX4 and at least you're not locked into sensor hardware (assuming you have software that allows you to swap in different sensors and try different algorithms). If you want to use a different gyro, drop the compass and accelerometer... add encoders, do whatever you want.

Michael

On Tuesday, November 26, 2013 11:36:22 AM UTC-7, JP B wrote:

I say this from a purely ignorant point of view - interested in benefits any other hardware platform may offer over the forthcoming 3DR pixhawk platform, which I can see the community taking forward with new software features whilst fixing the offering able to run on current APM hardware.  Looking ahead, going with the pixhawk which will attract an existing developer base is an attraction.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/1a27fa66-c40d-4c5d-9696-af5e2b65406b%40googlegroups.com.

[Thomas Roell]

The formfactor is kind of the real downside ... But the again, there is this here: http://www.rcswift.com/about-product/

The sensor on the F3 Discovery are the same as on the MinIMU9v2, except you have also the INT1/INT2/DRDY pins are routed. If the Accel/Gyro are not that great, you could add a MPU6050 only board as well (I2C is externally accessable), and just use the HMC5883L that is hidden inside the LSM303DLHC. 

[Thomas Roell]

On Tuesday, November 26, 2013 3:50:02 PM UTC-7, Michael Shimniok wrote:

Also been thinking about QRE1113 breakout boards with Schmitt triggers.
Or maybe the Schmitt triggers would go on the quad decoder board. Can't
decide.

Out of curiosity (and my ignorance as a SW only person). Couldn't you use COMP (analog comparators) on the MCU to emulate a Schmitt trigger ?

- Thomas 

[Jon Russell]

I've use these :

http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf

SPI interface, and they come in DIP, SOIC & TSSOP

They're about $4 each. I bought them from here http://www.geminielec.com/ 

Regards,

Jon.

[Jon Russell]

they do lots of other counters too ...

http://www.lsicsi.com/counters.htm

Regards,

Jon.

[Jon Watte]

Why DIP? Because I'm not tooled for surface mount. No hit air, no parts bin, and what solder paste I have in the fridge is way over date...

I have actually built a six-channel "step direction" decoder based on an Atmega, and it can do about 170 kHz doing just polled I/O and serial output. I've also done a Tiny-based decoder, but it is more finicky because of the lack of hardware peripherals (the USI isn't exactly "low maintenance.")

More importantly, the signal conditioning needed would be nice to get on-a-chip. Take a look at this output from the quadrature encoder on the Pololu 37D gearmotors:

https://www.dropbox.com/s/20t486iop0gg2hb/2013-10-11%2016.50.16.jpg

The spikes are after filtering with a 4.7 uF ceramic capacitor, and are in phase with the PWM driving the motor. The encoder electronics itself are driven by a well regulated 5V rail with 470 uF reservoir capacitor.

That's been a challenge when I've rolled my own. Using what's built into the RoboClaw motor controllers seems to work for me, though.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/5295259A.5040809%40gmail.com.

[Michael Shimniok]

On 11/27/2013 09:49 AM, Jon Watte wrote:

Why DIP? Because I'm not tooled for surface mount. No hit air, no parts bin, and what solder paste I have in the fridge is way over date...

I see what you're saying. You want a DIP chip. I was thinking in terms of making a board that has 0.1" pin headers and mounting holes to do the decoding and wires to whatever MCU you're using.

I have actually built a six-channel "step direction" decoder based on an Atmega, and it can do about 170 kHz doing just polled I/O and serial output. I've also done a Tiny-based decoder, but it is more finicky because of the lack of hardware peripherals (the USI isn't exactly "low maintenance.")

Too true! It took a bit to get my A2D board's I2C via USI going. I'm working on SPI with USI for an ATtiny84A AVR programmer. Of course I'm borrowing code, but tweaking it. Don't have slave SPI or master I2C yet. I do have software serial (rx/tx both) but haven't messed with USI-based rx/tx serial in awhile.

More importantly, the signal conditioning needed would be nice to get on-a-chip. Take a look at this output from the quadrature encoder on the Pololu 37D gearmotors:

https://www.dropbox.com/s/20t486iop0gg2hb/2013-10-11%2016.50.16.jpg

The spikes are after filtering with a 4.7 uF ceramic capacitor, and are in phase with the PWM driving the motor. The encoder electronics itself are driven by a well regulated 5V rail with 470 uF reservoir capacitor.

Hm, that's interesting... where do you think the spikes are coming from? Something to do with flyback from the motor? I don't remember seeing that on mine (with 100MHz analog 'scope). I was running the motor off an ESC with the MCU on a separate supply with lots of filtering. The QRE1113's I run output something like this.



And after running through my schmitt trigger (implemented with op amp for some reason now forgotten). I wonder if my scope is missing the spikes or something. Or maybe the fact that the motor's on a separate power system helps?

That's been a challenge when I've rolled my own. Using what's built into the RoboClaw motor controllers seems to work for me, though.

Good info!

Michael

[Jon Watte]

It took a bit to get my A2D board's I2C via USI going

The main annoying thing is that you'll likely lose pulses with a software implementation.

where do you think the spikes are coming from? Something to do with flyback from the motor?

I don't know!

In the start, it's the same battery, but the power is split off to motor controller+capacitor on the one hand, and regulator+capacitor on the other hand. When the motor controller drives the motor with PWM, I see those spikes. It may be a ground reference problem, perhaps... or some coupling somewhere.

The actual connections are in a small wiring board I made (very thick traces), so battery into roboclaw, roboclaw motor back out to board; to motor/encoder connector motor power; separately on the same board battery into 5V regulator, to motor/encoder connector encoder power; encoder outputs back to RoboClaw.

There is a shared ground between RoboClaw and battery and encoder, because of the encoder channel ground reference, and this is the same as battery ground.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/52962809.5010906%40gmail.com.

[Michael Shimniok]

On 11/27/2013 12:19 PM, Jon Watte wrote:

It took a bit to get my A2D board's I2C via USI going

The main annoying thing is that you'll likely lose pulses with a software implementation.

That is an issue but... I looked into this just now and it appears solved for the ATtiny. I think I can build this without losing a single pulse count at least within certain limits. Wayne, Jon, others, see what you think of this:

USI has the lowest interrupt priority on AVR, pin interrupts the highest (and there's also an INT vs PCINT that can come into play). So the issue is really with communication problems while handling pulses, not losing pulses while communicating. Provided you enable interrupts first thing in your handler so pin interrupts can fire during servicing USI stuff.

But AVR ATtiny USI appears to solve this. The USI peripheral is basically a start condition detector and data shifter. You stick data in a register and USI shifts it out. Interrupts are fired when it's done shifting and when start is detected.

After start is detected, a pin interrupt could occur at any time, so you don't want to miss the first rising SCL. Likewise, after data is shifted out, and the overflow interrupt is fired for that, you don't want to miss the next SCL.

However, USI takes care of this. Per AN312 "Since the USI Start Condition and USI Overflow event holds the SCL line when  activated, it is not timing critical when the interrupts are to be executed."  That is, clock stretching is implemented so that the master waits until you've handled the start or overflow interrupts.

How would one avoid missing two pulses so close together that you're servicing the first pulse while the second comes in? The perfect answer is dedicate a board per wheel. Then it can never happen since the quad channel is going to come in 90 deg out.

There's probably some interrupts that could get missed on two wheels per board if they happen very close together. According to the datasheet:

"If an interrupt condition occurs while the corresponding interrupt enable bit is cleared, the Interrupt Flag will be set and remembered until the interrupt is enabled, or the flag is cleared by software. Similarly, if one or more interrupt conditions occur while the Global Interrupt Enable bit is cleared, the corresponding Interrupt Flag(s) will be set and remembered until the Global Interrupt Enable bit is set, and will then be executed by order of priority"

After the first interrupt fires until you can clear the interrupt flag, the 2nd pin might change. I suppose you could just grab the pin states, then clear the flag right away leaving a window between instructions where a pin change could be missed. Or maybe use INT0 and PCINT at the same time so you're guaranteed they will both fire. Or use a device with INT0 and INT1 both.

Also, just found: the Tiny84A has an input capture capability, although the input pin is SCL. Rats. :(

where do you think the spikes are coming from? Something to do with flyback from the motor?

I don't know!

That's truly puzzling.

In the start, it's the same battery, but the power is split off to motor controller+capacitor on the one hand, and regulator+capacitor on the other hand. When the motor controller drives the motor with PWM, I see those spikes. It may be a ground reference problem, perhaps... or some coupling somewhere.

RF?

The actual connections are in a small wiring board I made (very thick traces), so battery into roboclaw, roboclaw motor back out to board; to motor/encoder connector motor power; separately on the same board battery into 5V regulator, to motor/encoder connector encoder power; encoder outputs back to RoboClaw.

There is a shared ground between RoboClaw and battery and encoder, because of the encoder channel ground reference, and this is the same as battery ground.

Hm... Filter caps on the motor(s)?  Are the spikes on the supply too or just the encoder output or?

Almost seems like there must be something induced on the encoder signal traces right?

Michael

[Tim Myrtle]

I ordered a LPCXpresso, but after looking at the APM:Rover code, I'm still wondering if the STM32 Discovery might be the better choice.

A big part of the APM code is the NuttX operating system.  This is a big, complex system!  A couple points in favor of the Discovery board:

* The ardupilot folks actually document their support of NuttX on the stm32f4discovery:  https://pixhawk.ethz.ch/px4/modules/stm32f4discovery

* Ardupilot is also a big contributor to the NuttX code, and are actively developing it for STM32.

On the NuttX site, it does mention support of LPC1769, but it isn't clear if the support is complete, and there is nothing about the LPCXpresso board specifically.

-Tim

[Wayne Holder]

On Wed, Nov 27, 2013 at 12:38 PM, Michael Shimniok <shim...@gmail.com> wrote:

On 11/27/2013 12:19 PM, Jon Watte wrote:

main annoying thing is that you'll likely lose pulses with a software implementation.

That is an issue but... I looked into this just now and it appears solved for the ATtiny. I think I can build this without losing a single pulse count at least within certain limits. Wayne, Jon, others, see what you think of this:

I agree.  A software solution should be more than adequate, as a quadrature input on a wheel encoder isn't changing all that fast relative to CPU speed.  For example, let's say your wheel can spin as fast as 1000 RPM.  On a bot with, say, a 3 inch diameter tire, that translates into a ground speed of nearly 10,000 feet/min ( 3 * Pi * 1000), or 113 MPH, which is far faster than any bot is going to run at the AVC.  Now, let's say the the encoder has, say, 100 ticks/rotation (which gives it a resolution of 1/10 inch/tick (which is, again, far more than you probably need.)  The end result is that the interrupt rate for an encoder is going to be a maximum of 100,000 interrupts/second.  For an ATTiny running at 8 MHz, that leaves 80 clocks cycles per interrupt to handle the interrupt, which is far mor than you'd need to count the tick in a well-coded assembly language function.  And, that's absolute worst case.

Now, you could use the USP peripheral to send the data to the main CPU, but it's not necessary, IMO.  SPI is a completely asynchronous protocol, as everything is relative to the clock transition.  So, it doesn't really matter if the shift out gets interrupted by the quadrature ticks.  The data will get through anyway. 

Wayne

 

[Jon Watte]

My goal is to read 8 channels (4 quadratures.) If I use interrupts for each transition, and the interrupt-handle-return time is 4 microseconds, then the maximum rate I can run at is 30 kHz or so, not counting communications. With polled input, I get closer to 200 kHz because I lose the overhead.

The USI is also annoying because it doesn't have a stop condition detector for slaves. Thus, there's nothing that will tell you that the master is "done" sending. Thus, too, means you have to start doing polled USI.

The Mega32 is only a little bit taller than the Tiny84, and only a buck more expensive, and has peripherals for all of the communications, so I'd probably save myself the hassle of cost optimizing this :-)

Regarding the spikes: IIRC, the red line on the 'scope is the power input to the RoboClaw. If that's accurate, then the source impedance of my long wires may be contributing.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/52965829.50909%40gmail.com.

[Jon Watte]

For an ATTiny running at 8 MHz, that leaves 80 clocks cycles per interrupt to handle the interrupt, which is far mor than you'd need to count the tick in a well-coded assembly language function.  And, that's absolute worst case. 

For a single channel, yes. For eight channels (four wheels of quadrature, or in my case, four channels of step-direction) you're way oversubscribed.

Now, you could use the USP peripheral to send the data to the main CPU, but it's not necessary, IMO.  SPI is a completely asynchronous protocol, as everything is relative to the clock transition.  So, it doesn't really matter if the shift out gets interrupted by the quadrature ticks.  The data will get through anyway.  

SPI is 100% master-synchronous. If the slave doesn't feed the data register in response to the transmit complete (or chip enable) then bad data will be shifted out.

I2C is still master synchronous, but it allows the slave to keep the clock low until it is ready to respond, so you can avoid data loss there (at the cost of stalling the master and bus.)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAB%2BjonAE%3DCmHwuiUf58cTAZ-zDZ6CEFZCxc2p%2BwsWrguzxKXaA%40mail.gmail.com.

[Michael Shimniok]

On 11/28/2013 04:08 PM, Jon Watte wrote:
> My goal is to read 8 channels (4 quadratures.) If I use interrupts for
> each transition, and the interrupt-handle-return time is 4
> microseconds, then the maximum rate I can run at is 30 kHz or so, not
> counting communications. With polled input, I get closer to 200 kHz
> because I lose the overhead.

How are you doing the polling? How do you avoid missing state changes
(ie, when USI interrupts fire)?

It's only necessary to have interrupts on half the channels. For each
quadrature pair, interrupt on rising edge of one channel and check the
state of the other channel in the handler to get direction.

I was thinking along the lines of using one ATtiny?? board per wheel or
at best one board per pair of wheels.

At 200kHz, timing resolution is 5usec whereas with interrupts the
hardware syncs to the clock, so 62.5ns at 16MHz. I bring this up because
I found that speed calculations worked better when comparing intervals
between edges.

> The USI is also annoying because it doesn't have a stop condition
> detector for slaves. Thus, there's nothing that will tell you that the
> master is "done" sending. Thus, too, means you have to start doing
> polled USI.

Not necessarily. True, the only thing you have to go on, really, is that
the master is "supposed" to send a NACK on the last requested byte. The
code I'm using checks for that in the overflow interrupt handler, and
resets the hardware to wait for start. So it expects the master to
behave itself. :)

> The Mega32 is only a little bit taller than the Tiny84, and only a
> buck more expensive, and has peripherals for all of the
> communications, so I'd probably save myself the hassle of cost
> optimizing this :-)

Undestood :) I kind of have to if I'm going to try selling 'em. I'm
forced to fret over $0.20 on my designs. :)

If the Mega32 (or other megas) have dual external event capture tied in
with 16 bit timers (like the Tiny841 I ran across) and they also have
TWI that'd be ideal. If not there's probably a PIC or ARM or something
out there that can do this. I am pretty sure the LPC1769 has multiple
input capture pins so I would probably continue to do this on the main
MCU in my preferred design.

Michael

[Ted Meyers]

Hey, that's not a bad idea!  You would lose some resolution though.  Don't you need to check both rising and falling edges?  Say your encoding is: 00, 01, 11, 10 [, 00, 01, ...].  And you are watching the second bit and it is at 01.  Going forward it next rises when it wraps all the way around to 01.  But it could also have dropped back to 00 and then forward to 01.  You can't tell which, unless you watch for falling edges.

Probably everyone knows this, but if you are coding in Arduino, don't use the digitalRead (or digitalWrite) functions, they take something like 60 clock cycles when the same operation can be done in 2 cycles.  It is ridiculous.  But they don't seem to have any interest in fixing it -- probably because it would make the code a little harder to read.

[Michael Shimniok]

On Nov 29, 2013, at 9:08 AM, Ted Meyers wrote:

Hey, that's not a bad idea!  You would lose some resolution though.  Don't you need to check both rising and falling edges?  Say your encoding is: 00, 01, 11, 10 [, 00, 01, ...].  And you are watching the second bit and it is at 01.  Going forward it next rises when it wraps all the way around to 01.  But it could also have dropped back to 00 and then forward to 01.  You can't tell which, unless you watch for falling edges.

I was thinking of two channel encoder where the channels are 90 degrees out of phase. So you only ever see 01 and 10 after an interrupt on the edge of one of the channels.

from digital.ni.com reproduced for educational purposes:

You could either interrupt on A rising or A falling or both. If you do both:

counter++;

direction = (a) ? b : !b;

Where a and b would be some code to get the bit value of whatever pin (PINX & (1<<PXn) or some such)

For an absolute encoder, I would think you'd just interrupt on the least significant bit channel then just read the states of all the channels... I think on most MCUs if you put the channels on consecutive pins on the same port you can just read them all at once to get the value. And some MCUs can create virtual ports. I forget if that's an ARM or dsPIC thing. But anyway, if you use PB0..3 on an AVR, then position = PINB & 0x0f;

Probably everyone knows this, but if you are coding in Arduino, don't use the digitalRead (or digitalWrite) functions, they take something like 60 clock cycles when the same operation can be done in 2 cycles.  It is ridiculous.  But they don't seem to have any interest in fixing it -- probably because it would make the code a little harder to read.

Yeah... I was looking at the core code the other day. They translate from pin 9 or whatever to the specific PINx and mask (1<<N). There's probably a faster/smaller way to do this with macros and ifdefs, though. Come to think of it that might be a good thing to incorporate into an improved arduino-tiny core... hmmmm...  yet another project I have in mind :)

Michael

[Jon Watte]

How are you doing the polling? How do you avoid missing state changes (ie, when USI interrupts fire)?

It is *all* polled. No interrupts. Poll everything once during the main loop, with a state machine for the serial communication.

with interrupts the hardware syncs to the clock, so 62.5ns at 16MHz

The actual interrupt latency is higher, because the CPU needs to save registers. The save and restore of an AVR interrupt is, IIRC, about 2 microseconds in itself. Add any kind of work, perhaps with a spinlock, and a "typical" time for a single interrupt handler is up to 4 microseconds. (The Arduino library does a lot more work in the interrupt handlers, and thus has much suckier latencies than this, btw.)

  I kind of have to if I'm going to try selling 'em. I'm forced to fret over $0.20 on my designs. :)

This hobby is small enough that your tooling and setup is going to dwarf the cost of a particular part -- even if you count your own time at $0/hour. If you count your time at something competetive with contracting, you're unlikely to get those $0.20 back on volume. What's you're projected sell? 100 units? 500? Really successful, at 2,000?

If the Mega32 (or other megas) have dual external event capture

The XMegas are the ones with quadrature decoders.

Another option is an FPGA :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

Michael

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/5297E25D.2070707%40gmail.com.

[Michael Shimniok]

On Nov 29, 2013, at 3:11 PM, Jon Watte <jwa...@gmail.com> wrote:

How are you doing the polling? How do you avoid missing state changes (ie, when USI interrupts fire)?

It is *all* polled. No interrupts. Poll everything once during the main loop, with a state machine for the serial communication.

How many cycles per loop for i2c? Guessing it isn't too bad. Is the loop timing deterministic?

with interrupts the hardware syncs to the clock, so 62.5ns at 16MHz

The actual interrupt latency is higher, because the CPU needs to save registers.  Arduino library does a lot more work in the interrupt handlers, and thus has much suckier latencies than this, btw.)

True. The bandwidth is worse than polled for those reasons but the timing resolution is still down to the nearest clock edge though assuming latency is constant. By resolution I mean if you measure delta time between two edges. 

Michael

On Thu, Nov 28, 2013 at 4:39 PM, Michael Shimniok <shim...@gmail.com> wrote:

On 11/28/2013 04:08 PM, Jon Watte wrote:

My goal is to read 8 channels (4 quadratures.) If I use interrupts for each transition, and the interrupt-handle-return time is 4 microseconds, then the maximum rate I can run at is 30 kHz or so, not counting communications. With polled input, I get closer to 200 kHz because I lose the overhead.

How are you doing the polling? How do you avoid missing state changes (ie, when USI interrupts fire)?

It's only necessary to have interrupts on half the channels. For each quadrature pair, interrupt on rising edge of one channel and check the state of the other channel in the handler to get direction.

I was thinking along the lines of using one ATtiny?? board per wheel or at best one board per pair of wheels.

At 200kHz, timing resolution is 5usec whereas with interrupts the hardware syncs to the clock, so 62.5ns at 16MHz. I bring this up because I found that speed calculations worked better when comparing intervals between edges.

The USI is also annoying because it doesn't have a stop condition detector for slaves. Thus, there's nothing that will tell you that the master is "done" sending. Thus, too, means you have to start doing polled USI.

Not necessarily. True, the only thing you have to go on, really, is that the master is "supposed" to send a NACK on the last requested byte. The code I'm using checks for that in the overflow interrupt handler, and resets the hardware to wait for start. So it expects the master to behave itself. :)

The Mega32 is only a little bit taller than the Tiny84, and only a buck more expensive, and has peripherals for all of the communications, so I'd probably save myself the hassle of cost optimizing this :-)

Undestood :)  I kind of have to if I'm going to try selling 'em. I'm forced to fret over $0.20 on my designs. :)

If the Mega32 (or other megas) have dual external event capture tied in with 16 bit timers (like the Tiny841 I ran across) and they also have TWI that'd be ideal. If not there's probably a PIC or ARM or something out there that can do this. I am pretty sure the LPC1769 has multiple input capture pins so I would probably continue to do this on the main MCU in my preferred design.

Michael

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/5297E25D.2070707%40gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGPVwQf7dwMXv1SGFjfahkyyU0bWOVGOUMHQLTHRB6izQg%40mail.gmail.com.

[Jon Watte]

I didn't combine quadrature decoding and I2C in this project -- I sent serial data out. I have separately done I2C on tinys before, which is why I commented on the annoyance of doing that :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/1B83E1F5-D4FD-4B3D-9FF8-5CEBEA1BBDFC%40gmail.com.

[Ted Meyers]

You could do what I'm doing and use a Teensy 3.0.  You can run them at 96MHz, and they have pin change interrupts on _every_ pin.  You could use the Teensy to process the encoders and send the results via whatever protocol you like.  Not bad for $20.

Ted

Michael

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/5297E25D.2070707%40gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGPVwQf7dwMXv1SGFjfahkyyU0bWOVGOUMHQLTHRB6izQg%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Jon Watte]

Teensy at 96 MHz? 

Oh, wait, there's a version 3! And it's ARM! Not bad.

Also, the OpenCM9.04 is 72 MHz ARM for $10. Also not bad :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/cc4692c9-2f42-4dcd-b5f7-b63a2e29b591%40googlegroups.com.

[John Leichty]

Ted, your Teensy advocacy has paid off. :-P

I just in the past few days decided to go with the Teensy this year after frustrations with the BeagleBone Black last year. The Teensy 3.0 is actually on sale today for Black Friday, for $14.75. I only got one to play with in hopes that the Teensy++ 3.0 will be out soon (there's been some talk of it on the PJRC forums).

I did some quick calculations and I should be able to read my 4 quadrature wheel encoders fine with the Teensy encoder library. It uses interrupts with a nice handler in assembly.

The Teensy 3.0 chip also has two hardware quadrature decoders, though they are not supported by any library yet and might have timer conflicts with the standard Teensyduino libraries.

[Michael Shimniok]

Sounds like there are a few good directions to go. Jesse and I are going to keep plugging at LPCXpresso. Ted and maybe John wants to join with Teensy (I have one and can help test). Then Tim and ?? With STM32F4/F3 Disco I have one of the F4s to test with. 

Michael

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/6b6d4c4f-3407-4275-9cdb-b78320587872%40googlegroups.com.

[Ted Meyers]

Oh, thank you!  I didn't even know that PJRC had them on sale today, and I've been meaning to order two more -- so I did!  Wow, it has quadrature encoders?  Never knew that.  I pretty much stick to the arduino IDE for programming them.  But, I can already see that I will need to get a little more advanced to get this ArduRover stuff working.

So Michael, you are working on the LPCXpresso?  Are you going through linux and makefiles to get things compiled?  I went through the Windows ArduRover build instructions, and got a little stumped on what to make of the "special" arduino IDE.  I'm really more at home building for Linux or Windows than microcontrollers, but I'm going to chug on into this.

Ted

[jesse brockmann]

I also have a Teensy 3.   So, I can help test that as well!  It's a very nice and cheap cpu.   And with the current deals, it's even better!  Woot!

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/16E96F51-F849-434F-8481-EDCFA8C839F9%40gmail.com.

[Jon Watte]

I went to get me one and it seems the sale is over.

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CANqFZg3XBJG61AZNHCT-F_AjPRfRJLDqEWh2Jdt%2BgZ2WK92UGA%40mail.gmail.com.

[Tim Myrtle]

For rover odometry, are quadrature encoders generally favored over single sensor encoders + commanded direction?

 

I had been using quadrature encoders but abandoned them in favor of single-sensor encoders.   I had found that any error in reading the quadrature pulses, either a missed pulse edge or noise on the line, causes the quadrature algorithm to flip direction and start counting backward.   This type of error in the middle of a run is basically catastrophic.  On the other hand, if you are just counting a single pulse train/wheel, any single pulse error is essentially tiny, and can be compensated for in the sensor fusion - a much better situation!

Is this perception of wheel encoders reasonable,  or was I just doing something wrong? 

-Tim

[Michael Shimniok]

My rover wasn't designed to back up so... Only incremental encoders for me. Your assessment rings true to me. 

But I might look at some approach on quadrature to reduce likelihood of errors. Direction is unlikely to change when above some threshold speed and when not commanded and for just one pulse so one could leverage those somehow. 

But until I decide to go for a robomagellan I will likely stick to incremental encoders. 

Michael

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/85f85c57-96d1-473a-a8b0-d4fc0bc4a38a%40googlegroups.com.

[Jon Watte]

any error in reading the quadrature pulses, either a missed pulse edge or noise on the line, causes the quadrature algorithm to flip direction and start counting backward.

That doesn't make sense to me. The direction is encoded in each individual state transition, so if you miss something once, you may back up for that count, but then keep counting forward again. There is no "state" other than "what was the previous quadrature output?"

So, given that there are two bits of previous output, and two bits of current output, there are only 16 possible transitions; 4 of those are no-ops (no change,) 4 are "backwards," 4 are "forwards," and 4 are "impossible" (as in both bits flip at the same time.)

Even if you get a wrong flip once, because you read the state of the encoders and keep that as the "previous state," you will immediately re-synchronize.

You can only lose "direction" if you had a systemic error that gave the same glitch for each increment, which seems like a bigger problem than just a glitch :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/46661F76-2AE9-4248-8F00-9CEBA9CD5E84%40gmail.com.

[Ted Meyers]

Yeah, I agree with you, JW.  Quadrature encoders work just as well as single encoders, and they give twice the resolution along with direction.  I figure that I might as well use them, and I can get direction -- although, normally a bot has a pretty good idea of what _direction_ it is going, or should!

I do have plenty of WTF moments with my quad encoders, but that is usually due to something like a bolt coming loose, or sunlight hitting the sensor.  I've found that I have to keep my optical sensors shielded from sunlight; they don't work at all if any sunlight gets in.

Ted

[Tim Myrtle]

On Friday, November 29, 2013 8:52:59 PM UTC-8, Jon Watte wrote:

any error in reading the quadrature pulses, either a missed pulse edge or noise on the line, causes the quadrature algorithm to flip direction and start counting backward.

That doesn't make sense to me. The direction is encoded in each individual state transition, so if you miss something once, you may back up for that count, but then keep counting forward again. There is no "state" other than "what was the previous quadrature output?"

So, given that there are two bits of previous output, and two bits of current output, there are only 16 possible transitions; 4 of those are no-ops (no change,) 4 are "backwards," 4 are "forwards," and 4 are "impossible" (as in both bits flip at the same time.)

Even if you get a wrong flip once, because you read the state of the encoders and keep that as the "previous state," you will immediately re-synchronize.

You can only lose "direction" if you had a systemic error that gave the same glitch for each increment, which seems like a bigger problem than just a glitch :-)

Interesting.  Thanks for the great explanation.

I had reduced my quadrature state machine to one with only two states and four transitions, which could be implemented using only pin change interrupts without ever reading the actual value of the encoder outputs.  Worked great, and i still think it is technically correct, but I now see that it is highly intolerant of errors.

If implemented in the standard way as you describe, with the value of the encoder outputs read on each interrupt,  the correct state would indeed quickly re-sync after an error.  Much nicer.   So yea, I was doing it wrong.

[Ted Meyers]

Interesting.  Thanks for the great explanation.

I had reduced my quadrature state machine to one with only two states and four transitions, which could be implemented using only pin change interrupts without ever reading the actual value of the encoder outputs.  Worked great, and i still think it is technically correct, but I now see that it is highly intolerant of errors.

If implemented in the standard way as you describe, with the value of the encoder outputs read on each interrupt,  the correct state would indeed quickly re-sync after an error.  Much nicer.   So yea, I was doing it wrong.

Okay, so I've done something similar, and had a concern that something could go wrong when not actually ever reading the pins, but I never stopped to figure out what the problem was exactly.  Thanks for the explanation.  This is what I had:

void ISR_LA() {

  if (la_state == lb_state) left_count--; else left_count++;

  la_state = !la_state;

}

void ISR_LB() {

  if (la_state == lb_state) left_count++; else left_count--;

  lb_state = !lb_state;

}

void ISR_RA() {

  if (ra_state == rb_state) right_count--; else right_count++;

  ra_state = !ra_state;

}

void ISR_RB() {

  if (ra_state == rb_state) right_count++; else right_count--;

  rb_state = !rb_state;

}

Ted

[Tim Myrtle]

Okay, so I've done something similar, and had a concern that something could go wrong when not actually ever reading the pins, but I never stopped to figure out what the problem was exactly.  Thanks for the explanation.  This is what I had:

void ISR_LA() {

  if (la_state == lb_state) left_count--; else left_count++;

  la_state = !la_state;

}

void ISR_LB() {

  if (la_state == lb_state) left_count++; else left_count--;

  lb_state = !lb_state;

}

void ISR_RA() {

  if (ra_state == rb_state) right_count--; else right_count++;

  ra_state = !ra_state;

}

void ISR_RB() {

  if (ra_state == rb_state) right_count++; else right_count--;

  rb_state = !rb_state;

}

Ted

I don't have my code in front of me, but I think this is exactly what I was doing.   On startup, you read the encoder outputs to "sync" the initial states so it starts counting in the correct direction, but never again after that.  The problem I experienced is that any errors cause the state machine to lose sync, and start counting in reverse.  Fun!

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition.  Can this be done without a read?  Maybe using two pins/output line and and interrupting separately on rise and fall?

[Ted Meyers]

I don't have my code in front of me, but I think this is exactly what I was doing.   On startup, you read the encoder outputs to "sync" the initial states so it starts counting in the correct direction, but never again after that.  The problem I experienced is that any errors cause the state machine to lose sync, and start counting in reverse.  Fun!

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition.  Can this be done without a read?  Maybe using two pins/output line and and interrupting separately on rise and fall?

 

So, I did a little research on this.  There is an encoder library for the teensy, and it appears to be very thorough and efficient, although it has not been highly optimized for the 3.0 yet.  The 3.0 also has a hardware encoder, but there is no support for that yet.  I don't see how you could get around not reading the pin, on the 3.0 it should only take 1 clock cycle, but I suppose the pin could change (again) before you have a chance to read it -- but it would have to be changing crazy fast (or bouncing).

I'm going to try the library and see if that fixes some of my WTFs.  (If not, I'll go back to my current simple code).

Ted

[Michael Shimniok]

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition.  Can this be done without a read?  Maybe using two pins/output line and and interrupting separately on rise and fall?

Reading the pins isn't a huge time waster on AVR (or probably same on most MCUs). You can use the test/skip instructions for testing bits in IO registers, something like this (for determining direction):

ldi r24, lo8(0) /* r24 = 0; 1 clock */

sbic PINB, 1  /* testing bit 1 of PINB, PB1, 2 clocks  */

ldi r24, lo8(1) /* r24 = 1, 1 clock */

sts direction, r24 /* direction = r24, 2 clocks */

The longest path through this is 4 instructions, 6 clock cycles 0.375µsec at 16MHz (62.5ns/clock). The time required to figure out what state you're in and change that state to the next one is probably similar.

Incrementing a 16 bit value takes 5 instructions:

lds r24,counter

lds r25,(counter)+1

adiw r24,1

sts (counter)+1,r25

sts counter,r24

There's time required to push/pop values... you can minimize that I think.

I can't seem to think of a race condition that could occur on a single channel. Did you mean on multiple channels?

Hope this helps,

Michael

[Jon Watte]

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition. 

The read is a single instruction. The race condition isn't appreciably worse than you get from the interrupt latency anyway. Any encoder reader will have an upper frequency beyond which it cannot keep up. When you read the input bits, this will show up as an "impossible" transition, which you can detect and do something about (turn down speed, emit a fault, etc.) When you just count interrupts, you will not detect when the encoder runs too fast, so no possibility of recovery.

That being said, with typical interrupt latencies, you'll have to run at a speed of over 10 million steps per minute to get to the point where you start seeing this, which is unlikely with most motor/encoder combinations. The Pololu 37D motors, with 64 transitions per motor turn and overdriving the motor to 10,000 rpm, you'll  only do 640,000 transitions per minute, so a headroom of about 93% is good enough for that case :-)

Regarding using single encoder channels: You get a "tick" (a k a an "index") but you can't reliably use this for things like PID controllers. For example, if you command the robot to stand still, but it's on a slope, you will not know whether the ticks are coming in because it's sloping forwards or backwards.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/a3dc933c-141f-4018-b549-c7ba88730731%40googlegroups.com.

[Tim Myrtle]

On Saturday, November 30, 2013 5:04:29 PM UTC-8, Michael Shimniok wrote:

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition.  Can this be done without a read?  Maybe using two pins/output line and and interrupting separately on rise and fall?

Reading the pins isn't a huge time waster on AVR (or probably same on most MCUs). You can use the test/skip instructions for testing bits in IO registers, something like this (for determining direction):

ldi r24, lo8(0) /* r24 = 0; 1 clock */

sbic PINB, 1  /* testing bit 1 of PINB, PB1, 2 clocks  */

ldi r24, lo8(1) /* r24 = 1, 1 clock */

sts direction, r24 /* direction = r24, 2 clocks */

The longest path through this is 4 instructions, 6 clock cycles 0.375µsec at 16MHz (62.5ns/clock). The time required to figure out what state you're in and change that state to the next one is probably similar.

Incrementing a 16 bit value takes 5 instructions:

lds r24,counter

lds r25,(counter)+1

adiw r24,1

sts (counter)+1,r25

sts counter,r24

There's time required to push/pop values... you can minimize that I think.

Thanks for breaking this down for me - I'm learning a lot from this group! 

 

I can't seem to think of a race condition that could occur on a single channel. Did you mean on multiple channels?

I'm just referring to the delay between when the interrupt is asserted (?) and when the pin is actually read in the ISR, which could potentially cause problems.

[Michael Shimniok]

Btw I didn't actually test that assembly yet. :)

> I'm just referring to the delay between when the interrupt is asserted
> (?) and when the pin is actually read in the ISR, which could
> potentially cause problems.

Ah ok. If the rpm and resolution are high enough, the interval between
edges will be less than the time it takes for the ISR to read the pin
value. How fast is your robot going to be, anyway? :)

Michael

[Tim Myrtle]

On Saturday, November 30, 2013 9:02:42 PM UTC-8, Jon Watte wrote:

Still, I don't really like the idea of having to read the encoder outputs in the interrupt, both for performance reasons and for the possible race condition. 

The read is a single instruction. The race condition isn't appreciably worse than you get from the interrupt latency anyway. Any encoder reader will have an upper frequency beyond which it cannot keep up. When you read the input bits, this will show up as an "impossible" transition, which you can detect and do something about (turn down speed, emit a fault, etc.) When you just count interrupts, you will not detect when the encoder runs too fast, so no possibility of recovery.

That being said, with typical interrupt latencies, you'll have to run at a speed of over 10 million steps per minute to get to the point where you start seeing this, which is unlikely with most motor/encoder combinations. The Pololu 37D motors, with 64 transitions per motor turn and overdriving the motor to 10,000 rpm, you'll  only do 640,000 transitions per minute, so a headroom of about 93% is good enough for that case :-)

Regarding using single encoder channels: You get a "tick" (a k a an "index") but you can't reliably use this for things like PID controllers. For example, if you command the robot to stand still, but it's on a slope, you will not know whether the ticks are coming in because it's sloping forwards or backwards.

Jon, that was very helpful.  Thanks for your insight.

And sorry for hijacking this thread!

[Andrew Tridgell]

Hi All,

Tom and Linus pointed me at this thread, and I thought I could offer some input. I'm the lead developer for APM:Rover.

I actually think the APM:Rover code is really not very sophisticated at the moment by real robotics standards, but it is a reasonable framework that covers the basics of navigation, steering etc and could be a good starting point for a wide range of projects.

There are many ways that people can take APM:Rover and extend it. One of the more interesting things from my point of view is porting it to a new board. The APM code was historically designed for 8 bit AVR boards (Arduino style) but that was a long time ago. It now runs on a wide range of CPUs from 8 bit to 64 bit, and from 16 MHz AVRs to 1GHz ARM boards. For example it runs on APM1/APM2/PX4/Pixhawk/Flymaple/VRBrain and is now being ported to the BeagleBone Black and the RaspberryPi. It can run both "bare metal" or on top of a RTOS or a "full fat" OS like Linux. The BeagleBone black port I think is particularly interesting as it offers the chance of good quality vision code on the rover via systems like OpenCV.

If somebody wants to port it to a new board then that would be very welcome. The AP_HAL system usually makes doing a new port quite easy. Having a look at the AP_HAL_Flymaple and AP_HAL_Linux libraries to get an idea of what is involved.

I'd also love to see people do new types of sensors. Adding wheel encoders would be great, and optical flow would also be interesting. I'm working on a differential GPS system as an alternative for accurate positioning.

The real advantages of APM:Rover are:

• good simulation via SITL, so you can try new algorithms indoors. For a competition build it would be very worthwhile to adjust the simulator to match the characteristics of your rover. This was one of the keys to Tom doing so well last year.
  
• having all the basics done for you, so you can work on new stuff and not just solving the basics again which is really not that interesting
  
• good comms framework with MAVLink so you can analyse the behaviour in realtime
  
• good on board logging so you can get detailed sensor logs that can be analysed with tools like mavgraph and even loaded as raw data into MATLab or Octave
  
• reasonable support for hot-swapping controllers at runtime, so if you add a new navigation or steering controller you can easily add a parameter which you can change over MAVLink so you can compare your new controller to the standard one while in the middle of a mission. When I add a new controller this is usually how I compare - I run the rover around a course and then swap in the new controller while driving and then watch what happens. Live tuning is also very useful.

That said, I'd also be really disappointed if everyone just used APM:Rover in competitions, that would be boring!

If you do decide to use APM:Rover then please consider making your patches available in github and submit them for inclusion in the mainline releases.

Cheers, Tridge

[jesse brockmann]

Tridge,

   Good to hear from you!   We certainly will provide any changes or additions back to APM:Rover that we come up with.  That being said, if we provided all of them, how do we get an edge?   :)     I would really like to hear more about differential GPS solutions, because outside of the Sparkfun AVC, I have several applications where I could like to be able to use that. 

JesseJay

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/004edad5-e606-432c-9704-66746e5b5206%40googlegroups.com.

[Jon Watte]

Thanks for the update!

I've looked at the APM rover page, and while I approve of the overall concept, all of the details are different from my preferences :-)

I'm using an independently sprung chassis with 4 wheels each with direct drive and direct steering.

I use RoboClaw motor controllers with motor-based encoders. (And a mini Maestro for the steering servos)

I use an Core i5 mini-ITX computer running Linux.

And I use Xbee Pros for telemetry and remote control (bi-directional.)

I could add one or more Leonardo Minis, or OpenCM9.04s, or Raspberry Pis, or DiscoveryF4s -- I have at least one of each in the parts bin! But currently I don't see the real need compared to what I already have...

So, would it make sense at all to try to re-use APM Rover with this set-up?

Sincerely,

jw

Sincerely,

Jon Watte


--
"I pledge allegiance to the flag of the United States of America, and to the republic for which it stands, one nation indivisible, with liberty and justice for all."
~ Adopted by U.S. Congress, June 22, 1942

[Ted Meyers]

Hi Tridge,

Thanks for the explanation.  I'm hoping to port the code to the Teensy 3.0 (my favorite microcontroller) and I have already looked at the flymaple code -- it does look like a good starting point.  But I'm having trouble figuring out the build process.  I was able to follow the development instructions for building the AVR code, but I didn't see anything on building for alternate hardware.  I've been doing this sort of thing for a while now, so I should be able to figure things out, but the special arduino build kind of threw me.  I guess what I'm asking is do you have any hints or a tutorial?

Also, I am intending to write some wheel encoder code.  And yes, I do intend to post my code!

Ted

[Michael Shimniok]

Hey, really glad you could join in!!

On 12/01/2013 05:22 PM, Andrew Tridgell wrote:
> If somebody wants to port it to a new board then that would be very
> welcome. The AP_HAL system usually makes doing a new port quite easy.
> Having a look at the AP_HAL_Flymaple and AP_HAL_Linux libraries to get
> an idea of what is involved.
> I'd also love to see people do new types of sensors. Adding wheel
> encoders would be great, and optical flow would also be interesting.
> I'm working on a differential GPS system as an alternative for
> accurate positioning.

Definitely interested in contributing to the base code. I don't have a
good handle on much yet but in due time.

> The real advantages of APM:Rover are:

> ...

> That said, I'd also be really disappointed if everyone just used
> APM:Rover in competitions, that would be boring!

Don't worry, I plan to try out our own estimation algorithms as I
suspect is true of Ted and others :)

But I'll be most happy to have a head start with all the simulation,
basics, coms, logging, etc. I wrote some of that from scratch the first
time around, but it's all really primitive.

> If you do decide to use APM:Rover then please consider making your
> patches available in github and submit them for inclusion in the
> mainline releases.

Most definitely! Will keep you posted.

Michael