@Carlos_Vicente@Henrik Atually with Ardurover it is manadatoy to initialize the EKF with a geographic_msgs::GeoPointStamped message. Otherwise it is not possible to arm the rover. And I am almost sure it is the same for any kind of drone (quadcopter, boat or rover). here is the piece of code I implemented:
rover_set_gp = nh_.advertise<geographic_msgs::GeoPointStamped>("/mavros/global_position/set_gp_origin", 10);
std::cout << "Set INIT KF GPS\n";
// need to send a specifi message to initiate the EKF on ARDUROVER - otherwise we cannot arm nor switch to GUIDED mode
geographic_msgs::GeoPointStamped geo;
geo.header.stamp = ros::Time::now();
geo.position.latitude = 0;
geo.position.longitude = 0;
geo.position.altitude = 0;
rover_set_gp.publish(geo);
I worked on a quite similar project with a copter and you are not far off. The only thing left is a sensor to measure the relative movement. For ardurover to move to the setpoints you publish on /mavros/setpoint_position/local it needs to be able to track the position along the path to the setpoint. E.g. it needs to know if it has reached the setpoint.
The builtin IMU could in theory provide this, but in is nowhere near precise enough.
I guess that the wheel encoders are quite suitable for you. You can also consider the other options on its parrent page. Since you know you are on the ground, maybe you can make do with less radio beacons(eg. ex1, ex2) for 2D localization. I don’t see that it is mentioned in the rover documentation, but for copters optical flow sensors present a quite nice and cheap alternative for this scenario. If you mount any of these below the rover, it should be possible to estimate your position the same way a computer mouse does it. (I don’t know if this is implemented in ardurover)
While still mentioning that I have not used ardurover, I think you can use /mavros/setpoint_position/local. You probably need to take some care with the orientation so ardurover don’t come up with vastly different paths each timestep when you are close to the target. If this gives issues, you can consider to send velocity setpoints in the direction of your cat instead.
Just in case it was not obvious from fabonos answer: You should set the initial position to approxamentley your actual location, not just [0, 0, 0]. Ardupilot uses this location to correct for the distortions in earths magnetic field when using the magnetometer.
PS: Your project sounds cool, just please be very careful not to hurt the cat when testing .
Hi @fabono,
Thank you very much for your answer.
I haven’t created my own nodes up until now, but it will definitely come to that. I was just trying to test it out with out with just what mavros was offering me already. In a nutshell wouldn’t you agree that issuing,
Now I’m starting to wonder if this might be related to the status of my EKF. When I look into your screenshot of Mission Planner with EKF Status, mine has a couple of red flags (screenshot below). On the other hand this red flags could be related by the fact that I have a GPS and I’m currently testing inside, although I did set:
By the way, out of curiosity, and because like I said, I’ll have to create my own nodes for sure, what would you say is the best source to have look into the cpp API for mavros?
Ah yes… of course!!.. Independently of the way we measuring it, we do need to know when we traveled enough distance to get there. Good point!
Last I heard Optical flow sensors are not supported by ardurover yet and the problem with the beacons is that… well… it would only work on places where I had beacons installed (unless I missing something). I think, up until now, the most appropriate solution would be the wheel encoders.
Yeah… it still feels a bit far ahead. But while using Object detection I can retrieve a X,Y coordinates of where the object is in the picture. So, I would have to translate that into the /mavros/setpoint_position/local somehow and be clever with the updates.
Thanks @Henrik! No… I wouldn’t hurt the cat… either way, the RC platform I will be using is a RC crawler type… so. generally they are not fast! :-
Possibly I have to have another look into the variables set. I should be missing something, whenever I’m not using GPS… maybe something related to this page on GPS/Non-GPS transition.
@Henrik, I’ve also realized that actually, using wheel encoders might not be the best option after all. The idea of the wheel encoders is to have a motor for each wheel, for instance, one for the left wheel and another for the right wheel so that we can calculate how much has each wheel traveled at a given instance and estimate its position in the coordinate axis (but you probably already knew this ). Maybe Visual odometry…
Since I’ll be using a RC crawler type with motors already installed (1 for the rear axis and another for the front axis) I guess the whole idea of wheel encoders fall apart.
I still think that you can’t change to guided because it can’t calculate its position. When using GPS it can know where it is, but without it can’t. Setting origin is just a start, you also need something else to get new position updates(e.g. wheel encoders).
Non-GPS navigation is a challenge and will need some extra work. I agree that beacons might impose a too large restriction. However, I am not convinced that visual odometry is less work than retrofitting wheel encoders. You already have a companion computer, which simplifes an eventual visual odometry setup. If you have the budget you could consider the Intel T265 (e.g. this toutorial or this approach. I have tried neither.).
I think the problem may be that EKF2 won’t accept the set-origin command unless EK2_MAG_CAL = 3 (No GPS). This also means that the EKF won’t accept GPS input at all though so if you’re trying to do both GPS and Non-GPS then I think you’ll need to use Rover-4.1 and enable EKF3 and follow the instructions on the GPS/Non-GPS transitions wiki page (that you’ve already found).
I’ve actually done GPS+WheelEncoders for GPS/Non-GPS transitions using just AP and it worked pretty well. There’s a lua script available that helps decide when to switch.
That’s what I was thinking. Moreover I guess it wouldn’t be a simple retrofitting of wheel encoders, because I think I would still need to change the whole mechanics of the crawler to have a motor for the left side of the car and another to right instead of front axis and rear axis, I’m reckin…
EDIT: Actually, after some more investigation I found that could probably get rotary/shaft encoders to equip each of the wheels independently. Sorry about this… I’m back and forth with the plan…
You’re referred to EK2_MAG_CAL, but value 3 means “After first climb yaw reset”. Just double checking if this was the variable that you meant. I have it set to “never” at the moment.
I´m pretty ignorant in some aspects. When you say “just AP”, are you referring to APSync?
Also, can I ask what rotary/shaft encoder did you use? Or… did you use motors already equipped with it?
Ah, sorry, I wrote EK2_MAG_CAL but I meant EK2_GPS_TYPE = 3 (No GPS).
When I said, “just AP” I mean “just ArduPilot”. So no companion computer at all. I used motors which already had wheel encoders equipped (from Pololu.com). The flight controller was a Hex CubeOrange which is powerful enough to run this lua script.
Oh I had that set already in a previous attempt and I just couldn’t change to GUIDED. But I’ll try it again this evening.
But in my particular case I already have the motors installed (rear and front axis), so I’m tempted to use something like this. Unless for some reason you say… “That’s a terrible idea!!”
By the way, you’ve mentioned Rover 4.1. Is that an official release? At least from Mission Planner it doesn’t seem to be available yet, although I can always get it from GitHub and build it myself. Is that what you meant?
I’m afraid I don’t have any experience with wheel encoders besides the one that came pre-installed on these motors.
Rover-4.1 should be available from MP’s Firmware Install screen if you press Ctrl-Q. It has not been official released yet so it should be considered “alpha” code and is only lightly tested by our autotest suite and developers.
Yeah… I’ve tried to provide an EK2 origin, but the FC just ignores me (from both MP and mavros). I don’t even get an error message.
Just to clarify, you’ve said that GPS/Non-GPS transitions only work on 4.1, but if we’re talking about Non-GPS positioning only, will I be able (without setting anything on EK3) to set an origin in EK2 while EK2_GPS_TYPE=3?
Hi @rmackay9,
Yes indeed. I’ve given another go this evening at Rover 4.0, but I think I’ll move toward Rover 4.1. as suggested. I will also give a go on creating own node, at least I will be closer to what I want to achieve for whenever my rotary encoders arrive.
Hi,
This thread has been very helpful to me. Thank you! @rmackay9 I followed all the instructions to setup Wheel Encoders with Rover 4.1.0 , but it seems like the wiki for setting up wheel encoders for Rover 4.1.0 is outdated.
Following is my current setup to make the wheel encoders work:
AHRS_EKF_TYPE = 3
EK3_ENABLE = 1
GPS_TYPE = 0
EK3_SRC2_ POSXY = 6
EK3_SRC2_POSZ = 1
EK3_SRC2_VELXY = 6
EK3_SRC2_VELZ = 6
EK3_SRC_OPTIONS = 0
I also set the home position and EKF origin on the map but the vehicle is still not showing up on the map. Since, the vehicle is not showing up on the map I am still not able to switch to “GUIDED” mode. Please help!
.
(unless I missing something). I think, up until now, the most appropriate solution would be the wheel encoders.
