A Place to post and discuss Deliverable 1 for the Outback Challenge please share! for not just people competing this year but for those competing in the future!
Deliverable 1:
Deliverable 1 should demonstrate understanding and compliance with the UAV Challenge Medical Express
rules by describing a system that complies with the rules and explaining how it will meet the safety
requirements set out in the rules. The document should refer to the rules where applicable rather than
“cut and paste” of large sections. While a detailed description of the platform/s is interesting, it should not
be at the expense of ensuring that the Technical Committee can assess compliance and safety.
Replies
Hi Deadhurricane (I'll use DH for short!)
Comms is an issue over this distance. There is of course two distinct data sets that need to be transferred via RF, one being the telemetry the other the full images or recognition thumbnails to get Joe's exact position.
With telemetry you can expect very good performance from the RFD900's and a decent antenna combination on either end. On the aircraft we flew with two stick on flat pcb antennas, one horizontally on the outside of the wing and one vertically on the winglet. Distance from other noise creating components is key. On the ground we used a 9m mast with rope stays and the RFD900 on top with dipoles in similar orientation. Apparently we had one of the best telemetry links of the event, to the point the organizers questioned our radio settings etc.
In all our testing we never had an issue with the rfd900 ever, they became one of the most reliable components in the aircraft, however on the day the ground radio failed to connect for no apparent reason, resulting in us having to replace it quickly within the setup time. It worked fine earlier that morning when we tested it at the motel, and afterwards once we got back home, but at the event it just had an issue. You can use a USB to LAN cable adapter to get the cable length btw, but get a USB 1.1 version if you don't want to power it separately. There's no performance loss from what we could tell, but test the complete system to make sure.
Of course there's the issue of comms loss on landing as it is nigh impossible for the RFD900 to have a connection back down to the ground over that range, due to terrain, height of aircraft antenna, trees (they're good antenna) and any other obstacles etc. See my previous posts here on this thread about the alternatives to using a support aircraft for comms relay.
That leaves the image and thumbnail data components that need to find their way to the ground. The dominate idea behind using recognition onboard the aircraft is to reduce the required data to the ground where a human can then make the decision where to land. Some of course take this to the point that the recognition process is so good it produces only one hit/thumbnail with Joes location. In fact to get all the recognition points in the last OBC this is what needed to be accomplished, hence Team Robota becoming second with NO recognition processing at all, simply by using wifi FPV (5.8GHz Ubiquiti from memory). From what I could tell it was only the Dutch team that had the ability to do this type of one hit recognition accurately, but sadly this wasn't proven as they didn't get to the search area. In this event though there are no points for onboard recognition, so provided one can manage the data flow required to position Joe accurately from imaging, it's possible to do it without onboard recognition entirely.
So if no recognition is used then there are really only two paths that will work, one is via 3G/4G mobile phone services and the other wifi. At the last event we had both, but sadly our wifi experienced a mechanical failure due to some last minute reshuffling in the aircraft (the LAN socket came off the PCB) so we couldn't test that in the event. We should of at least turned the mobile's AP on instead though, that would of probably helped get the images down faster. Wifi is sometimes a bit of a hit and miss affair depending on your setup, and especially using 5.8GHz will mean you need to keep a decent altitude to keep the link, and probably a tracking dish/ on the ground. CUAV have done some work on data package handling that can help. Also I'd avoid Mickotek products unless you're willing or able to learn how their product works...I found their configuration unnecessarily complicated and hard to debug.
That leaves the mobile data path. From experience reception is pretty good in the air, much better than on the ground so make sure you assess the ground connection to mobile as well as the air components. Currently there is no location information on where the event will be held and this is a bit of a issue in order to select appropriate comms using mobile coverage maps. In fact we might only find out the location just before, or even during the event, which will make it pretty difficult, but obviously more realistic.
On the plus side there is the fact that Joe will text us his (rough) location which would typically mean that he also has coverage where he is on the ground. If this is the case, and he's not using a sat phone just to stuff us up (!) then one can reasonably anticipate that mobile comms is available on the ground. If it's available on the ground then it will be available in the air with even better connection speeds, which are fast enough to do full size on-recognition imaging transfers. So provided one is willing to "risk it" using mobile comms for imaging, and even on ground telemetry, it's possible to do it with just a mobile data stream.
Of course that leaves the with recognition options for data links. As previously discussed when using recognition the data volumes are significantly reduced, mostly because it filters out irrelevant information, ie image information that isn't likely to contain Joe. By doing this it is then possible to send some tiny geo-referenced 1-4kB thumbnails down over whatever comms is available (the more the merrier IMHO). This means it is possible to use the RFD900 for both telemetry and imaging.
Until now we haven't actually used the thumbnails over RFD900 approach as there's only certain setups of GCS etc that supports this, from what I understand all specific to CUAV's OBC code packages. In fact I think it's worthwhile to maybe start a discussion on the subject in order to give everyone a bit of hand (including ourselves!) to set this up. I would highly welcome it as it gives at least one mission capable comms alternative. What do you think CUAV team? ;-)
Regards JB
Hi JB,
On the RFD900,try using a ppp connection. It has worked for us so far, we have both MAVLink telemetry data and other data (ssh connection - flaky due to TCP/IP issues - will be looking at a normal tty as a fall back and a udp file copier). I was pleasantly surprised to find it injects the Mavlink RSSI in (so you get the radio RSSI not the 100% from Pixhawk to Mini PC reading). We have only tested to 2km so far and it works well. We will try a longer range test (10-15km) in the next few weeks.
Regards,
Chris
Hi,
Just to be clear that is a PPP connection on the companion PC that is connected to the RFD900 via a serial link (I use a serial TTL adapter) and a serial connection to the telemetry port on the Pixhawk. Should be all the hint you need to get it working.
Chris
Hi Chris
Thanks for the info I'll pass it on to our comms guy. If I may ask what are you using on the air end to inject the image data into the telemetry stream?
JB
Hi JB,
The PPP link means that I have a IP address on both sides, it means that I can push image data using a UDP file copier as TCP seems to crap out due to packet loss. I also seem to be able to maintain a semi stable SSH link which I run apps using a program called screen which means that if i need to reconnect i can return to where I was before the link went down. The telemetry data is just sent from MavProxy on an ODROID (connected to Pixhawk) via UDP to my linux VM running on my Notebook with the other RFD900+ on it.
So the telemetry data is the one being carried by the PPP link, I was very impressed that the RFD900 analyses the data going across recognises it's MAVLInk and injects the RSSI data.
Hope that makes sense.
Regards,
Chris
@deadhurricane - 64k is about the max you can expect. We can see things using progressive scan after a few passes at this rate - maybe enough to see the landing site. Thumbnails will come down OK at this data rate.
3G if present will be a bonus.
Which team are you on?
Ours is here:
http://westcoastuav.org/2015/09/21/westcoastuav-receives-go-for-d1/
Hey Stephen buddy.
How are things going? We should catch up for a flying meet sometime.
I read through your D1 and have just a couple of questions. With the RFD900 comms relay on the diagram you label the RFD900 on the support aircraft base, does this mean that the retrieval aircraft can only talk via the support aircraft radio, or can the retrieval radio also talk directly talk to your GCS radio? If it can't talk directly as well you might be at risk of loosing comms to both aircraft if the support aircraft fails. BTW are you using the mesh functionality in the Sik firmware or did you write your own?
The other thing that I'm wondering is on what information you based your decision to use a VSTOL airframe in the landing zone? Do you know something I don't on how smooth or accessible the landing area is for an aircraft to take off normally, albeit a short takeoff and landing? This is fairly important information, as even grass length and usable area, or orientation after landing, is obviously a concern, as well as nearby obstruction by trees etc that need to be avoided. What is the glideslope and takeoff length for your airframes?
But otherwise I'm happy to see your holding true to the safety concerns and are using lightweight foamies to get the job done! ;-)
Regards u know who!
Hi Sam - Yeah we should one day - I have all foamie wings now.
So far the lander talks only to the support aircraft. Not using mesh as we use SLIP and TCP/IP.
None at all - we figured that there must be a bit of clear space and will sacrifice points for 10 meters of something. Remember last time a FPV foamie trainer came second.
If it works it work and if it doesn't it doesn't.
You are doing a lot of talking and not a lot of posting - where is your D1 :-)
Yeah well as you'd know first hand I have a lot to say...but nothing at all to show! ;-)
Currently our D1 is "classified"...until D2 or so and it's to late to adopt. There's a couple of airframe/procedure/safety items that we included we think might give us an advantage, read be "competitive". I wasn't anticipating that we'd share it, so it wasn't written like that. We were close last time, so I'd like to do better this time around!
What's SLIP? Do you think it's a problem not being able to talk directly to the retriever?
With the landing space I originally thought there might be a way to use a SVTOL, around the base it is a non issue with LOS, but we went for a VTOL instead because we had more control over where/how it landed and would take off at Joe's. Still going electric foamie of course...but with a twist. I'm trying to get rid of the support craft (even though we're taking one), especially if it's only task is as a RF relay. There's other options there.
I remember team Robota well...classic case of the supposed "underdog" showing what can be done if you really understand the rules...and how the points work, using just the minimal gear required. Great bunch of people too. I wonder if they're coming this time again.
-
1
-
2
-
3
-
4
of 4 Next