Debugging malfunctioning cruising state mode

07-17

Line 40 test fail issue with the calculation of waypoints.

Note that the PM cruising algorithm can only be applied to fixed wings. The takeoff and landing algorithm can only be applied to quad.

On CrusingStateManagerTest.cpp line 113 both tests did not pass. Both the results are different from expected. Note that this test checks the desired track straight. So the path that is calculated should be for straight lines.

PM_CruisingStateManager.cpp line 131 the waypoint_type variable was commented out and on line 137 the waypoint_type is hard coded to be PATH_FOLLOW (data->waypoint_type = PATH_FOLLOW; ).

PM_CruisingStateManager follow_last_line_segment(line 389), follow_line_segment(line 355), next_waypoints(line 265) is where the math takes place. TODO figure out what they do and see why the math is not correct.

07-24

Added the below print statement to see what values were calculated (then realized that they are already printed ) :

Results:

Open

Results from the first test and second test

Since the DesiredTrack and DesiredAltitude are both 0, I think that the issue is just that they are never calculated but I can’t find the line that is not calculating. However I am going through the function calls and it seems that they are being called and performing calculations.

Open

Math for calculating upcoming waypoints

TODO: Do the math manually to see how the calculation is done (bruh i hate math)

Quick Overview About Waypoint Manager Math

Waypoint manager math breaks down into three big chunks: Straight path following, orbit following, and blending of both.

Straight path following

Given two points, get a line in-between.

• If given XY direction, calculate the line’s direction using trigonometry.

• If given GPS coordinates, convert them into XY coordinates using Haversine formula.

By subtracting the two XY coordinates, you’ll get direction vector. We have XY coordinates, and a direction vector. Applying atan (Recall SOH CAH TOA) gets you the angle of the track. 2 pi corrections can be done at this point.

Planes can get slightly off the track due to environmental factors or mechanical factors- that’s when cross-track error kicks in.

Cross-track error is the distance between the plane and the line that connects two waypoints.

To resolve the error, we would have to apply a correction factor, desired track. If the plane is close to the line, redirecting its heading to perpendicular will cause the plane to directly cross the line, causing the same issue.

Thus, we will have to adjust the angle of its heading depending on how far the plane is from the line. The farther the plane is from the line, the angle of redirection gets closer to 90 degrees.

Orbit Following

Follows the curvy path of certain radius, either in clockwise or counterclockwise direction.

To maintain radius, we need to calculate Euclidean radius:

where:

• position[0] → x coordinate of plane’s current position

• position[1] → y coordinate of plane’s current position

• center[0] → x coordinate of orbit center

• center[1] → y coordinate of orbit center

To put it simply, we’re just computing

This.

This orbit distance is then used to compute the cross-track error but for curve. Atan is used once again for the similar reason as the straight path follow.

 The arctan function ensures the track converges onto the orbit. The direction of travel lambda, either 1 or -1 (They represent counter or clockwise direction), counteracts track perturbations and is then added to the course angle as a perturbation. Note that a gain value must be tuned for the convergence rate.

The course angle can be determined by the vehicle's position on the orbit.

If the plane is in the first quadrant of a counterclockwise circle, the track ranges from 270° to 0° (On the right positive x-axis).

The course angle is calculated using:

Blending Following

Blending mixes two methods together and use them when needed. Path will be straight, so we use straight path follow. However, to travel the corner, we’d need orbit path follow because, unlike quadcopters, planes can’t make a straight 90 degrees turn to travel a corner!

To find the tangent (two lines tangent to the circle), we use trigonometry.

And now we’ll find the turning angle using dot product of two vectors. The formula is:  

where:

• Index 0 is the x-coordinate

• Index 1 is the y-coordinate

• Index 2 is the z-coordinate

We consider ‘boundary’ as a checkpoint to switch the turn from straight path following to orbit path following, and vice-versa. To tell if a plane passed the boundary, we use dot product formula:

Note: if the value is positive, that means they passed the boundary. The direction vector here are normalized. Path index incremented when they pass checkpoints.

TLDR: The dot product of two vectors are a⋅b=∣a∣∣b∣cos(θ). By checking the sign of the dot product before and after movement, you can determine if the vehicle has crossed the plane. D=(x−x0​)⋅(current position – halfplane) will hold positive value.

Code Breakdown

To determine the desired track and altitude, we get GPS coordinates (latitude, longitude), altitude, then a track. Formatting is done by the sensor driver.

So when you are given an input like this:

It simply means :

We are assuming that the flight path and home base is already initialized in this test.

Let’s look into more detail:

When you go to the pathFollow function, it calls a function called ‘get_next_directions’.

This simply allows you to get the next direction using waypoint manager logic. We introduce a new array called position. We then call a function to get coordinates.

Get coordinates calls get distance. They calculate longitude and latitude relative to defined origin, and output it into position[0] and position[1]. In this case, xyCoordinates[0] and xyCoordinates[1].

As I mentioned, to convert XY coordinates, we need to calculate Haversine Formula. Why do we need Haversine formula? Because Earth is not flat and square, it is spherical. The distance between two waypoints lies along the spherical surface - This is called the great-circle distance.

Earlier I said that we receive inputs from Telemetry Manager and store it in Waypoint buffer. In our test, we have pre-defined custom data we feed to the system for the purpose of testing without using RTOS and actual board and setup. We modify the path using editFlightPath function. This will assign necessary information to the system.

Now we proceed with the next line in get_next_direction function, follow_waypoint.

Because we have our test waypoints fed to the system, you’ll jump to next_waypoints.

This part is pretty self explanatory, it defines current waypoint, target waypoint, and the waypoint after the target waypoint. The altitude of each waypoint, in case of input1, will be 10, 20, and 30.

We would then calculate direction to waypoint. It calculate the direction by computing the norm first, and dividing the difference between two waypoints by the norm.

We now compute turning angle and tangent factor to compute half plane. Refer to orbit following for details.

We then compute distance to next waypoint. This function simply computes the distance between the current waypoint and next waypoint.

We would then receive orbit status from TM. This will decide whether we will be computing follow_straight_path or follow_orbit_path. For math, refer to the straight path and orbit path follow section. In our test case, we only follow the straight path.

The error with desired track and desired altitude was so simple yet so weird.

You just have to assign the output variables to the values.

Python Haversine formula simulator

import math