This is a schematic of my wiring of the ArduIMU v3. I hope to be able to use this soon as my own personal and custom RTH and 'stabilized mode' solution with some extra benefits highlighted below. One extra analog pin will be used in the future to read out the RSSI level from the attached RC receiver.
This setup demonstrates how far you can push this remarkable board. The W5100 chip provides 30Hz telemetry over wifi to the ground (just make sure to use the sparkfun one, I've seen other implementations with a hardware bug that only allow that SPI device on the bus). It requires a wifi AP specifically designed for long-range connections that allows you to set some specific parameters for your intended range, up to 50km. I still need to see how this performs in the field though, but theoretically it should work nicely.
I'm using this setup in combination with an HD IP camera for a 720p video feed that has 150-200ms latency. The weight of that cam is 160g, so about the same as a gopro+analogcam. The two IP devices onboard are then connected to the onboard LR wifi station by a stripped down ethernet hub I found that fit the requirements. Regular, non-shielded, ethernet cables are stripped down (2x twisted pairs without grey insulation), which over these short distances and bitrate aren't any problem (20-40cm). All in all, it's about 100g heavier than a full analog setup on the same platform (2.3kg).
The benefit of digital over analog is that it's much easier to integrate both the vehicle and sensors into more complex ground station applications. The tasks for piloting, navigation and mission execution for example can be cleanly separated in either machines or persons.This opens up a range of possibilities of how people with different responsibilities interact with the platform or how they use the data that the plane is sending down at high bitrates.
I hope this ignites interest a bit in higher speed datalinks. Although I did manage to find the electronics for connecting stuff together, the hubs and other fairly simple electronics leave many things to be desired. Hopefully more people will consider adding a magjack instead of a serial port on their boards. The advantage of connecting everything on the plane on a single databus is that you can recalibrate *everything* in the air. This opens up ways to use resources more effectively and redirect resources depending on the context within which they are needed. There's something to say for one databus connection that everything is connected to. This facilitates integration and makes interoperability a lot easier.
Comments
Cool, thanks!
e voila: http://code.google.com/p/arduino-ppm-servo/
Why should I mind? As long as it's your work and/or based on already open sourced code.
Thanks! I may well try that out. Indeed, the performance should be around that figure. Not sure if you could achieve 0.5us using something similar to:
------------------------------------
TCCR1A = ((1<<WGM10)|(1<<WGM11));
TCCR1B = ((1<<WGM13)|(1<<WGM12)|(1<<CS11)|(1<<ICES1));
OCR1A = 40000; // 0.5us tick => 50hz freq. The input capture routine
// assumes this 40000 for TOP.
// Enable Input Capture interrupt
TIMSK1 |= (1<<ICIE1);
ISR(TIMER1_CAPT_vect){
static uint16_t prev_icr;
static uint8_t frame_idx;
uint16_t icr;
uint16_t pwidth;
icr = ICR1;
// Calculate pulse width assuming timer overflow TOP = 40000
if ( icr < prev_icr ) {
pwidth = ( icr + 40000 ) - prev_icr;
} else {
pwidth = icr - prev_icr;
}
// Was it a sync pulse? If so, reset frame.
if ( pwidth > 8000 ) {
frame_idx=0;
} else {
// Save pulse into _PWM_RAW array.
if ( frame_idx < NUM_CHAN ) {
serinp[ frame_idx++ ] = pwidth;
if ( frame_idx >= NUM_CHAN ) {
radio_status = 1;
last_capture = millis();
}
}
}
// Save icr for next call.
prev_icr = icr;
}
------------------
but that's probably not even needed. I tried to find a piece of code where this problem was resolved, but only found the apm2.0 so far. If I get this working, do you mind if I opensource this afterwards?
I ended up the other way, using 8 bit timer for PPM input using the overflow interrupt to make a 16bit timer. Just add CNT (255) to a uint16 every overflow. And when a PPM pulse triggers the external interrupt, add the current CNT with the uint16 to get the current time.
Servo output is done quickly by cascading the output pins of a PORT using the 16bit timer (also used for ADC timing).
I don't have exact performance numbers but I remember it was in the 1us (1000 servo steps) range.
John, this board has two timers available. One is easily used for ppm sum analysis, but that consumes the 16-bit timer. Did you use an 8-bit timer to drive the servo's or the same timer for driving the servo's as well? I did try to use the same 16bit for both, but that didn't work. This will be an improvement for the v4 version I reckon (which I believe is coming up), as I'd expect at least 2 16-bit timers in there. Interested in what you did there and how good the performance of the servo's was.
Great stuff.. The older ArduIMU V1&2 was my favorite boards for a long time and would support 8 channel PPM input and solid 6ch servo output with a bit of trickery (more channels possible but pulse timing would suffer).
I used it as a 3 axis head-hold gyro in planes, Helicopter fly-bar less mixer etc.
Rana, it's not necessarily enough to increase output power, as many of these devices assume up to a certain distance away from the base station. So they hardcode the timeout between acknowledgements that the device expects. If that's too low, unnecessary retransmissions will occur and you'd see the transfer performance drop like crazy. Just a heads up there to be aware of that potential issue.
@Gerard and Rana: Interested in both your setups. Could you please provide more info on the camera models and setup? Thanks
This looks really interesting, I will probably contact you for details in the next few weeks some time. It's just to much other projects going right now.
Runar
-
1
-
2
of 2 Next