Path Planning with Ardupilot - Niklas #3

OVERVIEW

This post covers our starting point on the topic of path-planning, how far we are with it’s implementation and how we got there. It also includes information of the software suite ardupilot, purchase recommendations for needed hardware and a small wiki of useful links I wish I had known earlier.

This post is – apart from providing purchase recommendations – designed as a first step into ardupilot, with particular focus on USV implementations. (USV = unmanned surface vehicle)

Let’s get things started!

STARTING POINT: WHY WE NEED PATH-PLANNING

Our project – let’s name it “THE USV” during this post – should not just be unmanned, but also autonomously. Autonomously control means in this context: Drawing waypoints on a map in some UI. The USV follows them instantly. The “some UI” shall be a widget from the Ubidots Dashboard.

With this, we reach our first obstacle: Ubidots does not provide on board waypoint functionality. Therefore, our project leader Jason came up with ardupilot. An open source software suite, capable of autonomously controlling vehicles, may solve this little issue. I and Dylan would work on implementing ardupilot.

HISTORY OF WORK WITH ARDUPILOT

Getting picture of ardupilot

The first Task would be to get a picture of what ardupilot actually is. There is a ton of information about ardupilot online, still it is confusing to understand how ardupilot actually works. After some hours of research, we found several specific drone builds, though it was still unclear how ardupilot would fit in those. Moreover these builds were mostly intended for drone builds, whereas we needed a boat build. After some time we found a YouTube playlist (https://www.youtube.com/playlist?list=PLuteWQUGtU9BD_vxTEZy8tP8FF4zE2VJH), describing how to simulate path-planing with ardupilot on a Linux machine. I tried to replicate that. Meanwhile Dylan was getting a better overall picture of ardupilot. (What would turn out to be very useful later on)

Simulate path-planning

Setting up simulated path-planing on Linux appeared straight forward. No real issues setting up what seemed to be a server, dummy drone, a proxy for communication and the Mission Planner. The UI. But when it came to setting up waypoints, running these applications on Linux turned out to be very buggy and unreliable. Running a simple python script to feed Mission Planner with waypoints did not work out.

During a buggy representation of my work, we got – thanks to Dylan’s research – a glimpse of ardupilot’s structure.

Our next step should be, getting a simulated device running on Windows. That turned out to be way easier to accomplish. (Mission Planner was designed for Windows)

To figure out how to implement drawing Waypoints with Mission Planner on a real device, we needed to do more research on that topic.

Getting picture of ardupilot 2

At this point, the other teams had already working Open-CV on localhost as well as WIFI and simple GPS connection from a Micro: Bit to Ubidots using XInABox (System of chips expanding functionality of Micro: Bit’s)

During our new research on ardupilot, we got a better picture of it’s actual structure. We would need additional hardware, supported from the ardupilot software suite. The next step would be to research hardware and provide purchase recommendations.

STRUCTURE OF ARDUPILOT

Ardupilot is a Software suite, (collection of software that tend to communicate well with each other) providing software for vehicles of all kinds, as well as the controlling devices.

Following the steps on these pictures, Mission Planner is the (a possible) controller. Provided one uses

• supported hardware (for example a Version of Pixhawk)

• with a supported OS installed (for example Chibi OS)

• and connection using telemetry radios on the PC running Mission Planner and the Hardware,

Mission Planner can flash the vehicle specific firmware (ardupilot) on the hardware. Afterwards, it is possible to connect to the hardware continuously – using the telemetry radios – and draw waypoints, control the device manually, setup repeated paths, etc.

Needed steps for a ardupilot setup

1. Get a Flight controller (for ex. A Pixhawk cube + carrier board), connecting cables (mainly for power supply), power supply, additional sensors (if you need them) and a connection device (for ex. telemetry radios)

2. Wire Hardware together

3. Install Mission planner (or other GCS)

4. Connect Mission planner to flight controller and flash firmware (for ex. ArduRover that can be used for boats) on the flight controller

5. Plan Mission

Variations of Ardupilot builds

The ardupilot community classifies 4 different build category’s. Sorted from easy to build (TOP) to just not achievable by amateurs (BOTTOM), they are:

1. RTF/R builds:
   

   Also “ready to fly/run” builds. All needed parts are already assembled. You can buy them in an “all in one” pack. Easy to setup but very costly.

2. ARF/R builds:
   
   These builds (“almost ready to fly/run”) typically just provide some basic electronic components, meaning the “brain” of the system and the frame. Everything else, so power supply, transmitter and sensors need to be assembled additionally. Can cost less then RTF/R builds

3. Frame builds:
   
   Seemingly just provide the frame, nothing else. Not recommended for amateurs, because they generally don’t know what else they need. Build without knowledge, they can be way more expensive than RTF/R or ARF/R builds!

4. Scratch builds:
   
   Just nothing then a description. Not recommended for anyone, who is at the point of reading this article.

RECOMMENDATIONS

Before considering one of these recommendations, one should be aware that they are based on actual builds, but are no copy of those. Therefore, there is a good chance, that additional hardware would be needed later on. (especially when connecting to Ubidots). Furthermore, these recommendations assume that one is lacking almost all needed hardware. (except thrusters and power supply in our case)

The prices for these builds are estimated, based on prices on similar recommendations. The may differ. I assume about 90 € of additional hardware for each build (already included)

Recommendation 1: about 300 € to 400 €

The best recommendation I can give, is to buy a set with

• Pixhawk 2.1: Cube Black + Carrier Board (are normally sold together),

• telemetry radios (for connection),

• power module (so that power supply can connect safely),

• external GPS (not necessary. The cube should provide it. But more accurate for path planning)

Maybe a separate power distribution board (PDB) for multiple thrusters. This is probably not included in any set, but likely useful for our USV build.

REASON:

It should provide all functionality needed, has very good support (Pixhawk cube), good chances for support over many years and should be quick to assemble. Also, it is very modular, should additional parts be needed. Nevertheless, this is by far the most expensive set of my recommendations.

Recommendation 2: about 230 € - 320 €

• Pixhawk 2.1: Cube Purple + ProfiCNC/HEX Mini Carrier Board

• remaining parts similar to Recommendation 1

REASON

The purple Cube is similar to the black one, but designed for USV’s and UUV’s. The price is significantly lower (because no need for stabilizing hardware) and it’s functionality is more adjusted to boating systems. Nevertheless, I could not find many build with it. (see "Small boat using pixhawk O" in wiki)

Recommendation 3: about 180 € - 270 €

• Pixhawk Original (does not need a carrier board)
  

• remaining parts similar to Recommendation 1

REASON

The original Pixhawk is the most used, oldest and stable. It is less expensive than newer models (for ex. Cube). Also there is very much support for it online and many builds (also USV’s) using it. Nevertheless, the producing company slowly distances itself from the original Pixhawk and focuses more on the Cube Variations. There is a good chance of lacking firmware support in the future. Also it is still not clear to me, how it actually works.

Recommendation 4: about 200 € - 290 €

• Navio2 + raspberry pi
  

• remaining parts similar to Recommendation 1

REASON

This build is way less expensive. Also there is a strait forward tutorial to set it up. (“Setup Navio2 with Raspberry Pi” in WIKI). Unfortunately it is designed for drones and works on Linux. There is a good chance to run into some bugs, when adjusting it for a USV.

Recommendation 5: about 100 € - 200 €

• Beagle Bone Blue
  

• remaining parts similar to Recommendation 1

REASON

This is the cheapest build I could find. That’s actually the only reason for it. It needs additional GPS, is designed for drones and works on Linux. I am not even sure about the support. Though, there is information for it available and I am sure with enough patience, time, planning and research, it can be useful for as USV. (or a drone)

LONG TERM BENEFITS FOR FUTURE PROJECTS

Though Ardupilot Software is released 2009 and therefore rather young (if 13 Years is young for Software...), it has a large community. Also Ardupilot projects are designed to be very modular (and interchangeable with a bit effort). Therefore, working parts of a project have a good chance to work in another one, even if the new project is designed for different vehicles (or just robots).

WIKI OF LINKS

WIKIS

• ArduPilot itself

• Pixhawk Original (and cube too)

RECOMMENDATION PAGES

• Recommended flight controller for drones

EXPLANATIONS

• Pixhawk 2.1 (Cube) (Video)

• Pixhawk 2.1 (Cube) (text)

• Pixhawk O (original)

• Structure of Ardupilot (Video)

• Setup Rover (also USV)

• Setup Navio2 with Raspberry Pi

SUPPORTED STUFF

• Ardupilot supported Hardware

EXAMPLE PROJECTS

• Small boat using pixhawk O

• More advance boat using pixhawk 4 (and our thrusters)

• Simple boat using Omnibus F4 Pro