Want to do indoor non-gps-navigation in guided mode with mavros.
Velocity commands are sent by ROS navigation to FCU with SET_POSITION_TARGET_LOCAL_NED messages,
global localization is done with ROS 2D lidar SLAM package, but not sent to FCU.
Cannot switch to guided mode without GPS being locked at least once.
I follow these instructions, to configure ArduPilot.
I try both EKF2 and EKF3 with the same result.
I set EKF origin and home position by sending SET_GPS_GLOBAL_ORIGIN and SET_HOME_POSITION messages through mavros.
Although EKF origin is set, I still cannot switch to guided mode, because, as debugging shows, while requesting EKF position here, none of the EKF-s is reported active and
get_position returns false and, as the result, FCU refuses to enter guided mode here.
Sending VISION_POSITION_ESTIMATE message doesn’t help too.
Any ideas on what is done wrong?
Thanks for looking into this.
So I guess this vehicle has wheel encoders on it but ROS’s position estimates are not being sent to AP right? I guess you’re thinking that AP shouldn’t need to know it’s position accurately, all it needs to do is respond to velocity commandy from ROS/mavros? I’ve never thought of this configuration but I agree it should work.
I’ve tested wheel encoders a couple of months ago and it worked so I’m a little surprised that you’re finding it’s not working now. These are the instructions to follow for wheel encoders for Non-GPS navigation. I guess you’ve followed these?
Yes, rover is equipped with wheel encoders.
Yes, ROS doesn’t send any position estimates to FCU. This shouldn’t be a problem, as FCU uses wheel encoders itself to compute its own position in relative aiding mode.
Yes, I want FCU to respond to velocity commands from ROS.
Yes, I followed the instructions and turned off GPS use.
As described in the github issue, the problem is that FCU cannot start relative aiding with wheel encoders, bcz the latter are not reported as alive bcz of that comparison.
Probably, with other configurations wheel encoder readings come earlier than the IMU readings, and the comparison works ok. But in my case, it’s the opposite, so, it doesn’t work.
Why just don’t use correct timestamp comparison? I see this type of incorrect comparison very often in Ardupilot code. Is there some intention behind this?