Ardupilot based 4 channel servo subsystem.


I've mention this project a couple times and finally, here it is.


What: This is an ardupilot board that has been modified as per the picture above. The modifications allow reading the position of 4 channels from your receiver and driving 4 output servos. The firmware has been altered to remove support for gps and instead use the one ATMega328 serial port to write out the receiver channel data and read in servo position commands from an external computer.


Why: I am working on a gumstix based autopilot. The gumstix runs all the "smarts" but I need a simple way to decode receiver channels and drive servos, and I need a manual override safety switch. The ardupilot provides both of these.


I'm no master solder expert, but I managed to avoid soldering my fingers to the board and everything works, so I'm happy.


I am attaching my firmware mods (based on the Ardupilot-2.2.3 firmware with lots of hacking and chopping.) My current incantation only does servos, but I tried to leave the door open to attaching other analog sensors which could then also be reported to the host computer ... this could include pressure sensors, voltage sensors, etc.


ArduPilot_SensorHead_v1.3.zip


I ran into problems using pulseIn() to read the receiver pulses (which made sense after I looked at what pulseIn() is actually doing) so I wrote my own routine that watches all 4 channels at once and times the pulse. I haven't convinced myself that I have the overall board timing locked down exactly the way I want it, but for now it seems to work pretty well. I can read 4 channels of data off my receiver (+ the selection channel state) and I can drive 4 servos from the host computer (tested with a simple sine wave function.)


On the subject of hardware in the loop testing, a board mod like the one described here could be used to read the servo outputs of a standard ardupilot, and feed them to a simulator to be translated into control surface commands there. Some additional software/communication work would be required, but it should be a reasonably straight forward project.

Views: 901


Developer
Comment by Pat Hickey on March 29, 2010 at 6:03pm
If you're working on a gumstix based autopilot, you might consider the work I've done porting Paparazzi to Linux - http://moreproductive.org/autopilot/ . Let me know if you're interested and we could talk about the specifics of integrating this ardupilot based servo input/output. I currently use a Pololu servo output board and servo multiplexer, but this will be a more flexible solution.
Comment by bGatti on March 29, 2010 at 6:56pm
Good job, this supports my theory that there are many other applications/markets for true-Ardupilot* in 3 Arduino-sized bites:
1. Servoing
2. IMUing
3. UAVing
* true ArduPilot is any board with one and only one "Arduino" related** mcu.
**related means responsible for the Trendiness of the Arduino Keyword (which I believe excludes the MEGA - because "Arduino MEGA" has no s...)

Comment by Greg Fletcher on March 29, 2010 at 7:24pm
Curt , Don't use the pulseIn() command. It sucks. Down load Ardupilot 2.5 and look at the radio.pde . It uses pin change interupts for all the inputs. You need to get the data sheet for the 328p and slog through it to figure out how it works. I did it and added another channel to a different pin and it worked. And now I know how to set up and use interrupts:) I had problems with glitches using pulseIn() and it really slows things down.

Greg

Developer
Comment by Doug Weibel on March 29, 2010 at 7:42pm
The problem with doing 4 channels on Ardupilot is the limited number of timers and comparators. I think you will find that you either have to build in a lot of latency so that you can share timer one to form the pwm output for all 4 channels or you have to use timer two and have lower resolution on two channels.

3D Robotics
Comment by Chris Anderson on March 29, 2010 at 8:53pm
Better yet, use the code from our Arduino-based PPM encoder, which is optimized for four channels. Just change it so that rather than outputting PPM, it outputs whatever you want, including a serial stream with the servo position info.

Rock solid and sure to work!

Developer
Comment by Jason Short on March 29, 2010 at 10:17pm
Yes, if you don't use interrupts your functions will pause while incoming serial or other interrupt driven events occur. If you don't need to read in serial you can always just disable interrupts and count cycles.
2.5 and the PPM encoder use much more elegant solutions.
Comment by Andre S on March 29, 2010 at 10:27pm
Thanks Curt for sharing! I'm planning to do something similar in the long run when the ArduPilotMega comes out. But I'm planning to let the Ardupilot do its thing and the gumstix is more for setting waypoints, driving a webcam, doing Wifi, etc. I was hoping to use I2C for communication between the two but I'm still a newbie in terms of embedded systems. So far I have been playing with the gumstix and it works great. Good luck, please keep us posted! (would be also interested in code on the gumstix side if you plan to share)
Comment by Christopher Barnes on March 30, 2010 at 2:51pm
ArduNXT (the poor relation of DIYDrones dev teams - as it is going rather slowly) which is setting out to provide a Lego Mindstorms NXT interface with Radio Contol and Servos based on an ArduPilot PCB is quite similar to your 4 channel servo sub-system - it is just that the "other" interface is I2C with the NXT instead of serial. While I've not made a blog post about progress yet, the software is actually fully working in this respect and includes 4 channels of PWM input and output which are all interrupt driven with very minimal processor load and latency - the 'extra' two PWM input channels are carefully selected to be on different ports so that each has a unique interrupt service routine - so not time is wasted in deciding which pin has changed state. You can access the the source code (all comments and feedback welcome):
http://code.google.com/p/ardunxt/

I hope to post pictures of the prototype hardware and use in an NXT robot some time over the Easter vacation.
Comment by Tom Hastie on March 31, 2010 at 7:11am
Can anyone point me in the direction of some more information on how the servo end of the Ardupilot board works? Up until now, I assumed that the ATMega was already receiving all 4 channels of servo data. (This is implied on the Ardupilot main page - "Four RC-in channels (plus the autopilot on/off channel) can be processed by the autopilot. Autopilot can also control four channels out."). Now, looking at this thread, it seems that only 3 are currently supported.

The wiki manual only says that "Output 4 is not currently used". Are there reasons why this hasn't been implemented yet? Doug implies that 4 channels is too much for the Ardupilot.

I *think* I've read the whole manual, but maybe I've missed something?

Thanks for the help,

Tom

3D Robotics
Comment by Chris Anderson on March 31, 2010 at 7:35am
Tom,

There are four inputs (plus mode) on the board, but you need to do some special wiring to enable to fourth as we're using those Atmega pins for other functions in the current code. Ardupilot certainly can handle four or more channels (the same architecture powers our 4 channel PPM encoder), but there was very little demand for the fourth channel so we used that for other purposes in the base code.

If you want more channels, you'll be delighted with ArduPilot Mega, which will support eight channels right out of the box.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service