I know a couple of people at least were keen to see if it actually flew, I was a little skeptical it would be able to balance itself in the pitch axis myself!
I'll post another video shortly which shows some of the less successful flights, where it didn't quite manage to balance!
One of the biggest problems seems to be the landing gear.
Next challenge: Transistion and conventional flight :D
While flying our Telemaster last Sunday with two APMs we noticed something very strange about LOITER mode. The above track is a small snippet from our flight path. We entered LOITER mode on the left, with a loiter radius of 25m. As you can see from the spiral path, the plane did not loiter at all well, instead spiralling to the right.
It would be easy to dismiss this sort of behaviour as just a one off, but I've seen this before. Our plane has loitered well sometimes, but sometimes it was way off, often spiralling away from the right position just like this. I wanted to get to the bottom of it, and I thought that explaining the process of diagnosing and fixing a bug in APM might help other people to better understand their own UAVs. So read on for a long story of a set of bugs in the APM/ACM magnetometer driver.
The first thing I needed to do was look more closely at the raw data that I had logged for this flight. To do that I wrote a little utility called mavgraph.py, built on top of pymavlink. It takes MAVLink logs and allows you to graph arbitrary mathimatical expressions of any of the MAVLink fields. Someday I'll write up a proper tutorial for mavgraph, but for now if you want to use it have a look at the pymavlink github repository. The utility you want is examples/mavgraph.py. You'll probably find you will need to install a bunch of python packages to make it work. As I mentioned, some day I'll add instructions to the APM wiki unless someone else beats me to it (hint hint!).
If you are wondering how you get MAVLink logs, the major ground stations can record them. mavgraph will accept the format that the planner uses, or the format that mavproxy and qgroundcontrol use. I haven't tried it with HK GCS.
The key to good loitering is heading, so lets plot the GPS and compass headings we got in the above loiter:
mavgraph.py --condition='SYS_STATUS.mode==4 and SYS_STATUS.nav_mode==8 and RAW_IMU.usec > 908942404' Telemaster/logs/2011-08-07/flight8/mav.log VFR_HUD.heading GPS_RAW.hdg
That gives this:
as you can see, the GPS and compass headings did not agree at all well! As we had two GPSes on this plane, I was able to confirm that the GPS values were OK, so what was up with the compass? It looks like its range is badly squashed. That certainly explains why the plane couldn't loiter, as it didn't know which way to fly!
The next thing was to check if this was a problem during the whole flight, or just at certain times. If it was the whole flight then perhaps the compass is broken. We can run this to show just the times the plane is flying:
as you can see, the compass did track the GPS heading for some parts of the flight, but for a lot of the flight it was terrible. You can also see that I mostly did left hand circuits during this flight!
I started to suspect the magnetometer offsets. The magnetomers used by APM/ACM have two types of calibration. One is a linear scaling, and is computed at startup by asking the magnetometer to apply a 'strap' excitation and measuring the resulting field. The other is a set of offsets that account for local magnetic fields in the plane, and the properties of the magnetometer chips. The offsets are updated dynamically at runtime using a system called 'offset nulling' invented by Bill Premerlani and implemented by Doug Weibel. You can see the code for APM in libraries/AP_Compass/Compass.cpp.
Unfortunately the offsets that the null offsets code calculates were not being logged by APM (more on that later). So all we could do was use the RAW_IMU log, which does contain the x, y and z magnetometer readings after the offsets are applied. We can use those values to post-compute the heading from the raw magnetometer values. The formula is in the APM Compass code, and it translates into this rather long mavgraph command:
this shows that the basic compass calculations in APM are not at fault. The post-computed heading does match what APM calculated while flying (roughly!). So, what is the problem?
To get to the bottom of this we need a few more bits of information. First off, we need to start logging magnetometer offsets and other sensor offsets in our MAVLink logs, so we can properly check all the calculations in a post flight analysis. I added this patch to MAVLink and the code in APM to use it. So now we can get MAVLink logs showing the raw sensor offsets, not only for the magnetometer, but also for the gyros, and barometer.
Next I needed a reproducible test case. Waiting for the fault to show up again while flying didn't sound like a good idea, so I built a little test rig on my desk.
The test rig consists of a pan/tilt mount with two APMs mounted on top, both with magnetometers. The pan/tilt is controlled by servo outputs from one of the APMs. I then wrote a test script using pymavlink to run the test. The test script pans the two APMs around and tilts it when going in one direction, leaving it flat in the other direction. It also resets the magnetometer offsets at the start of each test (using another APM MAVLink message I added for this test).
This test rig allowed me to capture good logs of the two APMs moving about in a predictable manner. On one of the APMs I put a 5883L magnetometer, and on the other I put a older 5843. Here is the result, along with the 'true' heading calculated from measurements I took using a bushwalking compass.
(I should note that I am skipping quite a few intermediate steps I took this week in finding this bug. I don't want this post to turn into a book!).
As you can see from the above graph, the 5843 did track the true heading fairly well, but the 5883L didn't. So it looks like we have a bug in the 5883L driver. That means it's probably my fault, as I was the last one to work on that driver. So I am on the hook for fixing it. Darn!
Also note that this test is the worst possible case. It starts with zero offsets, and it only rotates the mags through less than 180 degrees, and doesn't roll them at all (I only have a 2-D mount available). So if you are wondering why your 5883L does better than this, then that is probably why.
The above result led me to start looking very carefully at the 5883L driver in APM. I found several problems. One was that we just accepted the first value from the mags for calibration purposes, but logging showed that sometimes that first value wasn't very good. So I added code to get at least 5 good values, where 'good' means not more than 30% off the expected value for the strap field. I also noticed that the expected values for each axis didn't match what the specification said they should be. The spec says that the X and Y values should be higher during calibration, and the Z value a bit lower. I found that the X was higher, and the Y and Z about equal. That was easy to fix in the code as well.
Next, I looked carefully at the gains used. The 5843 mag uses a strap field of 0.55Ga, whereas the 5883L uses a strap of 1.1Ga. That means you need to use different gain values during calibration of the 5883L than during runtime, as otherwise you either risk overflowing during calibration, or you will get lower sensitivity than we would like. So we use two gain values for the 5883L, and only one for the 5843. The problem was we were not scaling the resulting calibration values for the change in gain on the 5883L.
Finally, and perhaps most importantly, we were mucking up the rotation of the 5883L compass. The 5843 and 5883L mags have different orientations, so we apply a matrix multiply to fix that. Unfortunately we had some chicken and egg bugs related to that rotation. The compass init code was using the read() routine to get its values, and that applied the rotation, but the output of the init routine was used at runtime before the rotation is applied. That meant the calibration was incorrectly rotated. It also left some bugs related to init order, as we need to know what sort of mag it is to get the rotation right, but we also need to setup the rotation before we init, as init relied on the rotation. Nasty.
The fix was to extract out a read_raw() routine which didn't do any rotation or apply any offsets, and use that in the init() call, and also use that as the core of the runtime read() call. Thanks to Randy Mackay for this suggestion. Randy and I spent quite a lot of time on this problem together via skype screen sharing, and his suggestions were very helpful.
After all those fixes, this is the result of running the same experiment with the new code:
That's much better! We can also have a look at how the mag offsets evolve during this test, here are the 5883L offsets:
you can really see how the null offsets code is converging on reasonable values. It looks like it converges in about 10 minutes or so, but the heading is good much faster than that.
I'm still not completely happy with the performance of the mag driver, but it's better than it was. If you look at the 'good' graph above you will see that the 'true heading' matches the mag heading over a wide range of values, but the true heading peaks higher. I've double checked the measurements on my table using my bushwalking compass, and I think this is a real effect. It looks like we may be off by 20 degrees or so in some cases for both mag types. That means more investigation and logging. Meanwhile, I think APM/ACM will just treat it as a bit of 'wind' and will fly fine. I'll find out tomorrow when I take the Telemaster up again.
Posted by Daniel Hibben on August 13, 2011 at 12:30am
i have finally gotten almost all of the materials i need to build my new Y6, cf sheets in 1.5mm, and cf tubes in 20mm id with 1mm wall, and 50mm id with a 1mm wall.
i have gotten the main box pieces cut for the folding arms and the motor nacelles and arm mounts for the design above.
all of the main parts have been glued together and seem very lite and strong, once i get them all assembled i will post pictures. i am still waiting on the control system/ stabilizer, i am using the FY-91Q and the FY-20A for the camera mount, i actually have several control systems already, namely the wii multicopter board, the KK board with the xx2.0 firmware, however i like the features that the FY-91Q has and i found the wii board to be twitchy in the ACC mode,i added the barometric altitude sensor, however it seems to float up and down about 2 meters when it is engaged, and seems to have arming issues no matter what i do. the kk board fly's great but it is very basic, and has no advanced features like hover hold or return to home, so i am waiting for the FY-91Q to be delivered.
the motors are avroto's 2814 @ 770kv, i have these on my tricopter and running a 14.8v lipo pack at 3000mha, i am getting over 17 min of flight time using 12x3.8 props , this is a no payload flight time however, and in full flight trim i get 12 min, that is carring a GoPro camera, video tx, antennas, and the EMR labs 3D camera for video to the pilot, OSD, GPS, and a 500mha batt, so not a bad flight time i think. plus these motors are rather heavy also.
anyway back to the Y6 it will use 6 of these motors and i have ordered CF props in 12x3,8 from Mikrokopter USA, the reason i have ordered these is, A. because they look cool. and B. because i was getting tip flutter on the tricopter with APC nylon props, they just aren't stiff enough to lift that much weight without flexing, and it caused a lot of vibration that messed up the video from the GoPro causing me to have to fly with 10x4.7 APC props and i only get 8 min with these fully loaded. this is pretty good i think because the tricopter is very heavy, i hope that the Y6 will be lighter all around.
the speed controllers i am using are the turnagy plush in 30 amp, these have been great for me in the past and i have them on the tricopter and have had no issues, however if any one has an ESC they want to recommend please let me know.
well that is good for now i will update as i go and add pictures as well
Being from Lockheed it's not DIY by any means, but this could be an interesting concept to play with."The Samarai is about a foot long, and has just two moving parts plus a camera. It can be controlled by a remote control or by an app on a tablet computer."
I started a blog post some time back for a pre-production prototype we have been working on called the Quattor-bit. We have made a bit of changes after some suggestions, so we deleted the old blog and decided to start fresh with a new one. We originally wanted to call it the Quattro-bit, but thought we might run into copyright issues ( Victorinox Quattrobit knife). Well, it's almost done. Everything seems to be working as hoped.
We plan on selling the frame for around $300 with motors and ESCs'. The arms are made of thick pulltruded carbon tubes. The body is molded carbon fabric, but we also will be offering a fiberglass version at a lower unit cost. We are trying to use as little metal as possible, screws etc. The motor mounts are 3mm carbon panel, virtually indestructable. The mounts are fastened to the removable arms by wrapping 15 feet of carbon thread soaked in high grade epoxy resin. The body is large enough to hold a 11.1V 2600mah battery, and of course an APM. It will handle motors ranging from 22mm to 28mm can diameter. Gone are the Helicopter style landing gear. This size is more suited for small fpv gear, which we will demonstrate with later updates. We are still fabricating some of the parts, but this is what it will basically look like. Welcome any thoughts, suggestions, or questions. Couple of more videos on Youtube, just type quattro-bit in the search query.
Today's installment in our Meet the Developers series is Andrew Tridgell, or Tridge as he is universally known. He's one of a handful of "real programmers" on our team (it's his day job; most of us do something by day) who bring world-class software techniques to the project. I've learned a huge amount from him, including a lot of good advice on managing community development projects, which is what Tridge does with Samba.
Over to him!
Name: Andrew Tridgell
Home: Canberra, Australia
DIY Drones role: Works closely with Doug Weibel on MAVLink, APM and library development. Also leading the scripting and automatic testing initiative, along with lots of bug fixes.
Day Job: Working on the Samba project (www.samba.org) as a software engineer for IBM. I also teach part time at the Australian National University.
Background: I have been working on free software projects for 20 years, mostly related to system software and networking protocols. Before starting to work on free software full time I was a researcher and lecturer in computer science.
Interests: Right now I'm completely obsessed with building UAVs, but it is a very recent obsession, buying my first RC plane just 5 months ago. I got interested in UAVs after hearing about a local team entering the Outback Challengeat a meeting of our local maker group . I thought it would be a great project, and I now spend a couple of hours each night and most weekends working on the project.
I've found that working on APM with the diydrones community is the most fun project I have ever worked on. I think this will be a long term obsession!
Posted by Jeff Taylor on August 12, 2011 at 10:30am
For those of you who use a camera on ArduCopter there's a new accessory being added to the store today. It's a til-roll camera mount that stabilizes small cameras (up to about 75 grams) and keeps the image straight up and down while ArduCopter is maneuvering to maintain position and orientation. The kit is $20 and can be found here. Please note that the kit does not include a camera or servos! We recommend you use HS-55 servos or any other sub-micro servo in the same size. The kit does work out of the box with ArduCopter code - plug the servos in to channels 5 and 6 for automatic stabilization. Happy flying!
Posted by Andrew Fernie on August 12, 2011 at 10:00am
While the progress on the APM Mission Planner makes it more and more attractive to bring the laptop out to the field for each flight, sometimes the simplicity and sunlight readability of the Ardustation is what I really need. The problem was that I kept adding more pages and busted the memory limit of the Ardustation. However, after upgrading to the APM2560 I had a spare APM1280 so decided to port the code over to that. While one approach would have been to directly interface an LCD panel to the APM I decided to re-use the Ardustation by writing some code to turn it into a dumb terminal. This code (“ArdustationTerm”) receives basic commands on its serial link from the APM to draw text and make beeps, and returns key presses. Someone recently suggested a shield for the APM to add Ardustation-like functionality – my approach basically gives that functionality using current H/W.
The code on the APM1280 (“ASMRemzibiOSDMAV”) runs all the page logic and communicates with the vehicle via the MAVLink xbee. It uses the markup format from the ArdustationMega code so fairly straightforward to change the layout. The only change I made to the code on the vehicle (starting from the current APM 2.21 load) was to pass the motor current via the gps hdop field as suggested by someone in these forums. If you don’t want to make the change just delete the current from the display definition code. The image at the top of this blog shows most of the screens, but there are a few more for parameters not shown. Lots of memory left to add more functionality as needed. Parameter adjustment pages are coded on a 4x4 grid of fields with either static text for a label, or a parameter name for dynamic data. I made pages for the parameters I am interested in, but easy enough to change them as you like. Parameters are automatically requested from the vehicle after the APM s started, and can be requested manually. Same thing for waypoints.
For the most part my code is just monitoring traffic on the MAVLink, so it will co-exist with the mission planner. You can also hook up a Remzibi OSD and generate symbology on the ground. I have limited success with this as the symbology tends to drop off if the video gets noisy – need to work on a better antenna and add the tracking logic.
The APM1280 uses Serial0 for standard loading and debug via an FTDI cable. Serial1 is for the xbee, Serial2 is for the ArdustationTerm and Serial3 is for the Remzibi.
I have made use of a fair bit of code from the Ardustation and APM codebases. I have tried to acknowledge this in the headers, but if I have missed something I apologize. Let me know and I will correct it. You can find the code at my Skydrive.
I won’t have much access to email for the next week or so, but will be able to get back to this the last week of August.
there is some good hardware combinations for easystar FPV. this is motor 2835-2200KV, a 6x5 propeller and a beautiful 35mm aluminium spinner form www.leadershobby.com. a lawmate 1.2Ghz tranmitter and a lawmate camera from www.hobbywireless.com. everything is working verywell with this combination. a 2200mAh zippy battery from www.hobbyking.com. just some information i wanted to share.
The BT-1 8-Channel FPV Joystick is capable of interfacing with your transmitter (via trainer port) with the included FPV control box, and allows you to control up to 8 channels independently. There are 3 proportional channels, and 5 on/off channels. The BT-1 offers you the ease of flying your FPV model with just one hand.
Features: Ergonomic design Throttle lever for smooth, easy throttle control Easily accessible trigger and function buttons
Price is US$ 99.32 (but may be lower after logging in onto the Hobbyking website or after waiting for a pop-up with a one-time-offer).
Next up in our series is Jason Short, who is leading the ArduCopter 2 team.
Jason works right around the corner from me in San Francisco, so I see him often. When I walk into his company's reception area carrying a crazy robot multicopter, the receptionist nods knowingly and says "you must be looking for Jason." ;-)
Among the many cool things about Jason is that he's an ace at Flash programming. So if you were impressed by the interactive PID tuning demos in the manual, that's Jason!
Here he is, in his own words:
Name: Jason Short
Home: San Francisco's Duboce Triangle
Dev Team Role: Leads ArduCopter team
Day Job: I am a design director at Smart Design, know for creating OXO good grips line, Flip Video, and long list of other familiar products. I am an industrial designer turned interaction designer with 16 years experience consulting for consumer product and software companies.
Other DIY Drones Contributions: Lead developer for Ardupilot 2.5-2.8, ArdupilotMega 1.0, ArduCopter 2.0, Xplane HIL
Background: I purchased the Ardupilot while at Maker Faire had never actually installed the software. Instead I decided I try and re-write it from scratch to be a stabilizer and RTL system for my FPV plane. Pretty soon I had a full autopilot that could fly waypoints. Not well, but it worked. After posting my work to DIYDrones Chris asked me to help with the next gen of AP. I modified it, made it compatible with Happy's ground station and released it as Ardupilot 2.5.
As soon as the first IMU was developed, I started working with Doug on versions 2.6 and later. Doug's knowledge of flight theory gave me the confidence to keep pushing. Mike Smith's development expertise gave me enough coding advice to get myself out of almost any coding roadblock.
About that time I developed the HIL for testing using a simple solution in Perl to connect to Xplane. We used the HIL to test the new flight modes and the APM mission scripting capabilities.
Ten months ago I had a kid and realized my days of testing at the airfield all weekend were over, so I switched to Arducopter. I flew the original code twice and then fell back into my old habit of writing my own version. This time I ported the APM code that we wrote last summer and plugged in Jose Julio's control laws and within a few weeks had a flying copter. This version was not meant to be a release, but a private build for me to learn with. Pretty soon I had the framework for mission scripting, logging, HIL and Mavlink in place so the team decided to make AC 2 with my personal code.
The last 4 months have been tuning and rework to get it flying well in all situations on a wide variety of platforms.
I have to say, when I started with AC I had no clue what I was doing, nor did I fully understand the control laws. I'm still learning and trying new ideas and getting help from the team where I can. Unlike fixed wings, Quads can be extremely unforgiving platforms, which has proved to be incredibly challenging. But it's also been extremely satisfying.
Personal history: I grew up the son of a HAM radio and home-brew computer dad in the 70's. I learned that world as a kid, then went to art school and promptly forgot it all. I graduated an industrial designer from University of Cincinnati and worked in Boston for 9 years doing product design. I transitioned to software while in Boston and decided to move to SF with my wife to be closer to the action in Silicon Valley.
Other fun details: I used to be a BMX Freestyle rider, but I grew too tall to be any good (6'5") so I gave it up when I got to college.
Interests: I'm very much interested in human perception, behavior and cognitive science which I use a lot in designing UI's. I'd love to get more into AI and robotics in general.
Well, I diverted onto a quadcopter frame I have designed and built in order to test the electronics and my code, and here it is working, reasonably well! Though many more improvements are yet to be made!
In the first clip I simply increase the collective throttle, with stabilisation enabled, and then catch it as I have no directional control to prevent drift.
In the second clip I have done some p d loop tuning and have it happily responding to inputs from the transmitter. I'll follow this blog up with some more videos soon!
In the near future we will be running quadcopter and uav workshops at various locations in the UK and publishing each as a video guide on YouTube.
We intend to publish a comprehensive guide on PID loop tuning for model aircraft - it was very exciting to immediately swap the electronics into two other airframes we have (including Talon) and with only an hour or so of fiddling, have them flying stably too!
I can finally post a video of my quad. This is my 2nd FPV flight ever.
I was a bit nervous, but the latest AC2 firmware 2.0.39 proved to be rock solid! Weather conditions were the best ever so I couldn't miss a 7 o'clock flight... :)
Nothing special in the footage apart the stability of the quad that needed only little tuning. Here are my specs:
Arducopter center frame with custom ALU arms. 50cm circa motor to motor.
motors KDA 2022-L with 10x4.7 APC props
AC2 KIT with APM 2560 + mag + GPS
firmware 2.0.39
PIDS:
Stab. KP Roll-Pitch 3.5
Rate KP Roll Pitch 0.11
I defaults
YAW defaults
GOPRO HD with no vibration dampening at all. Video footage only cutted on boring parts.
FPV gear RC305 5.8GHz RX (cheap china) + 200mW TX
Fatshark Base
a lot of adrenaline and may batteries of testing before FPV.... ;)
I'm going to be starting a series of min-profiles of the people behind the DIY Drones projects, especially the software development teams who do all the hard work. These guys are some of the world's best aerial robotics experts and I'm in constantly in awe of what they know and can do. You may know their names, but not much more than that. So each week we'll highlight a few of them, so you can get to know the folks who make the magic here.
Before I get started, people often ask how they can join a DIY Drones dev team. There a quite a few teams, ranging from dozen members to just a couple:
APM software (fixed wing)
ArduCopter software, multicopter
ArduCopter software, heli
ArduRover
PPM encoder
Mission Planner
HK GCS
Lots of hardware teams, each with a few community members teamed up with a 3D Robotics engineer
Graphics and documentation
Lots of smaller teams focused on particular features, such a camera control or mission scripting
In all, there are probably 50-60 active developers in these projects. So how can you join? The best way is you have a specific feature you want to add or product you want to design and already know how to do it. That makes it really for us to evaluate: if the feature/product looks cool and you've already shown your aptitude, we'll hook you up with the right people and get you going.
What's harder for us to evaluate is people who would like to participate but aren't quite sure where and how, and may not already be a familiar with the code. We'd love to find a place for them, but the truth is that it can take a lot of work by the dev team to bring people up to speed, and that's time not spent on development for the community as a whole. One of our priorities for the rest of the year is to make it easier to bring such people into the dev teams, but that's still a work in progress at the moment.
With that introduction, here's our first developer profile, in his own words!
Name: Doug Weibel Home: Longmont, Colorado
Dev Team Role: Doug leads the APM software team, and is our resident fixed-wing expert. He also leads the weekly dev calls.
Day job: - PhD student and Research Associate at the University of Colorado studying Aerospace Engineering Science
Background: I started life as an EE/Systems engineer, but after several years switched into the business realm where I owned and operated several successful businesses. After retiring early and finding out that was boring I tried out a couple of other careers which failed to hold my interest. My involvement with APM led me to recently joined the aerospace graduate program at CU where I get paid to learn and play with drones ;)
Interests: I try to have as much fun as possible. I am a full scale pilot (Citabria) and competition sailplane pilot (Discus CS). I enjoy flying RC, particularly heli's. I am married and have 2 great kids both in high school. My kids are very involved with sports and music and chasing them around occupies a lot of my schedule. We do a lot of skiing in the winter and I try not to become a couch potato with some cycling, yoga, and pick-up games with the kids. Finally, I obviously enjoy the DIYDrones community and the continual push it gives me to learn more about technology.
Today DARPA will launch the second HTV2 that explores the 20mach region. It is launched aboard a Minotaur IV rocket and after re-entering Earth's atmosphere it glides until its destruction. At this altitude 20 mach translates to 13.000mph and DARPA states that the control system is one of the three key technical areas of the program (along with aerodynamics and heat management). The first flight was in April and after 9min communication was lost.
I have been working for a year on my home-made quad. It is made with wood, and it is controlled via wifi using a Fonera Router
Both WII NK and WM+ sensors gives the information to the router throughout custom CPU GPIO pins. To achieve I2C communication a especial linux kernel module is used to make an emulated i2c port with every 2 GPIO pins available.
The user can pilot the aircraft with a HTML5 and canvas web interface, making AJAX request on every key stroke or mouse movement. Telemetry is received with COMET (SERVER Push) HTTP information and Javascript is used to manage the entire page.
Fonera sends rotor commands to a 16F876 PIC, which generates PPM signals to manage ESC ( Electronic Speed Controllers). Those ESC are the power stage to trifasic motors.
To achieve very fast and less time consuming requests, http router web server has been modified on it's source code, to process all the AJAX requests in a RAM shared memory portion on the router.
Software control is home-made, and suited to be run into Fonera. It reads nunchuck and motion+ wii sensors, applies a low-pass filter, and a 2ndcomplementary filter (The RoyLB implementation ->thnx!) on every loop which has been previously readed.
I just got back some new silicon! These are the latest image sensor chips I designed specifically for robotics and embedded vision applications. The pictures above show a full wafer followed by a close-up of the wafer from an angle. There are four chips in each reticle- if you look closely you can see them packed into a rectangle (about 8.8mm by 7.0mm). Shortly after that picture was taken, we had the wafer diced up into individual chips and started playing with them!
One of the chips is named “Stonyman” and is a 112 x 112 image sensor with logarithmic-response pixels and in-pixel binning. You can short together MxN blocks (M and N independently selected from 1, 2, 4, or 8) of pixels to implement bigger pixels and quickly read out the image at a lower resolution if desired. The interface is extremely simple- there are five digital lines that you pulse in the proper sequence to configure and operate the chip, and a single analog output holding the pixel value. With two power lines (GND and VDD) only eight connections are necessary to use this chip.
Another chip is named “Hawksbill” and is a 136 x 136 image sensor, also with logarithmic response pixels (but no binning) and the same interface as Stonyman. What is different about Hawksbill is that the pixels are arranged in a hexagonal format, rather than a square format like Stonyman and 99% of other image sensors out there. Hexagonal sampling is not conventional, but it is actually mathematically superior to square sampling, and with recent advances in signal processing one can perform many image processing operations more efficiently in a hexagonal array than a square one.
(Above: 8x8 hex pixel layout from CAD tools, Stonyman chip wire bonded to test board- pardon the dust!)
We plan to release the chips in the near future, with a datasheet, sample Arduino script, and (yes!) a schematic diagram of the chip innards. (If anyone *really* wants one now, I can make an arrangement…)
We are also working on a new generation ArduEye sensor shield with these chips. The shield will be matched to an Arduino Mini for small size, and use a 120MIPS ARM for intermediary processing. The design will be “open”, of course. (Note- anyone who purchased an original ArduEye will get a credit towards the purchase of the new version when it comes out.)
(The thrill of getting new chips back is much like that for circuit boards. You designed it, so in theory you know how it works. But you are never 100% sure and there is no datasheet for you to consult other than your own notes or CAD drawings. You are always slightly afraid of getting a puff of smoke when you first power it. No smoke… the circuit breaker didn’t trigger… so all is good. Then you probe it, verify that different portions work as expected, tweak various settings, and finally get it working. The experience is just like that for a PCB except the stakes are higher.)
This small helicopter is calledInceptorand it is the latest product of Insitu, the innovative company behind ScanEagle that is now owned by Boeing. Inceptor weighs only 3.5lbs and fits into a police car trunk. It has an electric motor with swappable lithium polymer batteries. It can fly for around 24min, take-off and land autonomously, navigate and hover via waypoints and also controlled semi-autonomously through a touchscreen. The integrated flight control system is aFCS20 provided by Adaptive Flight Inc.
One can learn to operate it in a few hours and it provides electro-optic or IR imaging immediately even during adverse weather conditions and wind gusts. Video imagery is transmitted to the handheld ground control station and distributed to decision makers for real-time viewing. It flies below 500ft and within line of sight (as dictated by the FAA-issued certificate of authorization).
Inceptor will enter a developing but still very niche market sector that is mostly dominated by quadcopters. Prototypes are already flying and initially it will be available only for US public agencies at a cost of around $50.000. Selected law-enforcement customers will test it soon.
