Recently I just want to use fake gps signal to make the drone fix indoors in Loiter mode with Pixhawk. ( I programed to convert the UWB xyz position info to NMEA protocol and pluged in gps port )
Now the drone can fix in one position, but it still drifts, not that still. (Following is the test log link), The error on mission planner like Error pos horiz variance often happens.
Of course it’s going to drift, you’re giving it fake information. As the copter drifts, the IMUs detect that. But your fake GPS is reporting perfectly still. So the EKF generates very correct and expected errors. I’m not sure what you’re attempting to accomplish here, but feeding false information into the flight controller is not going to accomplish it.
@Pedals2Paddles
Yeah, I think you hit the point. But the fake gps signal do change with the drifts with every 10cm. Besides how can drone be just still outdoors with that terrible real gps accuracy.
Well I use UWB for positioning and I just convert the zyx info to latitude and longitude. UWB can track the drone’s position change, so the latitude and longitude will change.
@Debupt
Hi, I am doing the same thing just like you, even use the same UWB module and use pixhawk too. Have you deal with the problem yet?
I have no idea of the mavlink control msg, which messege( SET_ATTITUDE_TARGET or ATT_POS_MOCAP or the other? )is useful?
and, i try to use another way to replace the fakeGPS. just calculate the distance and use RC_channel_override to control it. after some tests, i sure RC_channel_override msg is good to use. but i haven’t do the complete test for the project.
if you have another method or advice to do it. please tell me, i will be appreciate.
Hey.
Well, I have used two method to send fake gps msg to pixhawk, fake gps info
with NMEA protocol and MAVLINK msg GPS_INPT(#232). Actually, the result is
not very well. When in Loiter mode, the drone will drift for ±5cm, not that
still as the real one.
If you use the same way as me, changing position to lat and lon and sending
them through telem port, you can change the original lat and lon to (0,0),
and decrease the rate of sending gps info to pixhawk. The result may be
much better.
With you method of using RC_CHANNEL_OVERRIDE, for my understanding, you
know the position info of drone and just send control cmd to drone to
adjust the position? is it right? I think it may be too hard for tuning PID
for control that precise?
BTW, by your email name, are you Chinese?
The use of RC_channel_override is Exactly what you say. I’m concerning about the precise since I try to use the RC_override msg. But because the drone will know where it is ( the control board which includes the process to positioning and sending RC_override msg is on the drone. I just send the point msg) , so I prepare to make a extra Kalman filter to correct it.
So the drift only for ±5cm of your experiment? It’s so good! How can you solve the time_usec problem of GPS_INPT? the timestamp of GPS is the clock of satelite, but how can i estimate this?
BTW. I lived in Taiwan, not China. Maybe is “not yet” for our government?
This weekend I adjusted the params of pos_xy_p, vel_xy_p and vel_xy_i, the
result was much better in Loiter mode, it just like outdoors with real gps.
Within the drift can be accepted.
About time_usec, you can just give a timestamp, like this:
time_usec = (Now.tm_hour * 3600 + Now.tm_min * 60 + Now.tm_sec)*1000 +
Now.tm_msec;
About gps time_week and time_week_ms you can search for gps time and find
some convertion.
Actually pixhawk doesn’t care about the time_usec, time_week and
time_week_ms, at least for my test.
Well, as for rc_channel_override, you should give the channel value with
mavlink, right? How can you know how much should you give to pitch, roll,
yaw and throttle to make the drone fix in one position.
The part of fake gps, I shall do some experiment recently.
And about the RC_override. The take off will be controlled by a 3DR controler.
It’s also a emergency switch for the experiment. And the msg of override is like this: RC_Channel_Override(0,0,1100,0,0,0,0,0);
The first 4 parameters are raw pitch throttle yaw, the others will not be used. and if you set 0, the channel will not be override, it will be controlled by controller. And if you set 65535, it will reserve the data of previous override msg. Then I can change the attitude on the specific axis.
And if I only give the throttle parameter a value. It will still in the air and do not move(ideally).
Hi @Debupt it is great that you’ve had success with this
I just started looking into the same solution.
Can you please share your findings? which commands you input to the fc and how you made the final calculations to the params which worked like an outdoor GPS?
@Debupt, I’m a real newb to arducopter interaction, I saw the two methods you used: the serial NMEA and the mavlink GPS_INPT(#232) command, which worked in the end?
You also mentioned that it didn’t work at first but then you adjusted the “params of pos_xy_p, vel_xy_p and vel_xy_i” what adjustments did you do?
Any hint in the right direction will be really appreciated
Hi,
I’m also a newbie to arducopter.
I would like to use a VIVE controller for positiong my drone in indoor environment (non-GPS navigation)
I already have the position on the companion computer (6DOF - read from the VIVE) but I don’t know how to send this data to the flight controller
@JustFineD, The trick way is that you can convert the VIVE controller’s info (6DOF) to gps info as longitude,latitude and altitude, and send it to drone with mavlink msg GPS_INPUT through serial port. The result may not be that accuracy due to drone’s internal EKF fusion with acc and gyro.
Another way is that you can change the code and avoid EKF fusing these info from your devices or just change the way EKF works according to your device info. This is my understanding, it may not right.
The first way, I have tested using UWB module, the result is not that satisfied. In loiter mode, the drone may drift for +/-10cm.
