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.
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?
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)
I've not had much luck with the ICD2 programmer from Sparkfun so I went with an option that Bill had mentioned. The PICkit 2 was purchased from Microchip for about $40.00 including the USB cable. This is less than 1/2 the cost and about 1/2 the size of the Sparkfun programmer but you have to make a minor modification. The connector won't fit over the 6 pins of the Devboard because of the polarizing tab. Bill mentioned he got around this by removing the tab but I was afraid to try this and possibly damage the board. What I ended up doing was removing the top cover of the PICkit and removing enough of the cover around the connector to avoid contact with the Devboard polarizing tab.
Hi bill and all,
i would like to ask about the fail safe mode or can say RTL mode , In my case my RC doesnt have inbuilt fail safe , so i was just checking its behaviourof matrixnav RTL in case of signal loss. So here how i proceed ::
# I keep the plane leveled and and on the transmitter then i on the plane and wait for some 3 mins it get the GPS lock also and just move rudder in left and right direction.
# As rudder flipping stops i check the manual control of rudder and elevator and it was perfect in manual control.
#Next i switch it into RTL position and its elevator was perfect according to pitch of plane, but rudder little deviates to left side and respond according to yaw of plane .
# i bring back in manual control and switching of controls was also perfect it make rudder and elevator leveled.
# Next i just switch off transmitter to simulate the condition of signal loss. But here what i found that the rudder and elevator remain leveled and does not change according to pitch and yaw , is it normal or something wrong here.
# just a one more try i on the transmitter and bring it into RTL mode and this time i just off the transmitter and PLane seems to remain in RTL mode and its rudder and elevator behaves according to the pitch and yaw of plane .......
I m using a 7 channel radio of futaba on easystar plane.......
Does it conclude that it works only when signal loss is in RTL mode
I read in the posts and PDF guides that you experienced some problems with high frequency signals on the gyros (for instance when you tapped against the gyros). You solved it by oversampling at 5kHz, low pass filtering and decimation. BTW, the MatrixNav doc mentions 500 and not 5000 Hz. Is this simply a typo or did you lower the sampling frequency by any chance?
Looking at the LISY300AL datasheet, it is mentioned that there are three filters associated with it. One is a 400Hz cut-off builtin 1st order low pass filter. The second is an active 1st order low pass filter whose cut-off frequency can be adjusted with an external cap. The third is an optional external low pass filter (RC) that can be attached to the analog output of the gyro.
Now the question. Did you make use of all these filters and still experienced the symptoms that you fixed by means of oversampling?
Hi Bill,
We recently bought a UAV Dev Board from sparkfun, but we noticed that inputs 3 and 4 don't work...
Even debugging the application resulted in associated variables equals to 0 (counted pwm pulse length).
Inputs 1 and 2 instead are perfect!
Any suggestions?
Thanks in advance, bye!
I have contacted Aaron and we are in the process of RMA the ICD2.
Meanwhile I got to play a little with the FTDI board. To put this post into the context, I am talking with reference to this post of yours while we were discussing the voltage of FTDI board. I had to remove the solder on the breakout board to get the voltage back to 5v. Now here is the mystery. It seems I have successfully removed the solder tieing the board to 3.3v. In your post you mentioned, I need to connect to VCCIO pin. However when I checked the voltage of VCCIO relative to GND, I get 3.05 volts. The VCCIO pin is in the row opposite V3.3 pin. However, before desoldering it was 3.33v. On the other hand, the VCC on the board (this is the one besides the V3.3) is at 5v. I believe this VCC pin was soldered to V3.3 and as a result was tied to 3.3. Now that is has been desoldered it is back at its reference voltage.
So I have a mystery right now. In your post you said VCCIO pin of the FTDI board must be connected to VCC of the UAVDevBoard. However VCCIO is at 3.05v but VCC pin of the FTDI is at 5v. Did I make a mistake in desoldering or did I interpret you incorrectly?
Has anyone out there tried to apply the DCM approach to a terrestrial vehicle (car, bus, etc.) to determine pitch and roll while driving (these angles would of course include both the road attitude and vehicle attitude relative to the road due to stabilisers, dampers, shocks, and such).
Having read the draft documentation on the theory behind it, and the paper from Mahony et al. it seems that this approach would be well suited for use in cars too. Maybe even a bit of overkill. I.e. if it works for planes it seems that it should work equally well and probably even better for an earth bound vehicle which is more restricted in terms of movement/direction of acceleration and turns (no wind effect for example).
One thing that does not fit too well with the current DCM approach is that it makes use of the GPS indicated speed, which (if we leave the effect of wind alone for now) is never zero during flight, therefore always having a good indication of true (ground) speed. But in a car the GPS would show small (erroneous) values for the speed while the vehicle is actually standing still, possibly affecting the outcome of the rotational matrix. One can probably work around this though.
Replies
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
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)
i would like to ask about the fail safe mode or can say RTL mode , In my case my RC doesnt have inbuilt fail safe , so i was just checking its behaviourof matrixnav RTL in case of signal loss. So here how i proceed ::
# I keep the plane leveled and and on the transmitter then i on the plane and wait for some 3 mins it get the GPS lock also and just move rudder in left and right direction.
# As rudder flipping stops i check the manual control of rudder and elevator and it was perfect in manual control.
#Next i switch it into RTL position and its elevator was perfect according to pitch of plane, but rudder little deviates to left side and respond according to yaw of plane .
# i bring back in manual control and switching of controls was also perfect it make rudder and elevator leveled.
# Next i just switch off transmitter to simulate the condition of signal loss. But here what i found that the rudder and elevator remain leveled and does not change according to pitch and yaw , is it normal or something wrong here.
# just a one more try i on the transmitter and bring it into RTL mode and this time i just off the transmitter and PLane seems to remain in RTL mode and its rudder and elevator behaves according to the pitch and yaw of plane .......
I m using a 7 channel radio of futaba on easystar plane.......
Does it conclude that it works only when signal loss is in RTL mode
G.
I read in the posts and PDF guides that you experienced some problems with high frequency signals on the gyros (for instance when you tapped against the gyros). You solved it by oversampling at 5kHz, low pass filtering and decimation. BTW, the MatrixNav doc mentions 500 and not 5000 Hz. Is this simply a typo or did you lower the sampling frequency by any chance?
Looking at the LISY300AL datasheet, it is mentioned that there are three filters associated with it. One is a 400Hz cut-off builtin 1st order low pass filter. The second is an active 1st order low pass filter whose cut-off frequency can be adjusted with an external cap. The third is an optional external low pass filter (RC) that can be attached to the analog output of the gyro.
Now the question. Did you make use of all these filters and still experienced the symptoms that you fixed by means of oversampling?
Best regards,
Elardus
We recently bought a UAV Dev Board from sparkfun, but we noticed that inputs 3 and 4 don't work...
Even debugging the application resulted in associated variables equals to 0 (counted pwm pulse length).
Inputs 1 and 2 instead are perfect!
Any suggestions?
Thanks in advance, bye!
I have contacted Aaron and we are in the process of RMA the ICD2.
Meanwhile I got to play a little with the FTDI board. To put this post into the context, I am talking with reference to this post of yours while we were discussing the voltage of FTDI board. I had to remove the solder on the breakout board to get the voltage back to 5v. Now here is the mystery. It seems I have successfully removed the solder tieing the board to 3.3v. In your post you mentioned, I need to connect to VCCIO pin. However when I checked the voltage of VCCIO relative to GND, I get 3.05 volts. The VCCIO pin is in the row opposite V3.3 pin. However, before desoldering it was 3.33v. On the other hand, the VCC on the board (this is the one besides the V3.3) is at 5v. I believe this VCC pin was soldered to V3.3 and as a result was tied to 3.3. Now that is has been desoldered it is back at its reference voltage.
So I have a mystery right now. In your post you said VCCIO pin of the FTDI board must be connected to VCC of the UAVDevBoard. However VCCIO is at 3.05v but VCC pin of the FTDI is at 5v. Did I make a mistake in desoldering or did I interpret you incorrectly?
Thanks,
Dev
Has anyone out there tried to apply the DCM approach to a terrestrial vehicle (car, bus, etc.) to determine pitch and roll while driving (these angles would of course include both the road attitude and vehicle attitude relative to the road due to stabilisers, dampers, shocks, and such).
Having read the draft documentation on the theory behind it, and the paper from Mahony et al. it seems that this approach would be well suited for use in cars too. Maybe even a bit of overkill. I.e. if it works for planes it seems that it should work equally well and probably even better for an earth bound vehicle which is more restricted in terms of movement/direction of acceleration and turns (no wind effect for example).
One thing that does not fit too well with the current DCM approach is that it makes use of the GPS indicated speed, which (if we leave the effect of wind alone for now) is never zero during flight, therefore always having a good indication of true (ground) speed. But in a car the GPS would show small (erroneous) values for the speed while the vehicle is actually standing still, possibly affecting the outcome of the rotational matrix. One can probably work around this though.
Any thoughts?
BTW, great work Bill!
Regards,
Elardus
-
5
-
6
-
7
-
8
-
9
of 11 Next