Replies to This Discussion

Permalink Reply by William Premerlani on September 26, 2009 at 2:14pm

Bryan,

Thats a great idea, to modify the PICkit2 to fit the polarizing tab.

Now, if only someone would have trouble with the PICkit2, we could contact Microchip and have them get to the bottom of the mystery of why some ICD2s will not work under MPLAB version 8.x. ;-)

Bill

• ▶ Reply

Permalink Reply by Charles Birlenbach on September 28, 2009 at 1:04am

Hi,
since this is my first Post here, I'd like to start by congratulating on this more than nice Board and it's excellent Firmware. I've been using it for a month now and am really impressed. Very nice work indeed and I can't hardly wait to see what you will integrate next :)

Now, the reason for this Post is with the MPLAB 8.x/ICD2 Problem. I too had the issue that, whilst using MPLAB 8.x, the ICD2 would never detect the Red Board (don't have a Green one, so no idea how it would behave there). As I found it to be really annoying to use MPLAB 7.5, I did some try-and-error and ended up with this: If you install MPLAB 7.5 and install the bundled ICD2 OS (he asked me to do so right at the first connect), then uninstall 7.5 and install MPLAB 8.x and NOT install the bundled ICD2 OS this time but instead keep the original 7.5 OS on your ICD2, everything will work fine. Well, MPLAB will complain about you not having installed the latest OS, but that message can be ignored.

Haven't seen this yet in the Forum, so I tought perhaps this can be of help to someone?

Keep up the good work :)

• ▶ Reply

Permalink Reply by William Premerlani on September 28, 2009 at 3:50am

Charles,

It must have taken you a lot of trial and error to come up with your great solution to the ICD2 issue. I will definitely recommend it to the next person who reports a problem with their ICD2 and MPLAB 8.x. Thank you very much.

Regarding what is coming next, Ben Levitt has been busy extending the code. In particular, he figured out a way to get 5 PWM inputs and 5 PWM outputs, and he has options for just about any configuration you can think of. He is in the testing and debugging stage, right now. As soon as its flight-ready, we will release it.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Scouser on September 28, 2009 at 9:56am

Hi all,

My solution to connecting my PICkit2 to my dev board was to make-up a lead using 0.1” Series Socket PCB Housings that match the pins on the board.

This way I could leave the lead connected to the dev board, which could be installed deep inside the aircraft, where it was less vulnerable to damage.

My sockets came from Maplin's in UK but I see that they longer have the 6 pin sockets but they should be easy to find.

You buy the socket terminals separately (Maplin code YW25C or Ebay), and solder or crimp the terminals onto the wires. I use sockets on the both ends of 6-lead telephone cable. To connect to the PICkit2 I use pin jumpers and highlight the number 1 pin position clearly.

Scouser

• ▶ Reply

Permalink Reply by Chris Anderson on September 27, 2009 at 11:45am

Bill,

I'm getting ready to test fly the red board with AileronAssist 1.8 in the BusyBee. I'm a little confused about one thing, however. It is possible to use the your RC transmitter to choose between RTL and Waypoint modes? As I understand the documention, the middle setting of a three-position toggle is stabilization mode in all versions of the code, but do you have to burn new code (1.7 vs. 1.8) to choose between waypoint or RTL mode?

Is there any way to do what we do with ArduPilot, which is "middle toggle" = waypoint, while "up toggle" = RTL? (If you unplug the GPS, you get stabilization)

• ▶ Reply

Permalink Reply by William Premerlani on September 27, 2009 at 12:20pm

Chris,

I like what you do with ArduPilot, its a great idea, but that is not how AileronAssist works. I will put it on my list of things to do.

In AileronAssist 1.8, the control switch choices are manual, stabilized, and waypoint mode. The only time RTL mode kicks in is if pulses stop coming in on channel 4, then it serves as a fail safe. Then the plane will return to the power up point. However if your receiver has some sort of fail safe that provides pulses no matter what, this mode will not engage.

With AileronAssist 1.8, you can achieve an RTL function by setting the first waypoint for where you would like the plane to go in a commanded RTL situation. The way the controls work, no matter where the plane is when you engage waypoints, the plane will head to the first waypoint before running through the pattern. At any time you want, you can command the plane to return to the first point by disengaging waypoints, and then re-engaging after a second or two.

By the way, you mentioned that you are using a red board. Please be aware that the LISY gyros on the the red board are more vulnerable to vibration than the ADI gyros on the green board. So, as part of your ground check, I suggest that you engage stabilized mode, check the response to pitch, and then run the motor up to full power, and check the response to pitch again. If you get the same response with or without the motor running, everything is fine. The only difference you should see with and without the motor running is with altitude hold, the elevator will deflect up a little bit when the motor turns on. This is normal. A vibration issue will show up as large, random deflections of the elevator.

If there is a vibration issue, I suggest that you provide some vibration isolation in your mounting of the board.

One last note, in case you are thinking about running the waypoints T3 contest pattern that comes with AileronAssist 1.8. If you use the default settings, you will set a record for the longest time. The default settings were selected with sailplanes in mind, and focus on conserving altitude rather than achieving high speed.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Adam Bellchambers on September 28, 2009 at 3:54am

Evening all!

There seems to be a bit of interest in getting the dev board to work with the UBLOX chipset GPS receivers, i've seen several people ask about it, and Bill has commented that all is required is to write appropriate firmware. My dev board should arrive tomorrow, along with a GS407 GPS unit, which is the U-Blox 5hz chipset with the Sarantel helical antenna. (i'm more interested the potentially more robust reception of the helical antenna than i am with the 5hz update rate). Anyway, i've taken it upon myself to rewrite a version of gpsParse to suit the UBX protocol. So far i've gone through both protocols and found the appropriate messages and variables that need to be parsed to get the same info as what the SIRF protocol provides. The only ones i'm having trouble finding direct equivalents for are the Mode1, Mode2, Nav Valid and NAV Type variables.

NAV Type appears to include all the same data as the Mode1 and Mode2 variables, and Nav Valid is 2 bytes composed of one status bit and 15 reserved bits.

Furthermore, none of these variable appear to be actually used in the code other than being declared in a few places and assigned in the parsing code. (looking at the MatrixNav 1.7 code at the moment)

So i was hoping for some guidance, on whether this information is actually required or not. I think i can get most of the relevant info out of the UBX messages, it would just mean reading a bunch of messages that we probably otherwise don't need to parse.

Also if you can offer any guidance on the best way to structure the header files so that the code could be integrated back into your code base later on, that would be most appreciated. At the moment i was just going to run a seperate header file called gpsParseUBX, and select between it and your original one using #IFDEF's and a #DEFINE UBX in the appropriate places. Is this the best way to proceed?

Regards

Adam Bellchambers

• ▶ Reply

Permalink Reply by Adam Bellchambers on September 28, 2009 at 5:01am

correction, nav_valid is used in the code, so i will find a UBX equivalent of that, but just to confirm, the only bit that is used for our application is bit 0?

• ▶ Reply

Permalink Reply by William Premerlani on September 28, 2009 at 11:46am

Adam,

I am very grateful that you are integrating the uBlox. That's wonderful. Thank you very much.

I am not using Mode1, Mode2, and NAVType, but I am a packrat who hates to throw anything away that might be useful some day, so I saved them. But I have never used for anything and never will. You can ignore them.

Regarding Nav Valid, right now for the EM406, all that is done right now is a check that Nav Valid is zero, which is an indication that the GPS has enough satellites in view to perform a valid location computation. So, all you have to do is find out when the UBX is up and running, and set Nav Valid to zero.

The person to ask about integrating your firmware back into released verions is Ben Levitt. He has added some useful extensions himself, such as for 5 PWM inputs and 6 PWM outputs, and has taken over the responsibility of managing the source code.

The best way to communicate with him is to join a UAV DevBoard developers group that has formed. Anyone who wants to join is welcome. It will give you access to a versioning repository for all of the source code.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Bryan Cuervo on October 4, 2009 at 6:00am

I had similar issues as Scouser trying to connect my PICkit 2 to the board while it was buried in the fuselage. I ended up getting two servo extensions, cutting off the female ends and soldering them directly to the DEVboard. The male ends were CA'd together to create a connector to the PICkit 2. When finished uploading, I just tuck the connector between the foam and fuselage wall.

• ▶ Reply

Permalink Reply by Andrea Sala on October 9, 2009 at 1:07pm

Hi Bill,
I really need some assistance.
I've tested so far 4(!!) different red boards, but no one seemed to correctly parse the signal on input 3 and 4.
I tested them using stock sparkfun self-test firmware and also with self-compiled test firmware downloaded from here.
I've also made tests with AileronAssist firmware (without much success due to bad input channel 4 recongition).

I don't really know what I'm doing wrong, and it seems quite strange that all the 4 boards where bad.
I'm testing with futaba radio equipment, powered with 5/6 Volt stabilized power supply.
Input 1 and 2 are perfect, but input 3 and 4 aren't working at all, or seems to sometimes read one pulse sporadically.

Do you have any suggestion?
You can also contact me by email, so we can go to further investigation.
Thanks.
Andrea.

• ▶ Reply

Permalink Reply by 13brv3 on October 9, 2009 at 1:27pm

Hi Andrea,

Interesting timing, since I was going to ask a similar question. I'm not using channel 3 at the moment, but channel 4 was giving me fits yesterday. I could get it all working on the bench, then when I installed it in the plane, it got very erratic. Sometimes it would see the mode change, and sometimes not. Other times it would turn on and off at random.

After trying different receivers, GPS's, retesting, resoldering connections, etc, I finally realized that I was using a 4.8V flight battery on the bench, and the plane was using power from the ESC. Sure enough, if I use the battery for the receiver/AP power, it works in the plane as well. That was as far as I got last night, and I'll be scoping the ESC power, and doing some further investigation in a few minutes.

Stabilized power supplies aren't necessarily all that clean, so maybe you've got the same issue. It wouldn't hurt to give a battery a try. If the battery works for you as well, then perhaps the board needs a bit more power filtering.

Good luck,
Rusty (REALLY glad to be rid of IR sensors)

• ▶ Reply

• ‹ Previous
• 1
• …
• 26
• 27
• 28
• 29
• 30
• …
• 56
• Next ›
• Page