I need to get really fresh GPS data (w/VIDEO)

Can you view this?

http://s43.photobucket.com/albums/e396/arbarnhart/robo/?action=view&current=robotruck-1.mp4
(as an aside, anyone know how to get the real embed URL from PhotoBucket?)
I looked at the data. When it runs far off (and it was starting to turn back but I cancelled it because of the obstructions), it is because it missed an update and is still assuming it is on the other side of me. The GPS isn't wrong, but when you get info every second and are moving several feet per second trying to home in on something a short distance away, it is critically important how fresh GPS data is. I can try adding a function to get current data that waits up to a second before returning, but should return with very fresh data.
Computing bearings from GPS locations you are past is an exercise in futility.

 

OK, not near enough context.

OK, not near enough context. It is using GPS autonomously, homing on a GPS that is in the base unit I am holding. The base unit sends another request every second in case it is moving or the last one was missed. I have measured relative accuracy on the GPS units and it is within a few feet.

Is that the slowest speed

Is that the slowest speed your truck can go? I am also wondering what kind of control you have implement P, PD, or PID? What is the update rate on that GPS anyway? The one i use is 1hz. There are other GPS units you could get with update rates of of 10hz.

It can go slower, but I am

It can go slower, but I am using it to imitate a USV that has to home quickly. It goes faster than this.  That’s also why I don’t back up even though I know it causes the inherent problem with getting to something off to the side but within the circle of your turning radius. The boat pivots. Aren’t you reading in GPS data at 4800 baud also? No matter how many samples the unit takes, if it transmits oncer per second and sends me 240 or so characters, then GPS data will always be roughly .5 to 1.5 seconds old. If I am moving at 20 feet per second, this will dramatically change the bearing I should set to turn towards something.

You are going to have to educate me on your P abbreviations…

My control is another Arduino. They communicate via xBees. Besides homing, implemented a primitive joystick mode on the base unit. I use a 4 switch joystick and pass the same commands that homing uses - turn left or right, bear left or right, go straight or stop (coast, really) and all the movement commands have a fast/slow setting.

When I turn to take a new bearing, I use the same method as you, waiting for the bearing and then heading off. Most of the time I set flags and return so main loop processing can continue.

 

Accuracy

This is the kind of accuracy I am getting:

3gps.jpg

I am very pleased with how accurate the units report where I have been, which pretty much equates to where I am when walking. Audio nav units for cars have the luxury of telling you about a turn coming up when it is still far enough away that roughly correct works.

 

The real embed url:

The real embed url: http://vid43.photobucket.com/albums/e396/arbarnhart/robo/robotruck-1.mp4

More info

Thinking about it after explaining it earlier, it occurred to me that I really don’t have to accept sometimes getting behind and missing part of an NMEA string (which is all, since then it isn’t easily decoded) sometimes when I get busy. I broke out the “check for available and call decode” portion and sprinkled calls to it around. But the thing that made the most difference is tracking age of GPS data. I added something that waits up to a little over a second for new data if the correct data isn’t under a second old. I call it when I need GPS data to calculate the next bearing to take. I will have to get a much more impressive video in the daylight. I still have some issues with the last few feet, but I can put it in traditional RC mode and send it pretty far away from me down the street and leave it aimed in any direction to start homing. It will turn back toward me correctly and come pretty much right at me until it gets within 50 feet or so. Then it bobs and weaves all around me, usually coming within 4 or 5 feet within 3 passes. I still may need a different technology for the last 20 feet.

I get an error when I put that in the video URL box.

You have specified an invalid media URL or embed code.

Looked up P, PD an PID; not sure I understand how they apply

 

The problem space isn’t static and the errors in accuracy of target location are indiscernible from targeting a moving object. Each time a seek request is received, it is treated as a new command to supersede any previous target it was homing in on. 

P, PD, and PID apply to your

P, PD, and PID apply to your steering. Without a good way to steer to your needed bearing, then you will never have a very good system. You said your steering is like this "turn left or right, bear left or right, go straight or stop (coast, really) and all the movement commands have a fast/slow setting."

Rather my steering is done via calculation (PD):

 

void execute(){

error=(heading-headinggps);

//handle wrap-around  

if (error < -180){ 

error = error + 360;  

}

if (error > 180){

  error = error - 360;

}

//Serial.println(error);

float HEADING_KP=.8;   //gains. Randomly choosen right now. Not tuned

float HEADING_KD=.2; 

int derror = ((error - last_error) / 2); 

int ierror = ((error + last_error) / 2);   

float diff = (HEADING_KP * error) + (HEADING_KD * derror);

int PD_output=diff;

last_error=error;

servo.write(map(PD_output, -50, 50, 110, 70));

 if (listen()){

   decode();

 }

esc.write(speedesc);  //drive the set speed

}

So if i understand correctly, your steering is set in stone just you have a few different types. While my steering varies based on exact data. So i think you should try to drive to a GPS point first, not a moving one, and see how your steering holds up. See if you can drive a square pattern or something. If your current setup and code can not do that then i would change it till it can.
Just my opinion and of course this is only true if i am understanding correctly. 

 

 

I guess I misunderstood,

I guess I misunderstood, that’s a direct link to the video itself. I thought you meant a direct link to the embedded video and not a driect link to embed the video.

Aside but relevant

Getting the correct embed code from photobucket is irrelevant. Photobucket is not a supported video provider in the eyes of our Drupal CMS.

"Enter the URL or Embed Code here. The embedded third party content will be parsed and displayed appropriately from this.
The following services are provided: Blip.tv, Brightcove, Dailymotion, Google, JumpCut, Live Video, MetaCafe, MySpace, Revver, Sevenload, Vimeo, Youku, YouTube"

Also see /node/4364 and /node/2270.