Blogs

As shown in this video, I connected the UART of an Acro Naze32 flight controller to an Arduino Mega, and used the pitch values (pitch, get it?) from the IMU to modify the pitch of a buzzer. 

You can download the code for this example from github.

Dear DIY Enthusiasts,

the team working on the development of the airship-drone ObliX now has an officially registered logo and name: 

With the new name also comes a completely redesigned website with the new address www.aerobotX.net and lots of exciting new content. Have a look at our “ObliX -vs- Octocopter” comparison on the airship page, browse through a beautiful library or even apply for one of the jobs offered on our join page.

You have found a mistake on our website or have an idea for improvement? Please let us know! 

Very much looking forward to your feedback!

Daniel and team aerobotX

From Hackaday:

For his Hackaday Prize project, [tlankford01] is using RC planes and UAVs as an anti-poaching system for rhinos and elephants. It’s a laudable goal for sure, but the conditions of this use case make for some very interesting engineering challenges.

The design goals [tlandford] has set are relatively simple for a bush plane, but building a plane that can fly 200km with a 6kg payload and return to base is a challenge that isn’t usually taken up by RC enthusiasts. For this project, [tlandford] is using an entirely 3D printed airframe, with living hinges printed right into the control surfaces. That in itself is pushing the limits of amateur airframes, but [tlandford] isn’t stopping there.

This UAV system will be completely automated, with a single ground control system taking care of controlling a swarm of planes, pointing a tracking antenna, and connecting to the Internet for observation or control from anywhere in the world.

The project that has seen a lot of improvement since it was entered in last year’s Hackaday Prize. The addition of a completely 3D printed airframe is a big one, and replacing the RVJet with something that looks a bit more like a glider should increase the loiter times over the target. There’s a video of the Icarus flying available below. If you also have a UAV project entered in The Hackaday Prize, there is now one obvious choice of what music you should use.

Here's the original post:

Project Icarus is a solar UAV that is challenging endurance records for airframes under 5kg. The airframe is a proven long range plane that is capable of multiple mission payload and power setups. Icarus 3.0 in its full form is a solar uav and is capable of other hybrid power systems such as hydrogen. For the 2015 Hackaday Prize, we will complete the third version of the project and will place the plane in service in wildlife refuges around the world.

There is a lot of catching up to get this listed so others can replicate what we are doing. We will be trying to add to and update this daily. Thank you for looking out for the project and if you would like to help in any way please feel free to give me a shout.

Overview:

 

Icarus 3.0

A. Long Range >200 km

B. Long Endurance >180 minutes

C. Payload >6 kg

D. Custom Image Recognition Software

E. Fire and Forget autonomous mission from launch to recovery

F. TCP/IP Cloud Control for observation or control from anywhere in the world

G. Simultaneous Mission Capable

F. Fully 3D printed airframe

 

Ground Control Station

A. Single or Multiple Users

B. Cloud Capable

C. Permanent Station and Man Portable Solutions

D. Automatic Antenna Tracking

E. Satellite Communications

F. RTK GPS Centimeter Accurate Solution

G. Onboard HIL Simulation Training Support

H. Swarm Control

COMPONENTS

• 2×Odroid U3Unbuntu Linux based embedded processor
• 1×Range Video RVJET Flying WingAir Frame
• 2×Piksi RTK GPScentimeter accurate RTK GPS
• 1×Cyclops C UAVAir Frame
• 2×Pixhawk APAutopilot
• 2×DroneDeploy Cloud CommunicationsMobile Network communications
• 2×Iridium 9252Satellite Modem Communications
• 2×Machine Vision USB CameraMultispectral MacIhine Vision for ID Software
• 2×Thermal Imaging CameraMachine Vision for Night Ops
• 2×RFIDto be determined

From IEEE Spectrum:

We live in California, and we’re trying to grow some food in a field, but we barely haveany water. In order to grow plants most efficiently, we’d want to be able to measure moisture levels in the soil to make sure that we’re not over or under watering. Assuming that we’re looking for a better solution than a human to walk around probing the soil all the time, we could try to have a mobile robot do the same thing, but that can be tricky and probably expensive. Another option might be to put sensors in the ground all around the field, but then you’ve got to buy the sensors, power them, and do some sort of fancy wireless thing to get them all reporting back.

In a paper recently posted on arXiv, a team of researchers has proposed a hybrid approach using long-range UHF RFID sensors that are dirt cheap and require no power source, combined with a mobile robot that can talk to them. Is it the best of both worlds? Yes. And does it work? Yes. It does. Maybe.

Radio-frequency identification (RFID) tags consist basically of a chip and an antenna. Most tags don’t have their own power source; instead, they’re powered by the radio frequency emissions from any antenna that tries to read the tag. Essentially, you get a free transmission of a small piece of information from an unpowered tag to a powered antenna, and this means that the tags themselves can be manufactured for next to nothing. By hooking UHF RFID tags up to low power sensors, you can collect a little bit of data and transmit it to a nearby antenna whenever that antenna is in close enough range to power the RFID and sensor.

The researchers (Jennifer Wang from MIT, Erik Schluntz from Harvard,Brian Otis from UW, and Travis Deyle from Duke) show how a mobile robot could zip around and remotely read a whole bunch of these ridiculously cheap RFID sensors spread over a wide area, giving you an outdoor Internet of Things that you can quickly deploy and will cost less than other approaches.

This is a picture [right, top] of what one of these UHF RFID tags looks like. The tag shown here would cost less than US $0.10 at scale, and can operate indefinitely. Compared to something based around a system like Bluetooth Low Energy, RFID is at least an order of magnitude cheaper, potentially way smaller, and will probably operate much, much longer. The entire sensing system (including the resistance probe) might run you about $1, in volume.

Once you’ve got your pile of cheap RFID sensors, here’s how the system would work: you walk around and stick them in your field wherever data would be useful [right, middle]. You only have to do this once, and you can place a whole bunch of sensors, because of their low cost. As you place each one, simply note its GPS coordinates. To do some data collection, pick your mobile robot of choice (the researchers used both a quadrotor with an antenna mounted underneath and a RC car modified to work as a UGV), and have it wander around to all of those GPS coordinates. When it ends up at one, it activates its antenna, and the RFID tag on the ground sends back data [right, bottom].

How well does this technique work? In technical terms, it works pretty well, but developing it further into a commercial system would require some improvements. The challenge in reading a passive UHF RFID sensor tag is that your antenna has to be positioned fairly close to the tag: in the configuration that the researchers used, the best case read distance was about 1.3 meters, which is well within the position error of a standard GPS system. Also, the tags have to charge up with power for some time (a second or two) before they’re able to transmit any data, so you can’t just zip past them and expect to pick up a measurement. Consequently, their quadrotor wasn’t able to autonomously read any of the tags, although the team managed to get reads on all of them under manual control. The UGV fared better, partially because the antenna was positioned at a favorable height. Based on autonomous GPS waypoint navigation, the UGV nailed two-thirds of the tags.

The researchers say that both challenges (power and range) may be solved as RFID technology improves. In fact, the RFID tags already used in some highway toll systems can charge you money even if you drive by them at 10 mph over the speed limit. Solving these issues, however, wasn’t within the scope of this research, and a lot of other research has been done on how to make robots navigate between waypoints more accurately. Since both of the mobile robots were able to read all of the UHF RFID tags while being manually controlled, the point is that the system has been shown to be useful and viable, even though the navigation bit still needs to be figured out.

Apart from just sensing tags, mobile robots can also place tags, and since the tags don’t require any infrastructure (batteries or WiFi or whatever), you can stick them (or drop them) anywhere you think they’ll do the most good. At ten cents a tag, this is where the Internet of Things starts to become really, really powerful: through a dirt cheap, scalable, infrastructure-free way of adding sensors to the world with robots.

[ arXiv ]

We have spent the past year developing a system to fly drones over the internet. We now have a hexacopter that can be flown from anywhere in the world using a joystick via APM Planner or Mission Planner (working on an iPad app as well). The latency is below 500 msecs and the video quality is 720p w/ 25fps. Obviously the flying requires the drone to be flown at a location with decent cellular coverage but we have been optimizing the platform to handle the inconsistencies inherent in cellular data connections by load balancing the data between multiple LTE radios. A single cellular modem is just not sufficient for true FPV flying. The F550 is piloted using APM planner and a joystick right now but will transition to the iPad app once we have finished testing it. All the video and controls are routed thru a central relay server so there is no concern about firewalls, VPNs or IP addresses. We have tested the system cross country flying from San Francisco with the drone over a field outside Boston. It has been a lot harder than we anticipated but the system is working very well right now and we are looking at ways to commercialize the technology.

Any ideas or feedback would be appreciated. 

Here's a quick glimpse of the current vibration and motion testing of the Solo gimbal in our Shenzen factory. Still on track to start shipping around the end of the month. 

From Trossen Robotics, news of a nice hack turning the one-dimensional LIDAR-Lite laser rangefinder into a proper 360-degree scanning LIDAR unit:

One of our favorite roboticists, r3n33, has been up to some magic with lite and mirrors. R3n33 has used a spinning mirror to get a 360 degree view with a LIDAR-lite sensor, without moving the sensor itself. The results speak for themselves, but here’s what r3n33 had to say about it:

This is my idea for using the LIDAR-lite sensor to produce readings in (as close to) a 360 degree view without spinning the sensor itself. I decided to start this project to give some life to my sensor which had never had a real purpose until now.

Thanks to my 3D printer I was able to quickly produce a “rig” to hold the sensor over a mirror. The mirror is attached to a 3D printed plate that is designed to hold the mirror at a 45 degree angle. This will allow me to bend the light 90 degrees from the sensor’s emitter. The mirror holder is attached to a stepper motor that will allow me to rotate the sensor’s light in a 360 degree view.

Before I go on I’ve presented a few issues.

Blocking the view. To hold the sensor over the mirror there will be an arm somewhere in the 360 degree view. I’ve already taken some action here and removed some of the arm material. In fact if I remove too much more the PLA plastic I’ve used won’t be rigid enough to hold the sensor still.

The mirror has to be quite large. This is something I discovered along the way. When it was just an idea in my head the mirror was really small but to ensure both the emitter and receiver are 100% in view I had to use the size you see.

Knowing the mirror position. Because I’m only using a stepper motor for this first design I get no positional feedback. I’ll have to assume the mirror position by starting the motor and firmware at a known point.

Reading accuracy. By bending the light alone there is going to be a small offset introduced. Then there is the ever changing distance of the mirror as it rotates. I chose to align the emitter of the sensor to the center of the mirror. This ensures the light will project in a parallel plane. When the light is received it might bounce off the high side of the mirror in one direction and the low side on the other. I may or may not concern myself with such slight offsets introduced in the readings.

No aerial category this year, sadly, but the Sparkfun Autonomous Vehicle Competition rover race was even fiercer, due to the crazy Discombobulator turntable challenge (below). Winners listed here.

From the Event 38 blog:

The creator of the cool Flutter processor/wireless board (1km range, Arduino compatible) that launched on Kickstarter a couple years ago is now shipping the board. He's also porting APM code to it, to make a drone with long-distance wireless comms. He's looking for help, so you can follow/participate in the project here. 

As someone who came from robotics to the RC side of drones I discovered that there were many things that I found not that well documented. The learning experience over the last 2/3 years taught myself and my team many things thereby a few weeks ago we decided to launch the Ubuntu DIY drone kit, a low cost kit available in red/white and yellow/black aimed for people that desired to build themselves a Linux (Ubuntu) drone with instructions and material to do everything step-by-step.

Today we present here our experience. Everything is based on technologies supported and sponsored by the Dronecode Foundation:

The assembly guide has been written with few assumptions in mind so that pretty much anyone can build their own smart drone (referring to the Linux side of it) and the operation manual provides an introduction to the basic concepts of autopilots and APM.

We were excited to see how many people started purchasing this kit thereby we though that it would make sense to organize a local session about "Building your own Linux drone" teaching people the basics about drone assembly and maintenance, APM, GCS and safety aspects.

The course duration was 2 weeks and it has been a complete success. We've had 15 students and they all were really satisfied. We closed the course with a visit to Erle Robotics and introduced slightly the engineering side of what we do.

Many thanks to Lander and David for a fantastic work supporting the course. Those interested in reproducing this experience can get in touch with us at https://erlerobotics.com/blog/dronedu/. We'd be happy to share material and additional content.

I'm personally quite interested in what the community thinks. Are there any previous experiences? Any advice on this side? Anyone interested to take over this initiative and reproduce it somewhere else?

Links:

• Ubuntu DIY drone kit
• Ubuntu DIY drone page
• Ubuntu DIY assembly guide
• Erle-Copter Ubuntu drone operation manual
• Erle Robotics web page
• Dronecode web page

For everyone looking to do some basic mapping with solo and mission planner I thought I'd write this post. FYI this post is just shorthand notes I've made and may contain some minor mistakes. The process to map with solo is fairly quick after you get familiar with everything and this post should be able to help guide you through it.  You may need a Alfa APA-M25 dual band 2.4GHz/5GHz 10dBi high gain directional indoor panel antenna with RP-SMA connector and extension cord from Amazon that will screwed into the left hand antenna as a replacement for extended range.

Make sure all batteries are charged including gopro. Setup in the middle of the area to be mapped for most coverage. Start solo, controller and solo app.

Sync gopro with phone clock using the gopro app, then shutoff the gopros wifi and leave gopro on, Set it to take picture every 2 seconds with gimelapse mode and have gopro facing straight down.
 
Start laptop and connect it to sololink wifi then the drone using UDP connection.(note do note use the configuration tab or any setup wizards in mission planner only use flight editor and data tabs) Go to flight editor and set home point. Add polygon by clicking the second mouse button on the map and draw the polygon for the area to be mapped. Then click the second mouse button on the map and go to auto wp then down to survey.

In survey select the camera you are using if it's a gopro then you will need to use the advanced options to put in the camera inputs. Note focal length is 2.77mm for hero 4 camera.

Set the speed and select use auto takes off and land. Select 85 percent sidelap and overlap. Go back to the simple tab and accept the survey.

Back in the map editor hit the second mouse button go to polygon and clear polygon.

Check the altitudes in waypoint at the bottom of the screen to ensure everything is set to the correct altitudes. I like to use verify height and set my takeoff altitude to the same as my mission altitude.

Once everything is set correctly upload map to solo by clicking write wp. Once it's uploaded go to flight data tab.

In flight data check to make sure the map Matches the one made in flight editor.

Click on the action tab on the left and change the top option to start mission. Start shooting the timelaspe with gopro which will take a picture every 2 seconds.

Click arm drone and then select start mission. Wait for solo to complete the mission and land.(note ensure the solo controller is always in range of solo) Stop the gopro footage and disconnect the link in mission planner to finish writing the log on your computer.

Find the log file in the mission planner directory log folder on your C drive and change the name to the flight you just did. (Note the log file has a mission planner icon and should be under the log and quadcopter folder or something like that. I have a shortcut to it on my desktop)

Now take the SD card from the gopro and copy the pictures to the laptop and ensure they have there own folder.

In mission planner press control f and select geotag images. Under log select the log file you renamed. Under images select the image folder you created from the flight. Click on time offset and leave at 0. Then pre process the files, once complete click add the geotag at the bottom of the window.

Once the geotaged images are done open pix4d and make a new project. Select the images and in camera setting select the model of gopro you are using. Continue to make the map as per normal with pix4d.

So almost a year ago, I posted about how I started work on a field oriented control ESC:

Redesigning multirotor ESC's

Some people in the comments already said how they made their own or started work on different ESC's. I went through 5 iterations of the ESC after the post.

Unfortunately, I never got any hardware working reliably for pretty simple issues in the end, which is frustrating. Primarily, I could never get the buck boosters of the TI DVR830x to work reliably and there were issues with SPI voltage and behavor. This caused a failure of 8-9 out of 10 boards or sometimes an entire batch. To produce one batch here is expensive: 60% import costs, $40 shipping for 2 boxes (one boards, one components) and then there's the currency rate of R$3 to the $1. In the end, to produce one batch here feels like spending $1200 dollars if I were in the US.

Important: I'm not saying the booster of the chip doesn't work correct, but that it's probably something in the process of my production (the "pizza oven bake") or the design of the component values around it or routing of the board.

Anyway, moving on... I did huge amounts of research into field oriented control. I built a FOC simulator in python and there's some 150MB of documents related to FOC implementations, ranging from presentations of TI about the subject to application notes, research papers, etc, plus I include some remnants of the board designs. Obviously, no point including boards of failing hardware, so just the schematics...

From the image above, all blocks at the top are really easy. They're only conversions from 3-axis to 2-axis models using clarke/park transforms. The difficult part is the "angle and rpm estimator", which is where the magic really happens. Eroding all complexity... it's trying to figure out bemf magnitudes from the Ialpha and Ibeta currents (in a 2-axis view), so that over a couple of samples it can converge to an angle. Another piece of code then gets this angle estimate and figures out the rpm, which is fed back into the angle estimate, because the rpm doesn't change all that quick. All that's left is tuning and the correct L and R inputs for the motor you're using.

The repository is here, along with a README on where to find the stuff.

https://github.com/gtoonstra/foc_esc

Disclaimer: No guarantees that any of this stuff actually works...

For a final project in a robotics class, I suggested that a few students try implementing their own version of a parser-generator program like pymavlink.  The students built a simple Python-based system in a few days, which parsed JSON message specifications and generated Python code to parse and serialize a simple variant of MAVLink.  

Since then I have added C++ and Java output to the program, and modified it to work with the popular Multiwii Serial Protocol (MSP) message format.  The program is extremely simple to use (a single Python script; you don't even have to know or care about Python to use it), and the Python output has been tested in a real-time attitude visualization program that one of the students wrote (shown in the image above). Another student is completing an Android program to do the visualization using the Java output, and I am working up a C++ example on Arduino (parsing messages over the Naze's UART pins.)

So if you are using Multiwii-based firmware like Baseflight or Cleanflight and are interested in writing code to interact with your flight controller, you might want to try out MSPPG. We could also look into adding support for other languages like JavaScript, C#, etc. -- just let me know!

Just want to tell that the DIY Ardupilot Cape for the BeagleBone Black (BBBmini) is now Open Hardware. You can get the KiCad sources here BBBMINI-PCB. I will not sell the PCBs, but I add some lines how to get 10 PCBs for less than 30$.

The BBMINI-PCB is updated to Rev 1.4, here some improvements:

• Connector for Ultra Sonic Range Finder HC-SR04 (2$, range 3cm to 400cm, 1cm accuracy)
• Voltage divider at pin RC_IN (RCIN) to connect 5V signals to RC_IN (RCIN), now it is possible to connect a 5V RX to the BBBmini without an external level shifter.

I also started a new project with is in an early stage of development, a Self Balancing Robot based on the BBBmini and Ardupilot software. AP_AHRS will be used to to get the pitch angle and AC_PID to balance the robot. It runs at 400 Hz, there are two Stepper Motors and there is a PRU Code inside the BeagelBone which can create up to 200000 steps per / second to the Stepper Motors.

Here is the first very early stage of development video, it balancing fine.

https://youtu.be/7Ow5aKap_sI

Best regards Mirko

From Bormatec, the Ninox, a great improvement to their original Q folding drone. With a wider nose, it has room for a Pixhawk and GoPro, and the overall construction is more robust. 

The NINOX from BORMATEC  is an action-camera electro-flyer, which can fold into a backpack. It was specially developed for action-cameras like the GoPro Hero and similar.

The NINOX has a wingspan of 100 cm with a weight of approximately 500 gr. The winglets can be turned down, so the NINOX has without problems in a backpack space and nothing can be damaged. The folding technique requires no tools and takes only a few handles. 
The voluminous fuselage accommodate action-camera, RC, autopilot & Telemetry !
The flight characteristics of Ninox are classified as absolutely simple. He can be flown slowly but quite speedy. 
For the NINOX, we use only high-quality materials such EPP and Coroplast, what makes these pocket-fly extremely resistant. 

Hi,

If you ever wondered what professional drone designers/makers are doing behind the scenes, well we're not only building UAVs for customers but we also have to train them from A to Z (and often we have to train ourselves too:).

To show you how this is made, enjoy this little video of this morning's training session (for agronomy usage).

Cheers,

Hugues

First off Chris Anderson reminds everybody he is known as old tiny hands in the 3DR offices, this the servo for the rover that he is entering into this round of the competition.

Rob keeps mentioning his chopper.

Some Australian fellows appear to have a flying site with a big flag next to it.

If you have no idea what I am referring to with this images and are brave enough to learn more then pop on over to the latest T3 round thread http://diydrones.com/profiles/blogs/t3-back-to-the-future?id=705844%3ABlogPost%3A2006592

Its not too late to enter either, these things are always flexible especially if you drop me a PM saying you are giving it a go but XYZ fell off or a tree caught your machine.

Thanks to everyone that has entered so far its a spirited affair! 

Very cool hack by a university team, using Android and Arduino. From Makezine:

The vehicle is a creation of University of Gothenburg student Dimitris Platisand his team of Makers — Yilmaz Caglar, Aurélien Hontabat, David Jensen, Simeon Ivanov, Ibtissam Karouach, Jiaxin Li, and Petroula Theodoridou — who collectively go by the name Team Pegasus. The team’s work is impressive, they’re GPLv3 licensed, and their documentation is quite good. The project is ripe to enable other interested Makers to jump right in and create their own fork of the project.

Originally, Platis’ class assignment directions suggested using a single-board computer, webcam combine, elaborate simulation software package called OpenDaVinci, and an aesthetically unattractive chassis, all of which he wasn’t too excited about. So, he and the team decided to dump the suggested components and solve the problem set using their own approach.

Here’s an overview of the project.

Layout of the car’s electronics system sans drive system

The electronics layout inside the car should look pretty familiar to anyone who has used Arduino to prototype a project. The Arduino MEGA connects with three ultrasonic sensors, two of which are mounted on the front of the car and one on the rear bumper. Three IR sensors also wire to the MEGA and are deployed in a similar fashion. A gyroscope and 9 degree-of-freedom inertial measurement boards round out the sensor package, but are placed within the chassis of the vehicle.

An Android phone, mounted to the car, handles computation of sensor data passed to it via Bluetooth.

Steering directions are transmitted from an onboard Android phone running vision processing and transmitted over Bluetooth, and the electronic speed control (ESC) and Adafruit motor shield handle the car’s acceleration (not shown).

Finally, and also not shown in the layout, is an ATtiny85 microcontroller that is programmed with its own sketch to handle LEDs control for such are things as breaking, turning, and illuminating the roadway.

The code leverages AndroidCar.h, a custom library built by Team Pegasus, and polls sensor data on the car, which is then sent via Bluetooth to the onboard cellular phone.

Then, the API handles the transmission of steering commands from the phone’s computations and alters the servo position. To learn more about the API, check out the Smartcar Core example sketches. For documentation on the code that glues the Arduino code with the Android phone, you want to check out the Android-Car-duino repository. And for an overall approach to adapting this set of libraries to your own vehicle this wiki is for you.