Questions about the firmware

[Dave_fr]

I created this discussion for everyone to ask random questions about the firmware. If like me, you are going through the code you must have noticed tom's professionnalism. Congratulations Tom !

[Dave_fr]

In navigation.c, navigation_do_circle method I don't understand the following lines of code :

float pointlon = current_code->y + sin(next_alpha) * next_r / longitude_meter_per_radian;
float pointlat = current_code->x + cos(next_alpha) * next_r / latitude_meter_per_radian;



navigation_data.desired_heading_rad = heading_rad_fromto(sensor_data.gps.longitude_rad - pointlon,
sensor_data.gps.latitude_rad - pointlat);


I thought that [current_code->x,current_code->y] was the desired center of the circle but then I don't understand what [pointlon,pointlat] represent ?

[Tom]

Hi Dave,

You'll need to take your trigoniometrics book from high school:

We want to calculate the point that is on the edge of the circle, with an angle of "next_alpha" with 0° towards the north (upwards). Then we know:

X = center_x + sin(a) * radius and Y = center_y + cos(a) * radius

next_r is the radius of the circle. current_code->x,current_code->y is indeed the center of the circle.

longitude_meter_per_radian and latitude_meter_per_radian are scaling factors to scale the latitude and longitude part from "meter" to "degrees/radians" in latitude and longitude


I hope this makes any sense

[Dave_fr]

Thanks man,

Ok now I've got it. It's just that I didn't understand the whole concept. By the way how did you come up with such an elaborate routine ? Is it similar to one used in paparazzi ?
Anyway I've learnt a whole lot of staff. I received my board and can't wait to get started with it.

[Tom]

Yes the circling algorithm is inspired by paparazzi.

[Dave_fr]

Hey Tom,

I was wondering how did you debug your firmware ?
I would love to continue your work and make some changes to the firmware. As I've already mentioned to you I have pickit 2 which I think does not allow any sort of real time debugging.
Amongst other randoms thoughts :
1)I have a digital airspeed sensor a got from DIY drones and would like to interface with the board. I suppose 3.3V is used as reference voltage for the ADC right ?
2)Are you planning on adding an integral loop to the kalman filter to compensate for the slow temperature changes ?
3)Would it be easy to add a page to the configuration desktop app in order to allow the setting of another data structure within the config structure ?
4)Last but not least. Are you happy about the idea of other people playing around the code ?

The deeper I look into your code the more impressed I am.

Best regards,

David

[Tom]

Hi David,

There were 3 ways of debugging:
- A lot of printf's
- In my pre-gluon firmware, I had a hardware in the loop simulator: I wrote a small flight simulator that would write the fake GPS and attitude signals to the gluon module, which would then write the aileron and elevator position to the flight simulator. I used this to write most of the navigation part. I'm also planning to port it to the gluon firmware... but I only need time! There are some cool flightsimulators that have TCP-ports available that offer the position and attitude data. This data could be written to the gluon module that would act as if it was real sensor data. Very cool things
- Careful flight tests
- Datalogging at 50Hz to dataflash and "replaying" this situation as if it was real data. See http://code.google.com/p/gluonpilot/sou ... _csv.c#412 and http://code.google.com/p/gluonpilot/sou ... _csv.c#647
- Load 50Hz datalogging to Matlab and use Matlab algorithms: http://gluonpilot.com/wiki/Matlab_attitude_estimation
- I never really used the ICD2 debugging as it probably won't work in a real-time system.

1) Yes, the microcontroller and ADC run at 3V3. The Batt input (for battery voltage) is not yet used, but is an analog input with a voltage divider applied to it. The SPI and I2C ports are available for interfacing with other hardware components.
2) Yes I'm actually planning to do that in the next release. Good you noticed this was missing
3) I tried to make this as easy as possible. Of course, the first time you'll have to look here and there to see how it's done. No worries, just ask if you don't see the light right away.
4) Of course! That's why the code is open source!

Tom

[Dave_fr]

Very cool !

Hardware in loop with a flight simulator must me an excellent tool to test new bits of the code.
I'm planning on applying a complementary filter in order to combine the GPS heading and gyros, I had some test runs in my car in order to estimate the delay in the GPS heading response. I'll probably start looking at the wind problem later.

1)How does printf works doesn't it short cut the RTOS ?
2)What do you recommand when programming : the use the pick kit2 or the bootloader + ftdi ?
3)How much does the voltage get divided when using the ADC connected to the bat port ?
4)Do you think that we can add a page to the config tool and enlarge the firmware config data structure so that we can set some extra variables for people who want to play with the code and need to modify values at run time ?

[Tom]

Hi Dave,

1) How could it short-circuit the RTOS? You can look at it as an ordinairy function
2) I use both. The bootloader is usually faster (but not integrated into MpLab)
3) It's about a division by 4 in voltage. You can change the resistors if you prefer another division rate.
4) Sure, what do you have in mind? Some 'custom' float point values?

[TCMontague]

I hope this is the right place to ask this question, but here goes:

In the code, you run the Kalman filter with an input dt = .02, and an input of .005 for the quadcopter. Where did these numbers come from, and have you noticed any errors from generalizing the change in time to a specific value?

I've modified the code so that a datalog is created even without a GPS, as I don't want to use it and my vehicle will be indoors mostly. I'm just wondering if calculating the dt takes too much time, and how that impacts filtering the IMU data.

Thanks,
TC