Comment by Hugo Vincent on January 15, 2008 at 3:02am

Here is an open-hardware open-firmware board I designed to do servo switching (#3 in the article) in a failsafe way. It also can monitor battery levels or RF link status and switch based on that too. http://open.grcnz.com/trac/servo-switch/wiki

The hardware is also capable of many other things that haven't been implemented in firmware, like MiniSSC-II servo controller emulation (through the built in serial port), servo logging (there is onboard flash memory), etc

Also of note: the failsafe code is implemented in hardware (in a Xilinx CPLD) to eliminate the possibility of a software crash rendering the plane uncontrollable. That means that, although the switch contains a microcontroller running software, this is used for ancillary purposes and the core switching has no software in the loop that could crash.

Comment by James Hall on January 15, 2008 at 4:29am

See a document I uploaded, search on the Discussion topic "Failsafe Document". Has some interesting reading, some circuit diagrams and some code in C. Its primarly devoted around a helicopter but still usefull. I got a kick out of the tilt sensor, a ball in a liquid which when tilted, closed a circuit by physical contact. I wonder if this would really work instead of a expensive IMUs?

Comment by Hugo Vincent on January 15, 2008 at 6:00am

"I got a kick out of the tilt sensor, a ball in a liquid which when tilted, closed a circuit by physical contact. I wonder if this would really work instead of expensive IMUs?"

Nope, it would work exactly the same as a 2-axis accelerometer with a really low bandwidth (due to the inertia of the mechanical ball) and low resolution/quantization. And as you probably know, an accelerometer-only IMU is very limited.

You could emulate it with a cheap 2-axis accelerometer, low-pass filter the outputs, and quantize with a 1-bit ADC (i.e. a comparator).

3D Robotics Comment by Chris Anderson on January 15, 2008 at 11:48am

Hugo,

First, great to hear from you: I'm a fan! (watched your presentation, been following the project),

Second, what a great board! I posted about it on RCGroups and people were wondering how to get it. I assume the answer is "DIY", but if you know of any way to buy finished boards I'd love to pass it on. If not, would you have any objection to us fabbing a stack of them and selling them for cost?

Comment by Hugo Vincent on January 15, 2008 at 2:44pm

Hi Chris,

Thanks! I am no longer with the research company that I was working for at the time I designed the board, however while I was there, we fabbed 45 boards (but only a subset of those were populated with components). I will enquire if any of those are still available for purchase. I'm sure they wouldn't mind selling the PCBs themselves (blank, unpopulated), but, as I understand, they don't really have the capacity to do assembly work. If the assembly (populating the board with the components) were out-sourced the price might rise considerably.

Can you please post a link to the RCGroups discussion. If I can establish an approximate number of interested people, I might be able to arrange production myself.

3D Robotics Comment by Chris Anderson on January 15, 2008 at 2:48pm

Here's the link:
http://www.rcgroups.com/forums/showthread.php?t=801709

Let me know if there's anything I can do to help.

Comment by Jason Striegel on January 15, 2008 at 9:45pm

What are your thoughts on using a separate microcontroller with the sole purpose of switching input and monitoring battery life or other critical events (maybe radio signal)? The routine can be simple enough to be trusted, and you can fit the whole package into a single IC.

3D Robotics Comment by Chris Anderson on January 15, 2008 at 9:52pm

You mean on the same board as the autopilot? I suppose if you don't lose power to that board, it would be fine. Certainly better than what we're doing with our Basic Stamp autopilot right now ;-)

Comment by Jason Striegel on January 15, 2008 at 10:06pm

Yeah, I'm thinking if you loose power, you're probably dead anyway. You could loose power to the radio electronics or to a servo too. I don't know if it's valid, but my main worry is the software using the same chip for control switching that's being used to read and process data from the GPS, accelerometers, gyros, etc. There are a number of systems that could fail and affect the control loop. If something wonky happens with the GPS and a serial read blocks, or if you have a mistake in your code and divide by zero, you loose control (and with the aircraft still at full power).

So you could have 2 controllers. Controller 1 takes input from the radio, gps, sensors, etc., does the math, and produces an output signal. Controller 2 also takes pwm signals from the radio and additionally from controller 1's processed output, and it chooses the appropriate source to output to the motors.

The code in the switching controller is very simple, and you go over it with a fine tooth comb and prove its validity. Then you can experiment with your code in the flight controller all you like and not have to worry about something catastrophic happening.

3D Robotics Comment by Chris Anderson on January 15, 2008 at 10:22pm

This is actually a great idea. My only concern is this: The optimal servo output of a Stamp is serial, not PWM (too much processing overhead). That means that the MUX would have to take PWM from one source and serial from the other, which is totally possible but introduces a good bit of additional complexity. Which means another potential point of failure?

Comment

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page