Strapping a photon or electron to a drone?

Hi,

I was wondering if anybody has experience with strapping a photon or electron to a drone? I plan to read data with my students while flying the drone. I assume wifi as not an option as the range would not big enough.

Richard

I haven’t done it with a Photon but I have used Moteino’s, which use the ATMega 328p chip. We built a board which had temp/humidity/pressure sensors along with an IMU and GPS chip. We used the built-in RF radio to send back the telemetry data. Wireless is an option since drones use either 2.4GHz or 5.8GHz for command and control already. Since you can’t fly outside line of sight most RF radios are good enough.

I started with a DJI Phanton 3, which unfortunately I crashed and broke the camera gimble. We just removed the camera and attached a PCB with the various sensors and MCU attached.

I’ve strapped the STM32 (the heart of the Photon/Electron) to drones a ton of times. Maybe if you give me an idea of what you’d like to get done I could share some specific advice?

Wifi can work out to several hundred meters, with appropriate antennas. However, it all depends on what your data requirements are.

kubark42, I basically would like to collect data e.g. barometric pressure, GPS, temperature etc. with the Photon strapped onto a drone. Students would fly the drone remote controlled while it collects data and e.g. sends it to a Google sheet or via Python to SQLite. I would prefer the Photon as it is easier to organise than pay sim cards for several students. It would take place outside and a wifi network for the Photon would need to be created somehow. My concerns are how I could create a wifi network outside and how far the range is for the Photon.

Another option if you don’t need real-time data collection is to collect all of the data and store it to an SD card or SPI flash chip and have the Photon upload if when you get back inside.

This is what I would certainly do. It’s very easy to connect an SD card to a Photon and store all the data. You can either solder the four wires yourself, or get a carrier, https://www.sparkfun.com/products/12941, and connect with some breakout wires.

If you make good data type choices (no strings!) you might even be able to store all the data in RAM.

One question though is how you intend to get the data from the sensors into the chip. Writing drivers is not easy if you’ve never done it before, and it can consume 95% of the project time, leaving you very little time for the actual fun stuff. However, you’re basically describing data from an autopilot, and here you’re in luck because there are tons out there which do sensor logging and memory storage (Tau Labs, for instance). You might find that that’s a better solution than a Photon.

@MrRichard, I don’t know how soon you need the solution but you could certainly use the new mesh networking options coming soon (Oct?) from Particle. The RF radios will give you plenty of distance and there are plenty of good options for temp/humidity sensors along with GPS. The libraries for the major GPS boards have already been ported to work with the Photon.

I done the data storage approach both ways, both reporting data in real time and also using an SD card. To me, the decision was made by the need to see the data in real-time. If I didn’t care and could wait, it was easiest to save it locally to an SD card.

… also, it is illegal under US law to use cellular data while in flight.

Just curious, do you have an official reference or source for this statement? Airlines now allow you to keep phones on during all stages of flight. The only restriction I found in a quick search is that it cannot interfere with flight instrumentation. In general, you cannot get enough signal at altitude so it doesn’t work for most of the flight anyways. But on a drone, which by their nature are low altitude flights, cellular is too easy to use.

Sure, here is a reference.

It is quite clear, but I agree that low altitude personal drone flights is probably not a big deal. But I believe @MrRichard was talking about doing this for a classroom under some sort of official sanction, so he may want to be aware of the actual law.

Also, airlines allow you to keep your cell phone on, but in airplane mode, during flight. Which means the cellular part is turned off.

Well that sucks. They need to update that law. :wink:

Interesting claim. In all my time spent on drones, including working with Sprint to extend LTE networks for first responders, this regulation never once came up. Here are my thoughts:

The prohibition in CFR 22.925 is very specifically relative to the use of cellular phones. Odds are that any attempt to enforce that with an IoT device will run afoul of the very clear distinction between the two. While the line is blurred with a cellular device such as a smartphone used to browse the internet, a device which has no human interaction and only serves to send environmental sensor data is not a telephone.

Secondly, and it’s getting kind of pedantic to delve into this level of minutia, these are regulations and not laws. The FAA has power to enforce regulations only within its regulatory mandate. Either it can take away your flight certificates, or if you’re not somehow part of the FAA it can convince a judge that fines are necessary because of egregious and harmful action. Neither apply here.

Lastly, as they are regulations and not laws, the regulations must be legally reasonable (and not simply constitutional). The prohibition of cellular phone operation aboard aircraft has a very clear history and traces back to first principles of RF interference. No such claim could be made about devices operated miles away.

If this prohibition were to apply to IoT over cellular, then it would also apply over wifi and any other wireless technology. The distinction between “cell tower” and “wifi hot spot” is far less meaningful than the one between “telephone” and “wireless sensor”.

FWIW, I’m a Part 107 pilot as well as Part 91. I have dealt directly with the FAA regarding regulations. Whenever we had any doubts about our Part 107 operations, we communicated directly with the FAA and the responses were typically prompt, helpful, and deferential to the desire to stay out of the way of progress unless forced to intervene.

1 Like

rvnash, thanks for pointing this out. I am in Australia, but definitely have to check with the local authorities about that.

syrinxtech, we start the new curriculum in January; however, I need to make decisions much earlier as I need to plan and write the curriculum. I ordered one of each of the new boards to see if I get them to work.

I am basically on beginner level and the solution need to be easy enough for students (and me). I use the Sparkfun Photon board kit as it provided all documentation and tasks for students. The Sparkfun kit was what I planned to use next year in senior, but I though it would be interesting for students to move the data collection from the desk onto a drone. The drone I plan to use is an educational drone with resources on law, safety, building etc. They also have a chapter on coding a Pi Zero W with temp and GPS sensor, but that is a new word and I am not sure how easy it would be to extend the given code to use other sensors. It does not seem as easy as with the Spark boards.

Do you know the range of the new mesh boards. I was wondering if I could use one Boron LTE and have my students connect to it using Xenon. I am just not sure if the boards could connect over 200-300m distance being strapped to a drone.

However, not sure to Pi or Particle now.

The only reason I stayed away from the Photon for this application was that the drone already uses WIFI for controlling the aircraft. Yes, you can switch to 5.8GHz but I found the range for the RF radios (RFM69) that I was using was more than sufficient to transmit the telemetry data. I have also worked with LoRA radios which can easily reach several miles in the right terrain. I haven’t had any problem integrating a number of different environmental (temp/humidity/pressure, etc) sensors along with GPS and IMU from several vendors, including Adafruit. All of the major MCU’s including Arduino, Moteino, ESP32, etc. have libraries already that work with all of these products.

Regarding the range of the mesh products, I’m assuming you’re referring to the Particle product line and as far as I know, they are still doing those tests. As far as your 200-300m distance requirements, both RF and LoRA can easily meet those requirements. The major reason I would not use the Pi is weight. In a drone you have to be very careful about adding extra weight and throwing off the center of gravity. When you’re flying the balance of the drone is very important along with the carrying capacity of the motors. You don’t want to burn up the motors trying to lift weights that they weren’t designed to carry.

Others have mentioned options here. Some more complicated than probably necessary. A cheap all in one flight control board (Omnibus AIO) with a ‘black box’ barometer, and a gps unit(ublox 6 or 8) with a magnetometer, would allow you to log data to an sd card and use it post flight.

For realtime logging, those same cheap flight control boards can send data to your fpv screen, or over a radio. Cheap telemetry modules that are common already exist, and the distances using modules like an nrf24(2.4g band) are well documented. As are the use of an hc-12(433mhz), and other LoRa devices.

I think more info on the build of the drone and its onboard components are necessary for anyone to help you refine a decision on how to approach data-logging.

:slight_smile:
Ben

Thanks @kubark42. I very much appreciate your knowledgeable and reasonable reply. I started doing High Altitude Ballooning some time ago, and have read random claims that using cellular technology for telemetry was forbidden in the US. (The fact that it doesn’t work well at very high altitudes is another discussion.) That’s pretty much all I’ve been going on in my interpretation. I’d be quite pleased if the actual enforced regulation was more permissive.

Thanks everybody for their support. Particle community and support is one of the best I have experienced.

My conclusion so far would be to stay in the particle world. I thought students could code on Xenon. At home and in the classroom they could communicate from Xenon via Argon to the cloud. This would allow them to also learn about mesh technology. When using drones I thought to strap a Boron (my account) and their Xenon (student account) to the drone. The drone suppose to be able to carry 300g; however space could be an issue.

Questions I still have:
Does anybody see a problem with that approach?
Can Boron and Xenon connected to different particle user accounts communicate easily?
Does anybody have example code of how to send data from a Xenon via Argon or Boron to the could. I and my students are no experts and it would be great to know how challenging this could be.
Could the drone motors, RF controller etc. disturb the communication of the Boron to the cloud or with the Xenon?

Thanks,
Richard

The beautiful thing about home-built multirotor drones is that you can build your electronics stack very high. So long as you put the GPS on top, you don’t run out of space. I wouldn’t expect you’d have problems fitting multiple small PCBs on the drone. You might even get away with taping them to the landing gear. Be creative, the odds are very small that they will get in the way or cause some kind of fatal issue.

I don’t, however, believe that you will get very far with the mesh. I don’t know that hard numbers have been published about range, but these are designed to excel at being low-power. I wouldn’t expect this results in optimal range. The drone’s needs are sort of the opposite, you have tons of power but you need high range. So the LTE is probably an excellent fit, but I wouldn’t count on the other modules to give you great range.

The drone RF could absolutely interfere… or it could not. You’ll only know when you try! But I’m 99.9% sure that even if they do it will be highly localized. It would be enough to relocate your antenna to a spot on the drone which is a little farther away from the noise source. This is very much a trial and error kind of thing, but the good news is that it’s really easy to iterate on this and you’ll find a solution within just a handful of tries.