Jaime Machuca's Posts (2)

Sort by
Developer

3689671110?profile=original

*** Note this Blog post was done a long time ago, this is no longer needed with the latest Solo updates. Current Solo firmware will trigger the GoPro during an auto mission correctly, and the cam trigger messages on the data flash logs can be used for geotagging the images via mission planner or directly in software like Pix4D ***

There have been a lot of questions about how to this in several forums, I posted a solution a while ago on the Facebook Solo Mod Club page, but with all the demand I think I should also post it here. 

First understand that this is a hack that modifies some files inside the Solo and that you may or may not need to do a factory reset before you upgrade to the next version of the firmware which seems it will contain something similar to this modification. So do this at your own risk and only if you know what you are doing. 

From the comments bellow, I think this explains it better:

"With the current Solo update system, user modified files will not be updated during a software update. To get the update, either a patched version of the new file will need to be manually installed (taken from a "clean" updated copter) or a "factory/settings reset" needs performed to get the copter back into a clean state before updating.

As with any software mods, it's always best to back-up the original file before modifying it (use something like "cp file.py file.py.date.back"). The backup can then be restored before a software update and then the updated file can be patched/modded again." -- Angus Peart

The Pixhawk firmware in Solo already has everything that is needed to trigger the GoPro for survey missions. It has the logic to trigger the GoPro based on distance or by using a explicit trigger waypoint. What is missing is for the companion computer inside Solo to interpret this messages and send a command to the GoPro to take a picture. This is what my mod does. Also it creates a log file for each flight where it stores the positions of any still pictures you take with the GoPro, not just during surveys, but anytime you trigger a still. 

Here are the steps:

1. Connect your computer to the Sololink WiFi network

2. Use an FTP Client to connect to Solo (root:TjSDBkAu@10.1.1.10)

3. Make a backup of /usr/bin/shotManager.py

4. Replace /usr/bin/shotManager.py with this file:

shotManager.py

5. Reboot you Solo

From now on whenever the Pixhawk sends a trigger command the Solo will trigger the GoPro and take a still. If the GoPro is in video mode it will switch it to still, take a pic and then put it back to video. Please note that everytime the GoPro takes a still you will loose video or see artifacts on the video. This is normal, and is related to how the GoPro works. If you fly too fast the GoPro may not respond to the trigger commands fast enough. Also if it has to switch between video and still it will take longer to take a picture and you may miss pics. So set the camera to still mode before starting the flight.

Once you have finished your flight you can use FTP to pull the georef log file from the solo. You should find them in /log/geoRefxx.log where xx is the number for the log and is incremented each flight. Have fun mapping with Solo.

PS. The picture above uses something similar but with the QX1 Edison Camera trigger on an earlier article I wrote. Since Solo is Pixhawk based you can use that too.

Read more…
Developer

3689652590?profile=original

 
For the past few weeks I have been working on a way to integrate better cameras into our mapping platforms. Our platforms are based around the APM: Copter and APM: Plane software and use 3DRs Pixhawk autopilots to control the vehicles. While the Pixhawk provides for a sime way to do survey missions, the next step towards advancing this area is to incorporate better cameras, more intelligence and vision processing into the systems. This is where the flexibility of this platforms provides a great advantage over other systems. 
     
The first step towards improving the system is to increase its processing capabilities and data collection sensors. By attaching a companion computer like the Edison, you provide extra processing without compromising the flight control system. This way if the Edison crashes, the Pixhawk can still bring the vehicle back in one piece. 
     
This post will show the first part of what we have been working on which is attaching a better sensor for surveys. Sony has some really cool cameras that have ditched every thing (or almost everything, the flash is still there) that a drone does not use, like a big bulky display and buttons. These cameras are meant to connect to a smartphone and use that as the control interface to the camera. This connection is done through Wifi, and Sony has released an API to allow developers to Crete their own apps. And in fact, all you really need is a Wifi connection to the camera. 
      
Using this API, you can control all aspects and settings the camera allows, things like Shutter speed, aperture, ISO, shooting mode, focus, zoom, picture quality, you can even preview the images that have been captured in different resolutions, and download the full size images of needed.  This opens up a much better control of the capture process and even allows for post processing of the images with vision algorithms on board! 
     
Working with her Dev Team, we have been able to write a module for Mavproxy and made some modifications to the Pixhwak code in order to allow control of these Sony cameras from the Pixhawk via mission items, and from ground stations sending mavlink commands to control the camera.
     
This is all still in its early stages, but it is functional enough now to allow for mapping missions using this system. 
3689652616?profile=original
The connections as shown above are pretty straight forward, an Intel Edison is used as the companion computer to translate the Mavlink commands into API calls sent to the Sony camera. The Edison is powered and connected to the Pixhwak using the Telemetry 1 port which provides up to 1 amp of power and forwards Mavlink Messages to the serial port on the Edison. Inside the Edison, MAVProxy consumes these messages and the smart camera module interprets them and sends the appropriate commands to the camera.
    
The messages used are the command long MAVProxy commands for DIGICAM_CONTROL and DIGICAM_CONFIGURE. Once the Edison is setup to connect to the Wifi hotspot from the Camera, it will look on that network for a valid camera IP and try to connect to that camera. Once connected the camera will respond to commands sent from the ground station or from a pixhawk mission. If you own a camera with a power zoom, you can zoom in or out using the DIGICAM_CONTROL message, and trigger the camera using the same message. Here are some results from a mapping mission using the Sony QX1 camera mounted on a 3DR Aero-M. 
    
    
I will write a wiki page on the developer documentation explaining the technical setup, but be aware some changes were required or the Pixhawk code so that it correctly handles the forwarding of the packets, these changes are currently only available on the AC3.3 beta code. The MAVProxy smart camera module is now in master in the MAVProxy Github repository which by the way was just recently moved into the Dronecode project Github account.
    
Read more…