Hi all, I'm glad to announce that the R10 kickstarter so far has been a great success, we reached our funding goal within 30 hours, and there is still interest. So I thank all of you here at DIY Drones, I know some of the community here have supported us too, so thank you.
I wanted to share with you guys some of the history and development of the R10, including crashes, dating back to the quadrotor that was called ROFL (pictured above) from sometime in 2011. Some of these videos/images you may have already seen as they were posted in Henry's bloghere on DIY drones at the time.
For brevity, I've only selected some of the key highlights, the rest of the historycan be found on our website.
These were some sketches that were made of the frame, and a few prototypes made of palstic and card. The aim was to minimze the number of components needed to build the frame, so a slot-together design was chosen, and that design remains core to the R10 frame today.
The initial testing was exeedingly difficult, at that point three things had to have right for anything to work - the electronics, which were completely new; the frame, which was untested; and the software, which was written from scratch. Unsurprisingly, mistakes and erroneous assumptions were made, which meant that things didn't work as well as planned at the start. The test rig was built in a garage using scraps of wood and clamps.
Eventually after a lot of head-scratching, research, maths, and frustration later, things started going well and it the quadrotor appeared to be behaving more like a flying machine than a glorified desk-fan.
I think many of you here will empathise with us about the lengths we went through to find workable tunings for the craft from scratch. This prompted the development of an XBee-enabled version of the control board, and a debug interface was created in Qt that had data-logging, sliders, and data-entry boxes. In this video, the quad is deliberately detuned mid-flight just for fun.
Things went well after that, however there were some persistent bugs in the flight code that caused transient unexpected behaviour, and gradual loss of control, a night flight ended in the worst crash to date, losing two motors and ESCs.
Many long nights of code tweaking, a complete rewrite of the AHRS, and new ESCs later, (Ok, I just skipped about 4 or 5 months of development time here, but just imagine countless crashes, whole bags of props smashed and a lot of swearing) we ended up with something that was acceptable
The ROFL quadrotor, and Henry make a brief appearence in this BBC News clip from earlier this Summer just before I joined: http://www.bbc.co.uk/news/uk-england-hampshire-18416111Henry and Universal Air were volunteering with TeenTech, a charity set up by BBC's Tomorrow's World presenter Maggie Philbin, which runs a program that invites schoolchildren to meet engineers in the real world and encourage them to seriously consider Engineering as a career. (BBC's facts are wrong, Henry was at Cambridge University, not Oxford)
Henry set up a "flying tent" which contained the ROFL to keep people safe from any prop breakages, and the ROFL quadrotor was also "kid-proofed" with a large padded yellow ring. The kids were allowed to try to fly the quadrotor. It's a nervous experience letting kids mess around with a $400 quadrotor, and some did manage to break parts of the quad despite the extra ring, but most were able to fly the quad thanks to the ultrasound altitude-hold and magnetometer-based "simplicity mode" (which allows you to yaw as much as you want and still have the quad roll or pitch in YOUR reference frame: stick left makes quad go left, regardless of yaw). There were even some who were surprisingly adept at flying without the altitude hold, we can see some promising drone pilots here.
And now, with even more code tweaks, a completely new flight controller, new operations in the US (that's me!), we end up with the R10 quadrotor system, which is currently on Kickstarter
What might not be clear in this video is that the flight controller is screwed into the side of one of the frame parts near the center, the flight controller doesn't actually feature in the video because we made the video before prototypes of the flight controller was available. And the ESCs have been heat-shrunk directly onto the aluminium frame for better heat dissipation.
I hope this has been informative!
Comments
Ok, here's what you do: always contact us. We might just be three busy people working out of a garage, but unlike faceless corporations, we'll reply to you and try to help however we can. Plus you've got personal email addresses of our tech team, please feel free to use them. If you want a new feature supported on our boards, particularly if it's a worthwhile feature like fixed-wing support, keep asking us about it, the louder you are, the more we understand what's important to you.
the website did not show any progress :-/
Yes, we did do a lot of optimisation to fit in some of the newer features, perhaps you should take a look at the latest firmware.
We learned a lot from Forebrain/Seraphim, that we're putting in Thalamus, moving the telemetry and gps code to the expansion means we reduce the flash usage, and also the LPC1347 on Thalamus has double the flash space of Forebrain.
thanks, but i already exceeded the flash size with my programming.
Also, I'll have a chat with Henry and see if we can schedule in some development time to get fixed-wing working for you.
Do you have some external I2C devices on the bus? And what version of the code are you using? We've not had any reports of that issue, and it hasn't come up in testing (R10 is flying fine on Forebrain/Seraphim) and we know that I2C under normal circumstances does not consume a significant portion of CPU time. In fact what's been limiting the CPU speed is actually the MAVLink telemetry and waiting for the UART. I suggest contacting our support email so we can properly help you.
The two major changes we made on Thalamus is to move the two slowest (and incidentally the two most expensive) components: the telemetry, and the GPS off the flight controller and onto an expansion port. This allows the I2C bus to run at 400kHz for the AHRS, and the expansion board deals with the slower UART and GPS stuff. (Expansion board communicates with main flight controller by fast 24MHz or 36MHz SPI bus)
you run out of cpu cycles when waiting for i2c data.
the handshake is to timeconsuming.
and you answered my question - thanks.
i have 2 imu's ... was waiting for the fixed wing support.
comminication seems to be a problem.
What's wrong?
i have not found any schema of the new flight controller.
if it still based on i2c, then there is something wrong.
As for fixed wing support, we did have some guys at Imperial College London working on getting Forebrain/Seraphim working in a Bixler, but unfortunately that project ran out of time, so unfortunately you're right, nada at the moment. Too many things to do, too little time, sorry. Hopefully we can find some people to help us with that, or we get some time to do that later on.