OK, a couple of (advanced) newb questions;

I have just started to get serious with a lineLeader, and thus just moving beyond the demo program provided on their (mindsensors) web site.

First thing I notice, is that robotC 'allow third party sensors' includes the Mindsensor lineFollower. I assume that is a typo? and is indeed the lineLeader?

Next thing is the mindsensors sample robotC code does not use any robotC I can decypher. So does the 'built in' support in robotc, do anything? or should I just stick to the mindsensor supplied include file?

Is there any guidance as to how the lineleader PID works? I'm not asking for the basics, I'm actually asking about any of modified PIDs (integral windup, deadband, feedforward, cascade), and which type if any, might they be using? I'm leaning towards cascade as I write my own. I guess I could ask them, but it seems like a public forum would share the answers better.

And last, any guidance as to what things I should 'log' to assist in tuning a PID? I assume in, time, error, out(PID) - not being able to get at the PID from the line leader (you only access the constants, not the actual values) is why I believe I need to write my own, am I correct? How badly does logging data hit the CPU? am I better trying to store in whatever memory I have left (round robbin) ? then dump to a file when stopped?

Sorry, advanced newbs are the worst

Use the MSLL driver in my suite and all will be well!

- Xander

I very likely will. But, still curious on the questions. Did you implement a genetic algorithm for cascading PID?

(http://journal.library.iisc.ernet.in/vo ... r4/343.pdf)

Yes but then my dog ate the source code.

True story.

- Xander

That's why I always keep my dogs in a virtual machine

I was just looking at some of your old articles and came across this
"This is the most interesting part in building a PID control. In this step one should tune the Kp, Ki and Kd values to get the best results. I cannot give you the values because what works for me will not work for you. The optimum Kp, Ki and Kd values vary a lot from robot to robot. And the best way to determine the optimum values is by trial and error."

In fact, that is known as "the poor man's genetic algorithm", so your story is plausible. Now if I could just get my hands on one of them fancy new mindstorms IMU units, I could turn it in to a rich man's algorithm (yes, already emailed, no reply )

I wrote a plotting program for NXT/Robotc datalogs. Read about it here http://www.spiked3.com/?p=345



Nevermind RobotC, Datalog, Grrrrr.

Xander, I hope its ok to post a question to you here, if its not, just ban me
I read your article about smoothing the lineleaders reading, and I was curious, was this because you were receiving data that looked like this?
If so, would dampening it be the correct choice, versus just ignoring (ie continue previous course of action) it when it spikes to 100? Or maybe enter some sort off 'lost' behavior?

Side question: I am eagerly anticipating being able to order a Mindsensors IMU soon (finally got a reply; "soon"). Any chance I can get your updated RobotC drivers for it early?

Thanks.

The reason I did this was to allow me to more easily detect a crossing or a T-junction with my maze following robot.

As for the driver, I don't have the sensor yet either but when I do, I will start working on it I'll ping Deepak about it.

- Xander

I feel the need ... the need for speed;

Wow, that thing is fast! Nice job!

- Xander

Wow! That thing is on fire!!

thanks notice the mat is on a table, I really wish the camera had been rolling for the blooper reel There is a reason an easy to reach and hit button got added on top.

This is why I test my robots on the ground, haha. I have had many a robot nose-dive right off the table onto one of my two unsuspecting dogs.

- Xander