Can anyone suggest a fix for this, I was running matrixpilot 2.02 and had to modify the options.file to work with 3 channels, elevator, rudder, throttle. All worked fine, then I edited the options file as I had left ailerons still enabled and now the ESC is telling me there is an abnormal servo input. It works absolutely fine straight from the Rx. I have the channel reversed on the Tx and have tried the software reversal in options.h but I am getting nowhere. My next step was to 'scope the o/p on ch3 from the UDB.
Any suggestions welcomed, the option file is attached
I'm not sure what 4 pin connector your referring to, but for something expendable like a connector, just cut the pins, and remove them one at a time. That's what I'd do with the gyros where possible. Solder wick, dipped in flux paste removes the solder pretty easily.
If you're working with something that requires multiple pins to be heated at once, a hot air rework station is the way to go. With solder paste, and a hot air station, even changing the CPU isn't all that hard to do.
I'm wondering, is the UAVDevBoard suitable for Quadcopter-project. The plan is to make it fully autonomous, but with the upgrade possibility to use radio to control the machine in the future. I have a few questions that I need answers to move on. I think this is the forum where is the best ackowledge:
2. There is four motors in quadcopter, in the DevBoard is only three Servo connections. Is there any spare pins that I can use for the fourth motor?
3. Is it ok to connect one or two parallel 3 Cell LiPo batteries(11,1V) to all four ESCs and then connect all control lines of the ESCs to the servo pins in the UAVBoard?
4. If I understood correct, the ESC gives about 5V through BEC, so there is no danger of noise that comes from the motor and ESC? The Board should be working good?
5. The PWM pulse for the ESC should be 8kHz. Servos are controlled usually with 50Hz frequency. Can I increase the PWM output to 8kHz?
6. If I want to upgrade my UAV with CameraCntlr and telemetry link, will I run out of pins on the Board? :P
There is a lot of questions and I know that I need to code almost a new autopilot, but this is a long project, a hobby that I'm willing to use time :)
Hi Bill,
I have a question about verifying the PWM in dsPIC30F4011 that you writed in UAV "DevBoard servoOut.c" function that called init_pwm(),
There is:
PTPER = 25000 ; // 25 millisecond period at 16 Mz clock, prescaler= 4
PTCONbits.PTCKPS = 1; // prescaler = 4
But by the information that I had saw in dsPIC Family data sheets like DS70046E it most doesn't work at 16 MHz clock and prescaler=4 (PTCONbits.PTCKPS = 1) and PTPER = 25000
Because by an example that Microchip had written in section 15.3.7 (Equation 15-1) (I supposed that when you don't verify the PTCONbits.PTMOD=0b00 but it should be Free Running Count Mode PWM and by the 25 milisecond period we have a PWM-Frequence Fpwm=40 Hz) "servoOut.c init_pwm()" most use a prescaler= 16 that could achieve PTPER = 25000 and 25 milisecond period time by 16 MHz clock, not a prescaler= 4. http://ww1.microchip.com/downloads/en/DeviceDoc/70046E.pdf
Please help me to understand it and finding my mistake.
Saeid.
The Matrixnav 2 version is working on an EasyStar? (just rudder, no ailerons)
----------
I like to use it together with the remzibi osd, similar way then the existing Ardupilot integration. It requires some additional features, so I have some program code questions.
- Is there some code version similar to the Ardupilot-remzibiOSD integration?
In detail:
- the osd requires nmea serial input, so my first question if this code version is working in nmea mode?
- the osd is working as display for messages like "manual mode", "stabilized mode", "waypoint 1" etc. It receives these messages on the same serial port as the nmea sentences. So the best solution if the devboard echoes the nmea sentences to the serial output and inserts the messages as well. My question if there is a sample code for echoing nmea sentences?
- the current serial speed setting is low, what happens if I set it higher? (because an additional message requirires some extra time between the nmea sentences) Are there possible timing problems?
- if the devboard is working in a different mode (binary or uBlox), is there a "translation to nmea" (for the output stream) code sample available?
I am familiar with embedded programming, however don't like to re-invent the wheel and working on code that maybe already available...
I have a question regarding pitch control in Matrix Pilot code (rev 2.0.1 , file pitchCtrl.c):
navElevMix is computed differently depending on the choice of RUDDER_NAVIGATION or AILERON_NAVIGATION:
navElevMix += rmat[6] * rudderElevMixGain * yaw_control; // when using RUDDER_NAVIGATION
navElevMix += rmat[6] * rollElevMixGain * rmat[6]; // when using AILERON_NAVIGATION
where
rmat[6] is the cosine of the roll angle, i.e. between aircraft X axis and earth Z axis
yaw_control comes from the code that steers the plane towards next waypoint
Why is used rmat[6] again instead of yaw_control in the computation when AILERON_NAVIGATION is used ?
Thank you
Another MPLAB problem, I'm afraid. I can program the board fine on an old Vista machine, but when I try to program it in an XP compatibility window (virtual XP mode) in Windows 7, I get the following error. I think everything else is identical to my Vista install. What am I doing wrong?
I am interested in autonomous flight, and have a project in mind which, with some help from other members of my local R/C club, I hope to implement in the long term. I've been investigating various hardware options (Ardupilot, etc) and the UAV board is very impressive.
I live on a small Caribbean island. My friends and I would like to design and build an aircraft which, after local testing, can carry out the following "missions":
1) Fly cross-country, from one end of the island to the other, a distance of ~35 kilometers. This would require some sort of RTH feature where H = Home and Home != Launch.
2) Circumnavigate the island, a distance of ~90 kilometers, then RTL.
3) Fly over the ocean, from a launch-point on our nearest island neighbour, to a predetermined landing point here, a flight of ~250 kilometers. Similar to #1, but involving a greater distance.
During the flight we would like to accumulate data including photographs/video for recovery and examination upon landing. Telemetry would be nice, if the distances don't make it impractical. The local regulatory body for aviation has expressed enthusiasm for such a project.
With appropriate software development, would the UAV board be suitable? I read that there was a 30 mile limit on flight range due to the use of 16-bit values in the navigation code. Is this set in stone? Also, if I understand it correctly, should the system lose contact with the transmitter on the ground, it switches automatically to the RTL mission profile. (Or am I completely mistaken about this?) For longer flights we would need the aircraft to fly the middle part of the mission without any signal from a ground-based transmitter.
Finally, all that I've read has shown the board being used with a Windows environment for development. I use Linux, and have no Windows computers. Is it possible to use the UAV board in a Linux environment?
Thank you Bill, thank you Riccardo,
I believe there is no such regulation in Poland regarding small (under 5 kg) aircraft models flying under 300 meters high yet. Despite of this our small FPV community (rc-cam.pl) is very sensitive about safety. Thats why I am thinking about UAVDB as "last instance" if anythig else would fail.
@ Ric - I hope you will fly and make movies despite your recent crash. Do you have any guesses about the reason of the "death spiral" of your model? Chris could have pointed some good directions IMHO.
Best regards
Michal
Replies
Any suggestions welcomed, the option file is attached
regards
chris
options.h
I'm not sure what 4 pin connector your referring to, but for something expendable like a connector, just cut the pins, and remove them one at a time. That's what I'd do with the gyros where possible. Solder wick, dipped in flux paste removes the solder pretty easily.
If you're working with something that requires multiple pins to be heated at once, a hot air rework station is the way to go. With solder paste, and a hot air station, even changing the CPU isn't all that hard to do.
Rusty
If its not too late I would like to see one with flat gyros, and more R/C inputs and ouputs.
Keep up the good work.
I'm wondering, is the UAVDevBoard suitable for Quadcopter-project. The plan is to make it fully autonomous, but with the upgrade possibility to use radio to control the machine in the future. I have a few questions that I need answers to move on. I think this is the forum where is the best ackowledge:
1. I should use the Boards servo connections to control motors. Is it possible to connect this kind of ESC to the servo pins: http://www.headsuprc.com/servlet/the-1413/20A-POWER-UP-Brushless/De...
2. There is four motors in quadcopter, in the DevBoard is only three Servo connections. Is there any spare pins that I can use for the fourth motor?
3. Is it ok to connect one or two parallel 3 Cell LiPo batteries(11,1V) to all four ESCs and then connect all control lines of the ESCs to the servo pins in the UAVBoard?
4. If I understood correct, the ESC gives about 5V through BEC, so there is no danger of noise that comes from the motor and ESC? The Board should be working good?
5. The PWM pulse for the ESC should be 8kHz. Servos are controlled usually with 50Hz frequency. Can I increase the PWM output to 8kHz?
6. If I want to upgrade my UAV with CameraCntlr and telemetry link, will I run out of pins on the Board? :P
There is a lot of questions and I know that I need to code almost a new autopilot, but this is a long project, a hobby that I'm willing to use time :)
Regards,
QU
I have a question about verifying the PWM in dsPIC30F4011 that you writed in UAV "DevBoard servoOut.c" function that called init_pwm(),
There is:
PTPER = 25000 ; // 25 millisecond period at 16 Mz clock, prescaler= 4
PTCONbits.PTCKPS = 1; // prescaler = 4
But by the information that I had saw in dsPIC Family data sheets like DS70046E it most doesn't work at 16 MHz clock and prescaler=4 (PTCONbits.PTCKPS = 1) and PTPER = 25000
Because by an example that Microchip had written in section 15.3.7 (Equation 15-1) (I supposed that when you don't verify the PTCONbits.PTMOD=0b00 but it should be Free Running Count Mode PWM and by the 25 milisecond period we have a PWM-Frequence Fpwm=40 Hz) "servoOut.c init_pwm()" most use a prescaler= 16 that could achieve PTPER = 25000 and 25 milisecond period time by 16 MHz clock, not a prescaler= 4.
http://ww1.microchip.com/downloads/en/DeviceDoc/70046E.pdf
Please help me to understand it and finding my mistake.
Saeid.
----------
I like to use it together with the remzibi osd, similar way then the existing Ardupilot integration. It requires some additional features, so I have some program code questions.
- Is there some code version similar to the Ardupilot-remzibiOSD integration?
In detail:
- the osd requires nmea serial input, so my first question if this code version is working in nmea mode?
- the osd is working as display for messages like "manual mode", "stabilized mode", "waypoint 1" etc. It receives these messages on the same serial port as the nmea sentences. So the best solution if the devboard echoes the nmea sentences to the serial output and inserts the messages as well. My question if there is a sample code for echoing nmea sentences?
- the current serial speed setting is low, what happens if I set it higher? (because an additional message requirires some extra time between the nmea sentences) Are there possible timing problems?
- if the devboard is working in a different mode (binary or uBlox), is there a "translation to nmea" (for the output stream) code sample available?
I am familiar with embedded programming, however don't like to re-invent the wheel and working on code that maybe already available...
Thanks,
I have a question regarding pitch control in Matrix Pilot code (rev 2.0.1 , file pitchCtrl.c):
navElevMix is computed differently depending on the choice of RUDDER_NAVIGATION or AILERON_NAVIGATION:
if ( RUDDER_NAVIGATION && flags._.pitch_feedback )
{
pitchAccum.WW = __builtin_mulss( rmat[6] , rudderElevMixGain ) ;
pitchAccum.WW = __builtin_mulss( pitchAccum._.W1 , yaw_control ) << 4 ;
navElevMix += pitchAccum._.W1 ;
}
if ( AILERON_NAVIGATION && flags._.pitch_feedback )
{
pitchAccum.WW = __builtin_mulss( rmat[6] , rollElevMixGain ) << 1 ;
pitchAccum.WW = __builtin_mulss( pitchAccum._.W1 , rmat[6] ) >> 3 ;
navElevMix += pitchAccum._.W1 ;
}
Roughly semplifying (forgive me):
navElevMix += rmat[6] * rudderElevMixGain * yaw_control; // when using RUDDER_NAVIGATION
navElevMix += rmat[6] * rollElevMixGain * rmat[6]; // when using AILERON_NAVIGATION
where
rmat[6] is the cosine of the roll angle, i.e. between aircraft X axis and earth Z axis
yaw_control comes from the code that steers the plane towards next waypoint
Why is used rmat[6] again instead of yaw_control in the computation when AILERON_NAVIGATION is used ?
Thank you
I live on a small Caribbean island. My friends and I would like to design and build an aircraft which, after local testing, can carry out the following "missions":
1) Fly cross-country, from one end of the island to the other, a distance of ~35 kilometers. This would require some sort of RTH feature where H = Home and Home != Launch.
2) Circumnavigate the island, a distance of ~90 kilometers, then RTL.
3) Fly over the ocean, from a launch-point on our nearest island neighbour, to a predetermined landing point here, a flight of ~250 kilometers. Similar to #1, but involving a greater distance.
During the flight we would like to accumulate data including photographs/video for recovery and examination upon landing. Telemetry would be nice, if the distances don't make it impractical. The local regulatory body for aviation has expressed enthusiasm for such a project.
With appropriate software development, would the UAV board be suitable? I read that there was a 30 mile limit on flight range due to the use of 16-bit values in the navigation code. Is this set in stone? Also, if I understand it correctly, should the system lose contact with the transmitter on the ground, it switches automatically to the RTL mission profile. (Or am I completely mistaken about this?) For longer flights we would need the aircraft to fly the middle part of the mission without any signal from a ground-based transmitter.
Finally, all that I've read has shown the board being used with a Windows environment for development. I use Linux, and have no Windows computers. Is it possible to use the UAV board in a Linux environment?
Comments, please. Am I barking up the wrong tree?
I believe there is no such regulation in Poland regarding small (under 5 kg) aircraft models flying under 300 meters high yet. Despite of this our small FPV community (rc-cam.pl) is very sensitive about safety. Thats why I am thinking about UAVDB as "last instance" if anythig else would fail.
@ Ric - I hope you will fly and make movies despite your recent crash. Do you have any guesses about the reason of the "death spiral" of your model? Chris could have pointed some good directions IMHO.
Best regards
Michal
-
3
-
4
-
5
-
6
-
7
of 14 Next