In steering mode, the transmitter’s heading stick controls lateral acceleration… which means you’re controlling the G force you feel as you go around corners. This should mean it turns faster at low speeds but slower at high speeds. The throttle stick controls the vehicle’s ground speed. So for a given throttle stick position, it’ll always drive at the same speed even if the vehicle is driving up or down hills.
In manual mode, the transmitters heading and throttle sticks go directly out to the motors (after passing through the mixer in the case of skid-steer vehicles). This mode doesn’t require GPS. The steering response, especially at high speeds will be much larger in manual mode compared with steering mode. The throttle goes straight out to the motors so you’d expect the vehicle to slow down while going up hills, speed up while going down hills.
Because testing seems to be going fairly well (knock-on-wood), I’m thinking of pushing Rover-3.2.0 out as the official live version within the next 3 days or so. If people have any objections please speak soon!
The final version will be just like -rc4 but also include these small changes:
send live PID values to ground station regardless of mode (commit is here)
New release… great… but has anyone else been able to use the POZYX system. I get “EKF IMU0 has stopped aiding” while in manual mode. When I switch to auto, I get “Bad GPS Position” followed by “Flight mode change failed”.
I’ve had a look at the logs and I wonder if maybe there is a problem with the update rate and/or beacon data being sent to the autopilot.
In particular the BCN.D1 value (the 2nd beacon) seems to always be 3.389. Also the distances to the beacons don’t seem to be changing very often. It could be that the distances really aren’t changing but I suspect that it’s actually that the updates are very slow to arrive. I think the distance to each beacon needs to arrive at at least 4hz. In my setup I was managing around 7hz.
EDIT: Paul Riseborough will also have a peek at your logs…
Thank you for your answer. This is now very clear.
I have a question that is a little off subject. I am looking to understand rover software code. I can write simple arduino and c++ programs however my programming skills are not great however I want to attempt the following.
Do you know of any tutorials that really explain in detail the ardurover code. I need an overview of how the main elements of the code work.
Also I am looking to find a cut down version of ardurover I want to find the code for a gps waypoint driving rover. I do not need endless possibilities as I only want the rover to drive between waypoints with a gps and compass and to be able to pivot turn and do 180 degree turns at each WP. I ie I want to the rover to navigate a simple grid.
The code can be reasonable simple as I do not need to use the code on may chassis or many different motor controllers etc etc. I will then develop it as a learning exercise. I would like to do this as I think understanding ardupilot would be a major task and will take a long time before I got anything that I can use for my own projects
If you know of something suitable then I would appreciate a link so I can take a look
Of course I will continue with ardurover on my other projects
Thank you! I must confess I’ve modified the Arduino sketch just a bit.
Since I’m a rover, I removed the changing from stage 0 to 1.
I commented out the changing of the TxPower for the anchors & tag. Standard power level works fine.Besides, the change power function didn’t work that well.
I changed the code for get_remote_range of reading the anchor to anchor distances to setting those anchor to anchor distance to what I measured. I did this because there were too many inconsistencies in the doremoteranging function.
I added code to read a rotating LIDAR LITE V1 so my robot won’t run into anything unexpected.
I added code to send all the data from the POZYX & LIDAR Lite to a Megunolink GUI.
As I mentioned sometime ago, I really don’t understand all that is sent by the Arduino to the Pixhawk, so it would not surprise me if my fiddling is to blame. For example, it is my belief that the doremoteranging is just between anchors. If this is wrong, please let me know.
I’m afraid I don’t know of any cut down versions of ardupilot/ardurover. We try to layer and compartmentalise things so the complexity is kept under control but the system as a whole is not simple of course.
Rover can already do the things you’re talking about (driving a grid, pivot turn, etc) so no programming is really required I think… but it’s all open source so do whatever you think is best of course!
I think I’ve found a problem which stops Rover from going into autonomous modes unless there is a GPS. I’m currently testing with the ZED camera and it’s not letting me go into Steering mode. My vehicle is appearing on the map and I’m not getting the “IMU0 has stopped aiding message” so I think there are likely two problems in your vehicle - but one of them I have reproduced and will look into (issue raised here)
THANK YOU!!! Yes I’ve always had that “No GPS” on my HUD . I have seen that IMU0 message.
3 other issues:
I’ve also been having to deal with Compass variance errors. Per the wiki page you previously mentioned, tweaking the EK2_YAW_M_NSE seems to have helped… at least yesterday… not today.
I looked at my D0 thru D3 values in the log and it makes no sense. Assuming these are anchor to tag distances, then something is wrong. As I manually drive around, I’m sending D0 to D3 values to the Pixhawk ranging from 300 to 7000 mm. But the logs values do appear to be constant with an occasional small “burp”.
While in manual mode, I can track my movements on the MP, but the tracking is still 90 degrees out of whack. I’m still experimenting with the Yaw.
Yes, I’m afraid ACRO requires the GPS (or wheel encoders or visual odometry) because the pilot’s throttle controls the vehicle’s speed. This is also important for the turn-rate controller because, on regular non-skid-steering vehicles, the turn-rate needs to be scaled by the vehicle’s speed.
Yes, the D0 ~ D3 values should be the distances to the beacons. One of them seemed stuck which doesn’t seem good. I haven’t personally tested the Poxyz since I made this video but it should be working. I can try to test it in the simulator again.
There’s a hardware issue with some early Here GPSs in which the heading is off by 90 degrees if the Pixhawk/GPS is unplugged and plugged in again within a few seconds. Normally if you leave the Pixhawk/GPS for 10 seconds before applying power again the issue doesn’t happen. Also if you’re using a very new Here GPS HEX recommends setting the COMPASS_ORIENTATION to Pitch270Yaw90 (or somethign like that) but that’s not necessary with Rover-3.2 which has the orientation defaulting correctly.
Yes, I’m afraid ACRO requires the GPS (or wheel encoders or visual odometry) because the pilot’s throttle controls the vehicle’s speed. This is also
important for the turn-rate controller because, on regular non-skid-steering vehicles, the turn-rate needs to be scaled by the vehicle’s speed.
To be clear here - at the moment we require position for Acro mode.
It’s been released. The ardupilot team doesn’t actual control the “ardupilot-copter-blue” package, we have an autobuilder that builds the firmware and then ground stations generally fetch it from there. Linux releases are a bit different though because more is required than just the binary so I suspect Emlid has created that package so they will need to update it I think.