Amphibious multi-purpose wireless-control vehicle.

Similar projects worth following
There are many places, like marshes or bogs, where UAVs cannot reach some nooks to inspect what is there. This amphibious vehicle, controlled from your computer, is a good solution for a bunch of similar problems, or simply, to have fun. It's fast, it's fun.

With the collaboration of the Seville Fablab.

The goal of this project is to design an unusual kind of unmanned vehicle with several interesting features. Inspection and surveillance are some of its possible applications.

For a better driving experience, we are trying to add different types of control: totally manual (control direct on motors voltage), assisted control (implementing PID control with an IMU to close the control loop) controlling speed and direction, and automatic control (following a designed trajectory, for example, with Pure Pursuit control).

Streaming system have been done, for now, with an USB Cam (bought for 1€) using ffmpeg for broadcast. The quality of the video is very low, so many information seems to be lost by the way with the wireless connection; so that, the image acquires wrong pixels in many colors (green and pink). Moreover, if the cam spin too fast, the image saturates and do not record well the things, blurred record. It has to be improved.

The structure has been all 3d printed except the top, which has been laser cut. It is, obviously, useless for claiming hermetic close, so that, we have to rebuild this part of the vehicle. It's a fact that the propellers protectors (wood circles) do not hold up the hits that the vehicle will have to carry. We will upload a video with them crashing. So fun.


Guide of the used controllers (rather than Turnigy ones). It has been taken directly from

Adobe Portable Document Format - 2.15 MB - 06/11/2017 at 17:11


  • 2 × Brushless Motor A2122
  • 2 × 20A Speed Controller for Brushled Motor Be careful choosing. It has to have three output phases.
  • 1 × Webcam
  • 1 × Raspberry Pi 3B
  • 1 × 1400mAh 11.1V Battery 3 Cells 60 C. Important: High C necessary to no explode.

View all 6 components

  • Root Changes - A New Concept

    Juan Sandubete07/28/2017 at 18:05 0 comments

    We have been thinking on the problems that the project has. It works, more or less, but it isn't pretty nice, so we want to improve it, changing some things that we think are wrong or, at least, are not so good as they could be.

     We want to make  Phoebe more robotic than it is, so we are going to give her some sensors and the capability of analyses them. That will be used for the trajectory generation software.

     But, before we can do it, we have to turn up all the basic systems. These are the lists of things we will do with the project from now.

    Things we have to do (fix):

    - Re-building of the whole structure. Evaluating the possibility of doing it with thermoformed plastic, taking the old structure as mould model.

    - Raspi-ESC electronic interface (3.3V logic to 5V logic). It seems it will be done by using a few transistors (bc535, b545, irfz44n) and not much more.

    - Attachment of the components (Raspberry, batteries and other internal elements) to the structure with Velcro or some adhesive.

    - Hermetic box for critical electronic components.

    Things we want to do (improve):

    - Accelerometer, water detector and other sensors have to be added for the control and automation of the system.

    - Better control using the interfaced made. We are thinking on implementing a PID control in two pieces: linearising the exponential curve that models each propeller.

    - Trajectory Generation. Thus, Phoebe could follow the way indicated from a computer.

    - FPV improvement. It is desired to add two servos to the camera, so that it will be possible to turn it to the wanted direction.

    Advices are appreciated !

  • Running Test Fail 1 - Crashing Phoebe - Repairing Motors

    Juan Sandubete06/12/2017 at 19:43 0 comments

    After doing the tests we do at High Engineering School of Seville, an issued occurred. The protection structure moved forward, so the adjusted distance to the propeller was reduced and it all crushed. You can see it in the video below.

    The condition of the motor is so bad. The wires get twisted and forced, so that, now they have copper visible. We have fixed it, more or less:

    We took out the insulation plastic, un-twisted the wires, added new thermo-retractable insulation and it is more or less well again.

    Although the result seems to be good, we are going to leave it for secondary tests. We don`t trust it a lot, because it is a little tieso. We will check it later.

  • AdHoc Test

    Juan Sandubete06/11/2017 at 21:35 0 comments

    The AdHoc script which you can find in github Phoebe-Adhoc, is valid for both computer and Raspberry sides. It detects itself what part is running it. This is done looking at the core, so you have to check if the code of your Raspberry is BCM2708 or BCM2709. If yours is not one of these, you have to add it in the lines 40 of (Adhoc on) and lines 31 of (Adhoc off). It looks like..

    grep 'BCM2708' /proc/cpuinfo && PI=true
    grep 'BCM2709' /proc/cpuinfo && PI=true
    Adhoc will be explained better in the instructions, but the basic idea, if don-t know it, is a Internet connection based in nodes, without any router, so you can connect two computers directly using the wi-fi modules they have.

    Once we turned on Adhoc, we first easily checked it with the command iwconfig. Others connections are turned off with our script, so the unique connection we had to pay attention was that. Is so important to check that, with iwconfig, a cell is shown in the adhoc connection. It means that almost everything is ok.

    After one or two corrections in the script, we could make a ping check. So, it works !

    Note. Adhoc connection is important because is what we use for both TCP and UDP connection. TCP for control, UDP for monitoring.

    If you know about others ways or you think something can be done better, let me know !

  • Making off Phoebe

    Pelayo Gutiérrez06/11/2017 at 18:30 0 comments

    In order to build Phoebe we went to our local Fablab because we want it to be replicable in any of the 1150 fablab around the world or any other profesional or maker hacklab.

    So we decided to 3D print the main structure of Phoebe, the hull with some pieces to line up, the motor support and two protection rings for the fans. The full print was around 60h of printing in 3 deferents machines, an ultimaker original for the fan cover and the line up pieces, other machine made in the fablab for some clips for the cover of the hull, and the hull was fully printed in the reliable P-minifab designed and build there.

    The assembly of the 3D printed parts was made with two different welding technique, friction welding with a dremel tool and adding fused material with a 3D pen. The decision to use this techniques was simple, is better to fuse differents layers with the same plastic than adding glue from other material.

    At the end in order to ensure the protection from the fans and to cover the cavity of the hull we add a different fan cover that was laser cut from 5mm MDF.

    The designs of all parts were made in FreeCad, the open source Cad program for parametric modeling with the idea to modify and scale the models to any size required to suit any personal necessity.

    We still have to add the resin and fiberglass for claiming impermeability, so we could do the water tests.

  • First WebCam Streaming Test

    Juan Sandubete06/11/2017 at 17:35 0 comments

    The streaming has been done, for now, with the program ffmpeg, installed in the Raspberry and computer both parts. The installation way can be seen in the phoebe github, in the ffmpeg folder. One of the texts are the instruction. I will write another instructions more detailed later.

    Once installed, you only have to configure the program to take the video data from your webcam and pass it in rtp protocol (that uses UDP protocol) to the destiny IP address, followed by ":" and the port to which you want to transmit.

    This is the command I used:

    ffmpeg -f v4l2 -framerate 60 -video_size 640x480 -i /dev/video0 -tune zerolatency -f rtp rtp://

    The framerate have been put to the maximum since, with udp protocol, a lot of data is lost in the way, so you have to send as much as you can for receiving a decent quality image in the computer.

    The IP address taken was the IP which the computer had with the AdHoc connection, that will be explained in the instructions later.

    These are the results:

    The latency is about half second. The quality is so low, so we have to improve it. More ways will be tested with the same or different programs (We accept suggestions !).

  • First ESC Test

    Juan Sandubete06/10/2017 at 17:04 0 comments

    Two weeks ago, we tried to turn on the motors, supplying them with a 10A 12V power source. The power it gave was not enough for both motors, so we had to try to test them one each time.

    Problems determined:

    -ESC calibration fails several times with the Raspberry Pi 3b software generated PWM. We were using 10A Turnigy Speed controllers back that. Calibration is done by giving it the higher voltage value until it beeps, and then, turning it into the lower voltage value used (look a the SimonK archive for the calibration of the 20A ESC). The beep code depends on the ESC used, so be sure you are using the one of your ESC.

    We could finally got it with the first one. The results can be watched here:

    With the second one, there were several calibration problems. It seems to be due to the bad PWM generated by Raspberry Pi 3B software.

    The speed controller thought we were trying to make him works rather than calibrating, so...

    - 10A Turnigy ESCs seems to not be able to control the power of these motors. In the second video this fact is obvious. So it is necessary to change to 20A ESCs for managing enough intensity.

View all 6 project logs

Enjoy this project?



KimPeek wrote 06/13/2017 at 16:41 point

Have you tried it with a rudder? It seems it would be easier to control with a rudder vs two props. Another alternative would be to mount both props onto a servo and use thrust vectoring.

Might be better to use two props if you were able to control the pitch of the prop blades. You need a spectrum of control between the lack of propulsion when the prop is turned off and the excessive propulsion when the prop is turned on. ESCs don't give enough low speed control. Seems to be an "all or nothing" situation with the steering in this setup.

  Are you sure? yes | no

Juan Sandubete wrote 06/13/2017 at 17:34 point

Hi KimPeek,
We haven't tried it yet. We want it to be as
cheaper and easier as possible, so we reduced elements. Furthermore,
adding servos and mobile parts for the fans, it would become less
robust, is not promising for us.
Are you talking about the
presentation video? I know is a shoddy work (the video and the control).
The control implemented is not an "all or nothing". The curve of the
motors is an exponential one, so when you try to control it manually, it
all goes shit. We have written a logarithmic control to linearise the
exponential for having a better manual control, but we haven't tested it
And that what you say is possible. I don't know if the ESCs will work ok with low currents, or better said, if the motors will work well with low currents, so we will try next week (I hope) and, if it doesn't work, we will have to think alternatives as you say.

Regards !

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates