I am new to this and probably have a simple question:

1. We want to trigger our camera on the UAV with the DO_DIGICAM_CONTROL command. As far as we understand it, every shutter release requires a waypoint (we create the polygon and use the GRIDV2 command for it). Is this correct?

2. If so, it seems that there is an upper limit of 255 waypoints maximum in every mission. Is this correct?

3. If so, this means that one could shoot a maximum of 255 photos per flight, which is far too few for us.

How can we overcome this or is there an easier way to control the shutter release and - most important - get the GPS positions of the photos.

We use ArduPlane 2.70 and Mission Planner 1.2.50.

Many thanks for your help.

Oliver

Views: 2635

Reply to This

Replies to This Discussion

Oliver,

     Yes, each do-digicam-control will take one command slot and we are constrained by eeprom space so you won't actually even get 255.  I think the limit is closer to 124.

     I guess we could change the code so that the command keeps pushing the servo button at a regular interval perhaps.

     How about using a camera that has a built in gps?

     

Hi Randy,

thank you for your answer, which is a big problem for us. 124 is really nothing as we usually shoot between 1000 and  2000 photos for photogrammetry and surveying. So I guess the only quick solution is to switch the camera into continuous mode, which means that we won't get the positions.

A regular interval wouldn't help us too as with head- and backwind, the groundspeed of the plane would change significantly and therefore the distances between photos change enormously, which is useless for photogrammetry. We need a constant and stable overlapping.

Could it help if we changed the controller to PX4? I've read it is supported now with version 2.72 and assume it offers more memory with its 32-bit system.

Oliver,

     I thought there were systems to tie together images without them being aligned or regular.  In any case, I'm sure you know more about it than I do.

     I'm pretty sure we could support more waypoints on the px4 but I don't think we currently do.  It's probably not that difficult to increase the limit.

     I've ping'd tridge who is really the arduplane expert to see if he has an opinion.

Hi Randy,

yes, we can support more waypoints on PX4, although it isn't quite as simple as changing a #define. The waypoints are stored by the 'storage' AP_HAL object, which maps to the 4k EEPROM on APM2, and currently maps to a 4k file on the SD card for PX4. That 4k file is a direct emulation of the APM2 EEPROM.

We could increase its size, but currently it consumes the same amount of RAM as the size on the SD card. It works that way so that reads/writes never block waiting for SD card IO. An IO to/from the SD card can sometimes take quite a long time, and we wouldn't want the flight code to block waiting for it, so it is held in ram, and the storage IO thread writes changes to the SD card at low priority.

We could make that file larger, say 16k or so, perhaps even 32k, but we couldn't go much further than that without changing the way we handle it. If we made it 32k then that would give us space for a bit over 2300 mission items. It would mean we couldn't use the RAM for anything else though.

Another alternative is to go to an async interface to the waypoint storage, where the flight code says "I'd like mission item N" and then a callback happens when it is available (after having been read from the SD card). The flight code would then need to hold off changing waypoint until the data was available.

Alternatively we could keep the sync interface to keep the vehicle code simple, and just wear a possible delay in changing waypoints. We'd need to work out what the worst case time to read from the SD card is, and see if that time is acceptable. We would bring in a page at a time (say 512 bytes) so that delays don't happen very often.

Cheers, Tridge

Hi Andrew,

 

I've got the same problem like Oliver.

32k would help a lot - 2300 mission commands is not bad at all.

With Xbee you can send the next 2k commands ( = 1k photos?) in flight.

 

I'm looking forward to upgrade to PX4 soon :)

 

Regards,

Yannick

Randy,

you are right, I can align the photos without position data and the resulting 3D-model is just as good as with it. The difference lies in the processing time, which explodes without position data, as every photo has to be checked if it is connected with any of all other photos. This way, the processing time increased by the square of the number of photos. I can do it with 100 photos, which would probably take around 5 hours or so. With 1000 - 2000 photos, which is the normal case, it would take...well, forever. With position data the processing time is linear.

Hi Tridge,

many thanks for the details. I understand that memory is always a bottleneck in these tiny systems.

I think the concept, that photo points have to be waypoints isn't ideal. For covering even the biggest areas it is absolutely enough to have 100-200 waypoints available, as long as the autopilot is able to follow the flightpath between them as precisely as it actually really does. For taking photos and using it for surveying and photogrammetry this number is not enough.

Wouldn't it be possible to write a function which calculates the position of the next photo point depending on the input information of  last waypoint, next waypoint, minimum distance between waypoints and a counter? This way you wouldn't have to store all position data all the time, only one single point until it has been reached.

I don't know if the current architecture of the system allows this but it might be a solution. Anyway, for using APM for photogrammetry the availability of a file with x,y,z coordinates of the shutter release is a must.

Regards

Oliver

I see.  But if the shutter servo timed to fire at regular intervals (say every 5 seconds) and the APM stored the lat+lon+alt into the dataflash as the shutter servo was triggered that would give you what you need right?  Of course you'd have to download the location from the dataflash and make sure it lines up with the pictures but it probably would unless there was some kind of mechanical issue with the servo...

of course making the camera trigger after the copter has travelled X meters is probably also possible.  So then the distance between the shots would be roughly equal but the timing would not..

A better implementation would be if you could configure the ardupilot to trigger every X meters allowing a predictable overlap irrespective of groundspeed. This means that assuming there is no crosstrack error, you only need to place waypoints at the ends of each flight line. I believe Mikrokopter has just added this functionality inV0.9 firmwarehttp://gallery.mikrokopter.de/main.php?g2_view=core.DownloadItem&g2_itemId=133742&g2_serialNumber=1

Cheers.

 

what about the camera trigger option "trigger when 3m from waypoint" located at the top of the standard parameters menu?

Does that option work?

Nick is right, this method would perfectly do the job. Is it possible to get this functionality within a few weeks or so? I see this as a must-have for applications in photogrammetry.

Randy: a timed interval is useless as the difference in groundspeed between head- and tailwind can be huge and therefore destroy any planned overlapping.

I'm not sure if I understand the idea behind your question. Wouldn't it still require a waypoint for every shutter triggering? This wouldn't solve the problem.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service