That made me laugh out loud!
Yeh it really is isn’t it.
This is a great showcase of how the position controller uses the position to define the result but the velocity to define the fast response. I am looking forward to seeing the velocity axis fixed. I think you will find it becomes very tight!
Great work!
Ok, this is looking better. Here is a fixed yaw run with un-modified position and velocity passed directly from the ground GPS, and using the correct velocity axes for north/east.
Here is a run with SET_ROI turning the copter nose toward me (no look-ahead for ROI), and PSC_JERK_XY increased from 5 to 7. For some reason this video has been stuck ‘processing’ for over 24 hours, but it still plays if you click on it.
Thankfully the EKF problem only caused a landing in a very safe place, my luck is still holding and the weather was nice too 
The problem with altitude offset between the two GPS units changing over time has become so annoying that I think I’ll leave this approach here for now (except for perhaps some testing of ROI target look-ahead). Sometimes the altitude swings about 10 meters in a few minutes. Even if I had a way to adjust it on my ground tag, this level of disruption makes it impractical to use for any longer than these video clips and I find myself rushing to get it done before the altitude changes too much.
It would probably help if my ground tag was another Ardupilot board with merged baro+GPS to use, or maybe RTK on both. But I think it would be nicer to not rely on altitude difference at all. Lat/lon accuracy is quite good and drift is minimal, so perhaps the xy position could be used to look up a target altitude in some kind of pre-mapped terrain data, which could also include stay-out regions.
Well done! That is much more like it.
You can increase the Jerk to be 2 times your acceleration, maybe 4 times depending on what you have it set to. That will help it follow the fast breaking mauvers.
The climb may be vibration. I would have to check the log.
Bugger about the gps altitude difference. I use zed-f9p gps and they tend to do very well.
Thanks for the work on this mate. I have enjoyed seeing it used properly!
Ok, you are getting vibration problems when you go fast. You are starting to see clipping. You can see this in the VIBE message.
You are also using the baro for height on the aircraft. You may get better results using the gps altitude by setting:
EK3_SRC1_POSZ 3 (0:None 1:Baro 2:RangeFinder 3:GPS 4:Beacon 6:ExternalNav)
Gentlemen, i have one question about what i saw from what Chris did, sorry if this question is already mentioned by him, i’m a bad listener and a bad reader too
what is bothering me is
“why he not use an easy and simple phone aplication like Tower which we can used internal GPS from phone it self to make vehicle follow us (GCS) but instead he use a laptop with external gps”
what i’m missing here? because i’m sure Chris know it if he can used phone to make that goal, so i wonder why make Chris not use it
long time i want to test this one but i’ too lazy to doing it, until i saw Chris did, so i want to try it my self, but before that i want a confirmation about what makes me bother as i describe above 
Because he is not using follow mode. He is generating guided commands. As his code evolves he may choose to do more complex paths to follow what he is doing. A laptop may be more convenient to write and test code on than a phone. But I don’t see a reason why it could not be transferred to a phone.
ah short but answer all my question, thank you Leonard
i will proceed my plan without worry 
but fyi, i used “GUIDED” mode not follow me, i’m already make short test yesterday (PLANE), when i switch to “GUIDED” the plane start circling above me (GCS), but i’m not test to walk and find out if the plane follow the GCS or not, maybe after this i will
thank you…
There is no laptop anywhere, I don’t know where you got that idea…
As I mentioned in the first post it’s a board of my own design. It uses a nRF51822 with LNA/PA stage for both transmitter (on my helmet) and receiver on the quad. This chip has many similarities with the nRF24 radio modules I’m familiar with, but it’s also a microcontroller.
Here’s what is stuck onto the helmet:
The long thin shape of the board is because it was actually designed for something else (tilt hydrometer for brewing) so it has many components (accelerometer, step-up regulator, high precision thermometer) which are unnecessary for this usage, and of course that battery could be much smaller. If the board was specifically designed for this purpose it wouldn’t be hard to make a small rugged unit that would be easily wearable (eg. as an armband) or attached to vehicles.
A phone would be large and clunky, not realtime, not necessarily easier to program, more expensive and fragile, and I’m not sure what radio method it would use to transmit over potentially hundreds of meters, pretty sure bluetooth would not cut it. I also would not expect the GPS in a phone to perform on the same level as a dedicated module with a patch antenna.
hi Chris i’m so sorry i think i got my brain mixed because i’m always follow your “mix” work, you were right after i rewatch again i’m not found any laptop but you not mention use phone either so i just “assuming”
but! the worse is why i’m ignoring to think when you mentioned “computer companion”
thats why i assuming you use laptop ahrrrr
what makes me regret is…
because actually we have some vision for doing this project
look a like isn’t it
i made my own “companion computer” from my unused android stick, i replace the o/s with ubuntu and use mavproxy in it and use multi vehicle to follow each other (the finall goal)
i’m sorry for my mistake 
just found this video, it is uploaded some days ago.
seems like incredible follow performance, 80kmh and 1 meter error
the news say " For a brief technical description, the Beacon is an independently powered unit with a full ArduCopter flight stack configured with dual RTK GPS hardware in direct comms with Callisto 50 UAS via 915MHz meshed RF link. The ‘Freespace Operations RF Beacon’ hardware & software framework has been in the works for 3 years, beginning with the development of ArduCopter v4.1. It utilises Trigonometric S-Curve Navigation along with other new features coupled with LUA scripting working seamlessly with the industry-leading control precision & authority of the Callisto 50 UAS"
“EK3_SRC1_VELXY” and "EK3_SRC1_POSXY " Can you explain these parameters?
My goal is to use the VL53l1x for takeoff and landing. I want it not to be used on horizontal flights.
