It's customary and traditional that we celebrate the addition of every 1,000 new members here and share the traffic stats. This time it's a 77,000!
There were approximately 1.4 million page views in the last month! (we now get around 45,000 page views a day on average). It took us just 32 days to add these latest 1,000 members--we're averaging one new member every 45 minutes!
Thanks as always to all the community members who make this growth possible, and especially to the administrators and moderators who approve new members, blog posts and otherwise respond to questions and keep the website running smoothly.
I wrote an article which demonstrates how to build an inexpensive Bluetooth bridge between an SiK telemetry radio and an iOS device.
The article will be of interest if you’re building telemetry or ground control station software for iOS.
When I first started working with Pixhawk I was frustrated that I couldn’t use my iPhone as a development platform. I’m glad to have finally solved that problem. The problem is that iOS doesn’t provide the required operating system level libraries to communicate with serial port interfaces such as those on SiK radios. You could attempt to join Apple’s MFi program but that's out of the question unless you're a company intending to develop an accessory.
Solving radio telemetry for iOS involves hardware, and at the core of the solution is an ingenious bit of kit from RedBearLab named BLE Mini.
Other common Bluetooth modules are simple serial port adapters over Bluetooth, however these are useless for iOS. In contrast, BLE mini provides a Bluetooth peripheral service and a set of characteristics which bridge communication with a serial port connected to its pin headers.
My article covers the solution from a hardware and software standpoint. An example iPhone and iPad primary flight display app is available from my GitHub which works with the described hardware setup. Follow the brief instructions in the README.md to get the app running.
Tencent's WeChat is the most popular social app in china. In the most recently reported quarter, Tencent's WeChat had 697 million monthly active users.
With growing popularity of WeChat in China, mostly companies which focus on Social Media Marketing are choosing to setup a permanent presence on this platform with a subscription account. Subscription account allows post one massage include few articles to subscribers per day. Users could easy to share these article to others. So, it's the best marketing tool now and it's free.
WeChat Subscription Accounts Interface
ArduPilot China account Interface
Article Interface
We post drone and ardupilot project news for now, and we use this platform recruiting translation volunteers for first step.
The article in picture above is for Chris fighted back the "3dr closed rumor".
Chinese ArduPilot users will make ArduPilot ecosystem more awesome in the near future.
Due to public demand the slides for the PX4 Update talk ELC 2016 are now online and as they lack the narrative, this post details most of the content.
The PX4 project has gone a long way since its humble beginnings in 2008. While it was originally focused on open hardware (Pixhawk) and flight control (PX4) and produced a communication protocol (MAVLink) and ground control station (QGroundControl) “by accident” to support these, the project has set out in 2015 to tackle the next challenges: Vision based, GPS-denied flight and obstacle avoidance.
PX4 is an independent, international and professionally run open source effort with full-time staff driving the main development and quality assurance. However, it always did benefit greatly from ETH research lab hosting it, the Computer Vision and Geometry Lab of ETH Zurich. While it has been slightly odd in the past that a vision lab did sport its own flight control project, this now becomes a critical factor for success in 2016: With computer vision becoming as important as flight control on drones, PX4 is perfectly set up to deliver a full stack including obstacle avoidance in 2016. We will do so in a collaborative effort within Dronecode where possible, but are confident to have all the knowledge in-house to be able to drive it.
Progress Update
2015 was a very intense year for the PX4 development with contributions skyrocketing compared to previous years.
Linux / POSIX Support
PX4 has added broad POSIX support in 2015, adding support for Linux, Mac OS (helpful for development) and QuRT. The Snapdragon flight is the first fully supported Linux target and RPI2 and Navio are supported on a bench-test level as well.
While Qualcomm offered a PX4 port to their customers already mid 2015, the PX4 dev team and Qualcomm collaborated on a second generation of this SDK which now is completely open source and on PX4 Firmware master.
VTOL Improvements
PX4 supports VTOL since 2014 and extended the initial tail sitter support to tilt rotors and quad planes. While initial focus was on core flight control and safety-critical features, the development team has shifted its attention towards mission-critical features like ensuring smooth missions including forward and back transitions in all combinations.
Dronekit Support
Dronekit was recently added as a Dronecode project and now offers initial support for PX4. This is particularly critical for Dronekit as its ambition of becoming a standard drone API will require it over time to be entirely MAVLink generic.
Simulationkit
The current range of drone simulators is relatively fragmented, with each autopilot project maintaining its own simulation backends. This is not only inefficient and a lot of parallel effort, but also undesirable for the open source ecosystem: It should be possible to combine a simulator with an autopilot stack freely, which will help to drive both software components individually to perfection. The PX4 project and theAutoQuad project have recently started to collaborate on a MAVLink API for simulation. Simulationkit is still in its infancy, but already good enough to allow both projects to share common simulation infrastructure. The three videos below show that very different simulators and very different vehicle types can be supported with a relatively simple set of MAVLink messages.
Baseline jMAVSim cross-platform simulator:
High-fidelity Gazebo simulating a Quad:
Gazebo simulating a VTOL plane in a fully autonomous mission:
Complete Drone Stack
A drone software stack in 2016 looks very differently from one in 2015: GPS-denied navigation based on computer vision (optical flow and visual-inertial odometry) and obstacle avoidance are becoming increasingly important. The PX4 dev team has abroad background in research (video) in these topics since 2012. We also pioneered using vision sensors for avoidance with the Autonomous Systems Lab (paper video). While being pure research throughout the last years, we have now started to work on vision based flight and obstacle avoidance in the context of the open source project enabling PX4 to be embedded in a complete stack to build a drone with vision based positioning and obstacle avoidance.
Optical Flow
This involves the ability to simulate vision based localisation accurately, as shown in this optical flow example.
Avoidance
Or our recent work on obstacle avoidance is operational in simulation, and will find its way very soon into outdoor flights:
Planning
While avoidance is necessary for safety, it doesn’t create user delight – it does not make it easier to navigate the drone, but just safer. This is where planning kicks in: It takes load off the operator, allowing her to just specify where the drone should be going, but not how:
Wrapping Up
2015 was a great year for PX4, but also the last year where the project will focus entirely on flight control. A lot of new challenges are waiting to be tackled, but with more than 8 years experience on vision-enabled drones and quickly increasing broad industry support and adoption the project is set up to handle it.
We would like to thank our open source collaborators: The APM dev team on several years of great collaboration on the PX4 middleware and Pixhawk, the AutoQuad dev team on great beginnings on simulation, ETH Zurich and the Computer Vision and Geometry Lab for its ongoing support of the independent open source project and AUAV, Zubax Robotics and our corporate industry partners for their ongoing support and great collaboration.
Sky-Drones.com unveils SmartAP 4 Autopilot - the latest generation flight control system for multirotor Unmanned Aerial Vehicles of various configurations and sizes aimed at the wide range of applications. The main feature of the system is the capability of fully autonomous flight including take off, waypoints flight, landing and much more. The core is based on powerful 32-bit microcontroller ST Microelectronics® STM32F4 and 9-axis Inertial Measurement Unit. The latest UBlox® GPS module with integrated 3-axis magnetometer and pressure sensor can be connected externally for autonomous flight capabilities as well as wireless telemetry module for system configuration, mission planning & control and in-flight monitoring via specially designed SmartAP Ground Control Station and Configuration Tool. SmartAP 4.x supports any type of multirotor UAV with outstanding flight performance, reliability, navigation and control precision. Compact size and weight makes integration of the system fast and easy, various I/O interfaces allow creating the applications for interaction with 3rd party electronics and payload.
General specifications
Powerful microcontroller 32 bit 168 MHz STM32F4 ARM Cortex M4
Compatible with GPS/GLONASS receiver (UBlox NEO8, GPS/GLONASS, up to 24 sats, 10 Hz) active antenna
Up to 12 PWM I/O support (5V out)
USB interface for configuration / firmware update
Various communication lines (UART, I2C, SPI)
MicroSD, 4-bit SDIO interface for data-logging / parameters storage
Backup battery for RTC
2x ADC inputs for battery voltage / current monitoring
Electromagnetic sound audio indicator
3-channels LED support (up to 500mA / ch)
2-channels solid state relay
Flight performance:
Extremely stable flight in stabilize (user control), position hold (semi-autonomous control) and auto (fully autonomous navigation and control) modes
Native support of SmartAP Ground Control Station and Configuration Tool
Accurate GPS Position hold (up to 40cm), manual position override
Accurate Altitude hold (up to 10 cm), manual altitude override
"Google/Nest’s decision raises an interesting question. When software and hardware are intertwined, does a warranty mean you stop supporting the hardware or does it mean that the manufacturer can intentionally disable it without consequence? Tony Fadell seems to believe the latter. Tony believes he has the right to reach into your home and pull the plug on your Nest products.
On May 15th, my house will stop working. My landscape lighting will stop turning on and off, my security lights will stop reacting to motion, and my home made vacation burglar deterrent will stop working. This is a conscious intentional decision by Google/Nest.
To be clear, they are not simply ceasing to support the product, rather they are advising customers that on May 15th a container of hummus will actually be infinitely more useful than the Revolv hub.
Google is intentionally bricking hardware that I own. They don’t even dance around it, here is Revolv’s FAQ." (the image above)
Way back in 2007, when I was getting started with UAVs, the only autopilot available for less than $15,000 was the UNAV PicoPilot. I got one, stuck it in a plane (see above), and decided I could do better for less. Thus the open source ArduPilot project and the rest is history.
On a whim, I went to see if UNAV was still in business. It isn't. The site is now domain squatted, selling herbal aphrodisiacs (see below). Anybody know what happened to them?
Other companies from the early days that seem to be gone include uThere (Ruby autopilot), AttoPilot, Gluon (Gluonpilot), and perhaps some others I've forgotten. Amazingly, the thermopile-based (IR) FMA stabilization system I first used back then is still for sale (now just $39). One of the reasons we moved quickly into IMU-based autopilots was the FMA had a patent on thermopiles. We told them the thermopile era would end, in part because they were blocking others from using them, but apparently I was wrong ;-)
I have been using Canon S100 GPS for most of my aerial mapping work. It has been good to me as I do not require very high accuracy of the GPS location. My experience tell me that even with the small on board GPS receiver in the camera, my accuracy is always within 3 to 8 meter. Recently there are some request where very high resolution imagery is required and I start looking at better camera. For my Skywalker and FX 61 base UAV, I select Sony RX III or IV.
Since Sony III / IV does not has build in GPS, I had to use the Geo Tag feature in Mission Planner. I'm not going to re write the general work flow as it has been well documented here. I just want to share some issue that I encounter and how I solve it.
CAM Message synchro
As stated in the manual, we can use CAM message from dataflash log and also time offset. It really doing a good job - provided you have set it up right. Very often user may encounter problem which prevent him/her to successfully Geo Tag images and it is NOT fun to re fly the mission again after a long day in the field
For CAM message geo tag , " The most common problem in this processing mode is having a discrepancy between the number of CAM messages in log and the number of pictures in the folder. If the tool finds that they are different, it will output an error message and abort." as stated in the manual. Simply said, if the tools find more CAM message than the available images in the folder, it won't continue and you may end up forced to fly the mission again.
To prevent the discrepancy, it is important NOT to set the camera trigger interval too fast. I think to be in the safe side, the minimum time trigger between images is 2.5 seconds. This will give the camera plenty of time to write data to memory card and get ready for the next shot. Some how if it fail, I use the following method to " rescue " the dataset.
So, we have a problem here. CAM message 119 while only 114 images found.
Using Geosetter, I found out that between image 1536 and 1537, the time difference is 6 seconds while other is one or two seconds. So the camera had stopped taking picture here. Since the tools tell me that it need 5 more images, I simply add 5 random images between images 1536 and 1537 and rename them to 1536_1, 1536_2 and so on.
Now the folder has the exact number of images and the tools is happy to pre process it and subsequently geo tag the images.
I check the result in Geosetter and found that location is accurate. Of course the few " add on " images, even being geo tagged but won't help in orthomosaic / DEM processing for obvious reason. But at least we have most of the images geo tag and even need to re fly the mission, we only need to cover those missing area rather than the whole area.
I think CAM message is the best and most accurate way to geo tag images. If you are using Seagull Map2 or similar trigger device, just make sure to check " Photo every ( est ) " is more than 2 seconds when you build your mission and you should good to go.
Time offset
I consider Time offset is a back up method if the CAM message fail. For time offset, the common issue is the " estimated offset " suggested by the tools is not accurate and user need to play around with the figure. the end result may not accurate either because we just " guessing ". I do have some confusion regarding the time offset idea. My initial understanding is the auto pilot will record the time stamp once it get first GPS lock ( may be 6 satellite and above ? ) then the tools will find the time of first image. The difference is time offset. It seems that the " estimate offset " in the tools also work similarly. But if you input the offset amount suggested, the GPS location is way out.
The best way I found out is just set camera time to your local time. You can simply Google your local time, in my case, I check here. Although most camera only allow to set up to minutes, you can set may be one or two minutes ahead of the time shown in the web site and wait to 59 seconds then press the " SET " key once it turn 00. Do it as precise as possible. You can take a picture of the computer screen with the time shown and check the images in Geosetter, which can display the image exif file up to seconds
Once the time had setted, if you use Time Offset for geo tag your images, you simply input 0 second offset, then go for pre process and geo tag images.
Here's the result
There you have it, a nicely geo tag data set waiting for processing. Some decent eyes may found that my Skywalker not tracking well at the first way point. This is because it make a sharp turn of more than 150 degree go toward way point 2 and for some reason the auto pilot is quite lazy to trace the grid line at that point. Normally I'll set 50 to 70 meter over shoot, depends on wind direction to avoid this issue. I also try not to let the plane turn more than 90 degree on it's flight path toward second way point.
I hope the above info will complement the Arduplane manual and make geo tag images easy and fun.
Meanwhile I was in Japan where, among a lot of other things, we celebrated the launch of Dronecode Japan at one of those secret underground sushi places with only six seats. (It was exquisite, of course)
Dronecode Japan is led by Randy Mackay (the APM:Copter team lead), who was at the San Diego meeting, and the team from Drone Japan, including Kiichiro Katsumata, Yousuke Ochiai, Taka Hiron Sunohara-san and others.
Today I am pleased to announce the formation of a new commercial support company which I have founded in combination with Bill Bonney (creator of MAVPilot and maintainer of APM Planner 2.0 GCS software) and Patrick Krekelberg who has been running an existing R&D consulting company for several years.
We decided to do this because it has become apparent that there are many companies which are attempting to use UAVs and other mobile robots, but struggle because the field is multidisciplinary, requiring skills not just in software development and electronics, but also power systems, aerodynamics and mechanical engineering. These combined skills are difficult to find in one single person. Over the years, the Ardupilot community and DIY Drones has fostered an amazing group of people who have developed these skills, many who are working as independent contractors. But some, particularly large companies, prefer the simplicity of dealing with one single entity to simplify project management, billing, etc. and to make sourcing talent easier and more reliable.
Our goal is that as the business grows, we will be able to draw on the talent of the community of developers which has built up within this ecosystem, and help connect them with commercial companies needing assistance with their projects.
We aim to help commercial companies gain easier access to the performance, reliability and flexibility of Ardupilot, and also help find ways for developers to keep doing what they have been doing until recently. We will be supporting the ArduPilot community with contributions to the code, support to members on discuss.ardupilot.org and its day to day operations as a commercial supporter.
ASC will offer more than just consulting on Ardupilot code, but complete end-to-end solutions. R&D, vehicle design, rapid prototyping micro-manufacturing, program management, autopilot code, payload integration, user interfaces. ASC also offer assistance with operations, flight training, etc. As little or as much as required to get customer’s ideas off the ground, or along it!. Companies can focus on integrating mobile robotics into their business and developing new revenue streams, instead of having to undertake the long and difficult process of developing UAS expertise and technology in-house.
As drones continue to move from basic flight to commercial applications, the ability for onboard and offboard customizations becomes more and more important. A given application would likely introduce new payloads and require custom onboard business logic. This also leads to customizations in remote applications allowing for custom data plumbing between ground app and drone as well as targeted user interfaces for bettering the overall user experience. FlytOS provides a scheme for web/mobile applications that not only allows such customizations but also simplifies them by using standard tools.
FlytOS provides an onboard web server and exposes RESTful and websocket APIs. With this, there are following approaches for building web and mobile apps:
WEB:
Onboard Web App: FlytOS framework provides blueprint to write onboard web apps with server side code in python. Such an app is directly served from the drone and can be accessed on any ground device in a browser.
Offboard Web App: This requires an offboard web server which hosts and serves the web app and can be coded in the language of choice. This app internally makes REST and websocket calls to talk to the drone.
MOBILE:
Cordova/Phonegap: Frameworks like Cordova or Phonegap provide a way to build cross platform mobile apps using web technologies (HTML/CSS/JS). The code can be written and tested in browser with mobile oriented UI design and then built for a specific mobile platform e.g. Android.
Native App: This is conventional native mobile app development. The idea is to use FlytOS supported SDK/libraries and develop native Android or IOS apps.
The video above shows a sample joystick app for controlling the drone. It is an android app built with HTML/CSS/JS using the Cordova engine. The idea behind this app was to provide a simple interface that can enable anyone to fly a drone without prior flying experience. This app is built by our mobile app developer who also successfully tested it on a real drone while our pilots just stood by.
The app mainly has a set of buttons (HTML/CSS) that are mapped to REST calls (JS) at the backend and thereby allow the control of drone’s position and heading. We can also get data streams from drone to the app by subscribing to desired topics using the websocket APIs of FlytOS. This is a relatively simple app with only an offboard component but advanced applications can have both onboard and offboard components. In such a case, new data could be generated on either side which needs to be shared with the other component. This is possible in FlytOS by publishing and subscribing to new topics or by using new params.
The step by step procedure for building an offboard web app and a cordova based mobile app is documented and available in flytdocs. Onboard web apps documentation is currently in progress and will soon be updated in flytdocs. FlytConsole and FlytVision are inbuilt onboard web apps. The setup for native Android apps is currently under development and a how-to guide with a sample app will be put up after internal testing.
The code for the sample apps is available in github. This currently includes the above joystick app, a simple demo app with an onboard script, a sample shape tracing app and a GPS based Follow Me app. Further apps to follow soon include a joystick app to control multiple drones and a photo shots app for capturing shots like Orbit and Cable Cam. Please visit links below to learn more and get started with imagining and building your own web/mobile interfaces.
The ArduPlane Manual had a good instruction on this subject. I would like to share my own setting base on Sony RX 100 IV and using the Seagull Map2 UAV camera trigger in my Skywalker 1720 UAV power by HK Pilot32 soon to be deploy in Tanzania for ultra high resolution chimpanzee nest survey after the successful Pilot mission using X5 flying wing and Canon S100 GPS camera.
The Seagull map2 act as an interface between the camera and auto pilot. It also has a build in intervalometer features where user can select 1,2,,3,4,5,10,15 and 20 seconds time interval. Another really useful feature is the ability to turn on and off the camera. This can be done via auto pilot or a special assign channel from the radio control, or both. We want the camera in OFF status during take off and landing to avoid lens damage.
We can select any two unused channel to connect with Seagull map2. In my case I use channel 7 ( RC 7 ) for trigger and channel 6 ( RC 6 ) for camera on / off. The detail setting is as below :
Mission Planner > Initial setup > Camera Gimbal set Shuttle to " RC 7 " Servo Limit Min " 1000 " Max " 2000 " Shutter Pushed " 1700 " Not Pushed " 1500 " Duration " 10 "
To configure channel 6, go to Config/Tuning > Full Parameter list
In order to add camera on / off control from radio controller, in my case, Futaba T8J, we can assign Channel 6 to Switch A. Please note that Seagull Map2 will turn camera on / off alternately when it receive " high " signal ( pwm 1800 - 2000 ) In practice, when you move switch A from top position to bottom position, the camera will turn on, to turn it off, you need to move switch A to top position follow by bottom position.
To take full advantage of the Seagull map2 and Mission Planner build in function, the mission planning logic is : we want the camera in OFF status at the beginning. After take off, about one minutes or so from the first way point, we want to switch on the camera. Once it reach first way point, it'll start capture images base on distance and continue to do so until it reach the last way point. From there, we want the camera to stop taking images and shut down.
You can plan your mission as normal using Auto WP > Survey ( Grid ). After the mission is build ( accept ), you need to ADD a way point in front of the first way point, Preferably at least 200 meter from the mission first way point. Right after the newly added first way point, add another two way point.
Set way point No 2 to " DO_SET_SERVO " Ser No " 6 " PWM " 1900 " This will turn the camera on Set way point No 3 to " DO_SET SERVO " Ser No " 6 " PWM " 1500 " This will return to neutral Now way point No 4 is the first mission way point follow by " DO_SET_CAM_TRIGG_DIST " which is automatically generated by Mission Planner. To turn off the camera, add two way point AFTER the last " DO_SET_CAM_TRIGG_DIST " command Set second last way point to " DO_SET_SERVO " Ser No " 6 " PWM " 1900 " This will turn the camera off Set last way point to " DO_SET SERVO " Ser No " 6 " PWM " 1500 " This will return to neutral.
I attach the tlog of test mission. You can extract WP file and also parameter file if interest. Use at your own risk : )
Hello Everyone, long time no see. I'm the webmaster of the ardupilot chinese site.
In Sep 2015, I was been invited to join the First Session of the National Drone Education Alliance of China in Chengdu, Sichuan.
There was fifteen vocational colleges from all over the country join this meeting, try to find a practical syllabuses. Organizer of this meeting is a professor of Chengdu Technological University, he has confidence in ArduPilot, but other teachers do not know what that means. So this meeting do not have any direct result.
But now, more and more university include these colleges start to pay attention to ArduPilot. In industry field, ArduPilot customization business start to show up.
The Chengdu goverment develops drone industry vigorously. I'm trying to coordinate with them oganize a competition base on ArduPilot at end of June.
Generally speaking, a GNSS RTK board will provide various electronic interfaces for communication as below.
- COM1/COM2, employ 5pin PicoBlade receptacle connector with TTL voltage level (1.25mm inter-pin distance)
- LED Indicator, shows the operational status (LED1 is data link indicator, LED2 is RTK status, LED3 is positioning status, LED4 is power indicator).
- Host USB port, receptacle USB 2.0 port for external USB Flash disk
- Micro USB, 5V DC power supply
- SD card slot, for plug in SD card
- SMA1, for GNSS antenna
- SMA2, for PPS output
As Tersus understands how important the interfaces for connection and communication, all Precis® series of GNSS RTK boards perform self-check and initialization procedure before they start to work. To get more info on the functions and get support for trouble shooting, drop us a mail sales@tersus-gnss.com or visit our official website www.tersus-gnss.com for the User Guide.
Congrats to DIYD'er Matt Reimer, whose great Pixhawk-powered autonomous farm vehicles continue to get the attention they deserve. Now on Hackaday:
[Matt Reimer] is a farmer in Southwestern Manitoba, Canada. It’s grain country, and at harvest time he has a problem. An essential task when harvesting is that of the grain cart driver, piloting a tractor and grain trailer that has to constantly do the round between unloading the combine harvester and depositing the grain in a truck. It’s a thankless, unrelenting, and repetitive task, and [Matt]’s problem is that labour is difficult to find when every other farmer in the region is also hiring.
His solution was to replace the driver with a set of Arduinos and a Pixhawk autopilot controlling the tractor’s cab actuators, and running ArduPilot, DroneKit, and his own Autonomous Grain Cart software. Since a modern tractor is effectively a fly-by-wire device this is not as annoying a task as it would have been with a tractor from several decades ago, or with a car. The resulting autonomous tractor picks up the grain from his combine, but he reminds us that for now it still deposits the harvest in the truck under human control. It is still a work-in-progress with only one harvest behind it, so this project is definitely one to watch over the next few months.
Writing from the point of view of someone who grew up on a farm and has done her share of harvest-time tractor driving it’s possible to see both the strengths and weaknesses of an autonomous grain cart. His fields on the Canadian prairie are very large and flat, there is plenty of space and the grain makes its way from the field to the elevator in a truck. To perform the same task in the smaller and irregular fields of southern England for example with a mile round trip down country lanes to the grain store would be a much greater challenge. Aside from that it’s worth noting that his John Deere is a 220hp 4WD workhorse that is capable of going over almost any terrain on a farm with very few obstacles able to stop it. This thing can do serious damage to life and property simply by running it over or driving straight through it, so safety has a dimension with an autonomous tractor in a way that it never will with for example a vacuum cleaner or even a lawnmower.
Those observations aside, this kind of technology undeniably represents a step change in farming practice on a par with the move from horse power to tractors in the first half of the last century. However the technological barriers that remain end up being solved, it’s likely that you’ll see plenty more machines like this in the fields of the future.
The video below the break shows the autonomous grain cart in action. Plenty of big-sky tractoring action, and for those of you unfamiliar with farming it should provide some understanding of the task of getting grain from combine to store.
We’ve talked about robotic farming more than once here at Hackaday. The gantry-based Farmbot, the six-leggedProspero robot farmer, or another hexapod confusingly also called Farmbot, for example. But these have all been hacker’s solutions to the problem using the concepts with which they are familiar. What makes [Matt]’s project different is that it is a farmer’s solution to a real farming problem by automating the machinery he already uses to do the job. Farmers have been doing what we would now call hacking at the hardware of their craft since time immemorial, [Matt]’s work is just the latest manifestation of a rich heritage.
We haven't heard too much from Trent@MyGeekShow since he restructured his time late last year. He has however just uploaded a video outlining some exciting news.
These new professionally-built 4S packs are based on Panasonic's NCR18650GA Lithium-Ion cells which offer comparable energy density but with upwards of twice the power density as Panasonic's well known NCR18650B.
With the primary factor prohibiting use of Panasonic's NCR18650Bs in a broader range of unmanned aerial craft having been the relatively conservative power density (compatible only with the most efficient craft) as well as the limited availability of suitably sized and terminated packs, this new offering is a fantastic option for many smaller fixed-wing (AXN/Bixler/Wicked Wing XL) and mini-multirotor (<350 ships, not fpv racing) flyers who are chasing a bit of extra endurance.
The only problem I can see at this point is that they appear to be available exclusively via Amazon and shipping is not available to me here in the land down under. It is a shame too because I would love to grab half a dozen or so for my park flyer!
Following on from my previous blog, I hope to get the prototype sub-hub pcb back soon from OSHPark.
The purpose of the sub-hub is in order that arbitrary electronics can be put in the wing of a plane with 2 piece or more detachable wings while being able to connect the wing to the fuselage with a single 4 way connector for useability.
The sub-hub communicates with the FC via a high speed uart. The connector also provides power at 7 to 20 V. (There is a switching regulator on the pcb to convert this to 5V at 2 A for the servos.
The prototype PCB uses an stm32f0 as the mcu and has the following features:
* 2 servo PWM outputs which can provide 2A at 5V. ( More coud be added as necessary but I only need 2 servos on the current project) * analog /digital RSSI input from the RcRx * PPMsum receiver input from RcRx * FrSky telemetry output to th RcRx * UART (for GPS) * Other analog input ( for airspeed sensor) * I2C input (for magnetometer.- airspeed etc)
I'm assuming I can get a baud rate of 1 Mbit per sec over the link ( cable length is around 400 mm) , so the next task is to try to work out the detail of communication between a sub-hub and the FC.
The UART for comm with the FC is probably an overly simplistic way of doing things. Dependent on how this goes, I may try a UAVCAN version or even a USB version using an Raspberry Pi as the host
