Quantracker Air OSD APM first successful build
Work in progress on the APM Arduplane Source code for Quantracker OSD.
github/kwikius/ardupilot/quantracker_master
Soldered up the rest of the connectors/sensors today and tested the baro
On board
Camera Input
Vtx output with vector graphics OSD
MPU6000 IMU for calculating which way up it is on dedicated SPI bus
MS5611 Barometer for calculating altitude on I2C bus
HMC5883 Compass on I2C bus
MPXv7002 Airspeed sensor analog input
generic 5v GPS
3 indicator LEDs
PPMSUM Receiver input
4 x servo outputs ( with up to 400 Hz refresh so hopefully useful for Quads)
Battery Voltage measurement analog input
Battery Current measurement analog input
RSSI measurement analog input
Video telemetry out
Audio (FSK) Telemetry out
Serial port telemetry out ( FrSky/OpenLRS telemetry out)
Logging will be via another serial port and using OpenLog
Console Uart
All the essential drivers are now completed.
Update 12th Sept 2015 Connected the MPU6000 IMU
SPI mpu6000 who am I test
Update 08 Sept 2015 connected servos
Update: 07 Sept 2015 connected the RC receiver:
RCInput Test code
Meanwhile... also constructing an airframe for the test board...
regards
Andy
To reply to a question, please Login or registered
34 replies
andy
Favor from: lexus08
2nd test flight of the Air OSD. This time testing RTL and FBWA modes:
https://www.youtube.com/watch?v=KQLArFbRjWg
Currently working on getting logging working
regards
Andy
Tom - PlayUAV
Favor from:
Great work, Andy. I am also learning the ardupilot code. I have a revomini board (https://github.com/TauLabs/Tau ... vomini). As a study project, I want to try running the Ardupilot copter code on the revomini board. If you also need such a board for test purpose, I'd be very glad to help.
andy
Favor from:
Tom,
Porting APM to revo mini sounds like a great idea because:
1) The original avr APM is too slow for a copter with latest firmware,which is confirmed by the Ardupilot developers.
http://copter.ardupilot.com/wi ... s_px4
2) The Pixhawk/PX4 is physically too large really for a 250 copter
The minirevo looks like a nice solution!
Some googling turns up an existing port of APM for Arducopter for revomini. Its a bit out of date but reported to fly well.
https://github.com/scenkov/ardurevo
I would love to have a minirevo board, however I would probably not get anywhere with my other projects if I had one, so I had better decline for now until I get more work done on my other projects!
On the other hand....
Are you producing them? If so how much :) ?
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy, I agree with you. Actually, we are playing the revomini on a 250 frame. The firmware is based on TauLabs and performs great. The reason I want to port APM to revomini is that I think it is a good practice for learning APM code.
Yes, we have produced some revomini boards. But we don't plan to sell them because it may violate the OP license which seems to forbid commercial use of its products. Nevertheless, it would be fine for individual playing, research and developing.
FYI, the AirOSD v2.2 are under production. I can send you a revomini board together with the AirOSD boards. You can lock the revomini up until you finish your work on hand.LOL
Best,
Tom
andy
Favor from:
I would love to have a revomini board. It will be good to compare its performance against the performance of the AirOSD board with the OSD running .
I have been looking at the best way to combine the Ardupilot code with the AirOSD code to have the OSD running in the Ardupilot code. I have decided initially to just put the APM scheduler in the OSD drawing task. The Ardupilot scheduler code gets called in the task before the OSD drawing code. (The drawing function could probably be added as the last task in the Ardupilot scheduler) Ideally then all the flight variables will be updated in the same frame before the real on_draw function is called so giving a very small latency and a good response on the display. The only issue is if the code doesn't complete in one video frame, but I hope that for simple drawing this option will work.
regards
Andy
Tom - PlayUAV
Favor from:
Yes, it is not necessary to draw every frame. We can divide it into several frequencies to get better performance and response. I have made a hack adding minimosd code to ardupilot. It may not be a good solution, but so far it performs well :-)
https://github.com/PlayUAV/ard ... av.md
andy
Favor from:
Hi Tom,
That is very clever. That is a novel and useful OSD. I had seen it for sale but didnt understand its purpose. I have re read the Atmega2560 datasheet and see it has 5 SPI ports, which I hadnt noticed before, so I assume you are using one of those which is multiplexed on the APM pins
I had a look at the source code. In it I think I am correct to say you are using an update rate of 5 updates per second? Unfortunately for some reason I can't get the video linked from the pdf datasheet to load. I just get a wait cursor so I can't review the OSD in action.
Did you try higher update rates than 1/5th second?
It is a nice hack for sure!
regards
Andy
Tom - PlayUAV
Favor from:
Yes, Andy, APM Plus uses SPI and MAX7456 communication to implement OSD. I have tried higher update rate like 10HZ and the FC seemed to work normally. But without solid data analysis, this is more like my personal judgement. To avoid potential overburden on SPI, I think it's safer to choose 5HZ because after all OSD doesn't have to be highly real-time.
Regards,
Tom
andy
Favor from:
Though I should provide an update on how I am getting on with porting Ardupilot to my Quantracker Air OSD dev board.
This is also probably of interest to anyone who wants to port Ardupilot to an stm32f4 bare metal board with FreeRTOS, though the fun part is the onboard OSD.
The source here explains it pretty well. Its not an FC yet just some test apps
I'm running the OSD and the APM in 2 separate FreeRTOS tasks. The fun will be trying to read the variables to the OSD but I may use a message queue for that, so each variable will be put on the queue as its updated rather than read direct but that is a bit down the road.
As the APM code has been ported already to various multitasking operating systems, it makes it a bit easier to separate into tasks and today I managed to add another FreeRTOS task. This is started by the scheduler and just calls an array of functions once very millisecond. The scheduler timer task can be seen in the Quan implementation of the scheduler Has been tested and is working ok with the OSD running on the board as well..
A long way to go but definitely not impossible
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Congratulations! It is amazing that you have made such a big progress within a few days. Indeed there is still a lot to be done, but you have made a good start. Now we know it is not a mission impossible, we should just go for it：） The development board should be completed next week. Hope more developers can join us.
Cheers,
Tom
andy
Favor from:
Hi Tom,
Very much Looking forward to the AirOSD boards being made and happy to welcome any devs who want to get involved :)
I am now very confident that the APM will work on the Quantracker AirOSD Board
I will try to prepare a schematic of the system, but in brief.
First some restrictions...
The number of pins on the dev board is quite limited, so you are limited to a PPMSUM rc input ( all the channels multiplexed on one wire. This is available on many Receivers , e.g FRSKy D4RII and OpenLRS to name 2) or you will have to use an external multiplexer)
You are limited to 4 rc output channels initially, but pulse update rates up to 400 Hz are supported. Alternatively 2 x external demultiplexer will provide up to 16 channels at a 50 Hz RC output update rate.
(These restrictions are simply due to the 64 pin part used. )
Here are the specs currently planned for the FC on the AirOSD dev board
4 x servo output @ 400 Hz or 16 channels @ 50 Hz with 2 x 8 way external demuxers
3 x UART ( e.g GPS/ Console/ Telemetry) + 1 Uart Tx only
16 K EEPROM simulated in Flash
1 PPMSUM RC input ( Individual RC inputs not supported)
4 x ADC ( for Battery Voltage/ Battery Current/ RSSI/ Airspeed sensor)
3 x LED (same as APM2.x ?)
1 x I2C channel for use with Magnetometer (e.g HMC5883) and Baro (e.g MSP5611/ BMP085)
1 x SPI channel for use with IMU ( eg MPU6000 / MPU9250 )
I hope that covers everything required to for a basic but fully functioning APM flight controller using the AirOSD board.. unless I have missed something?
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Where will the flight logs be stored? I know that Pixhawk FMUv2 stores the logs in SD card. Have no idea how APM2.x handles this.
Regards,
Tom
andy
Favor from:
The APM.2 has I believe a separate EEPROM IC . I have not provided a way to store data onboard the FC, though there is an auxiliary txonly UART which could be used to stream the data.It would then be necessary to hook the stream up to some external storage media.
The other option is to use one or more of the telemetry links to send to a groundstation directly There is a Telemetry uart ( e.g 433 Mhz modem), as well as the video telemetry link ( around 56K baud) and data can also be sent down an audio channel (1200 baud)
I am aware I havent started on the PlayUAV OSD tx telemetry yet. I havent forgotten it :)
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
It sounds great to store the flight data though the telemetry link. It can not only ease the burden of FC, in case of crash or FC missing it can also help us to find the reason by analyzing the flight log.
As to video telemetry of PlayuavOSD, though it is much expected, please just take your time and deal with other priorities:)
Regards,
Tom
andy
Favor from:
Hi Tom,
I will make sure to get data logging working via the telemetry on the Air OSD board
Looking at the STM32F4 datasheet, I see there is a dedicated SDIO interface which can be set up to use only 3 pins at 25 MHz clock. though not available on the current board I will certainly try to incorporate it on the next revision of the board as an option as well.
I will try to get some work done on the PlayUAV OSD too this week !
regards
Andy
andy
Favor from:
Looking into the issue of data logging I have found that there is a project that does logging to an SD card via the serial port. https://github.com/sparkfun/OpenLog, Since there are 3 serial ports available , that is the solution I plan to use on the V2.2 Air OSD board for onboard logging. It should be usable in parallel with telemetry
Finished some more drivers for the Ardupilot port to the AIROSD board. Currently about to test I2CDriver code , then only SPIDriver , RCInput, RCOutput to do.
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Great news about the serial port logging. I have tried reading quan-trunk code, but as my knowledge of C++ is quite limited, the codes just seem strange to me. I also read your article at your website, yet still don't get it. http://www.zoomworks.org/quan- ... .html
I think maybe it is time for me to carefully and deeply read a book about C++. Have you any advice to help a person unfamiliar with C++ to be able to use quan-trunk masterly？
Regards，
Tom
andy
Favor from:
Hi Tom,
My use of C++ is problematic since it makes the code difficult to understand, however I have been programming in C++ since 1990 or so and it is hard to change now. It will always be a problem, however, since the trickier code is mostly buried in librraries I hope it is less of a problem, though it does appear in error messages unfortunately. In an ideal world I would go back and rewrite things in a more standard way !
The 2 books on C++ I have found most useful are "The C++ Programming Language" by Bjarne Stroustrup, the original author of C++, and for more advanced things, "C++ Templates: The Complete Guide" by Daveed Vandevoorde and Nicolai Josuttis.
The idea behind the library documentation is based on C++ Concepts , which was going to be the next Big Thing in C++ a few years ago but since has faded away. (In Brief Concepts is about "the type of types") I prefer to call the idea Archetypes when applied to a family types that have common parts.
Anyway. I2C tested and working :)
Tomorrow I have scheduled to put away AirOSD and do some work on PlayUAV OSD
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Thanks for your advice. I read "The C++ Programming Language" several years ago, but didn't go deep and only got some superficial idea of C++ . This time with an aim in mind, hope the reading will be more effective:-)
BTW, Andy, it would be better that we can update your progress with "AirOSD APM" in the top article so that new readers can catch up without reading all the following replies. What do you think?
Best regards,
Tom
Tom - PlayUAV
Favor from:
Hi Andy,
Thanks for your advice. I read "The C++ Programming Language" several years ago, but didn't go deep and only got some superficial idea of C++. I should have learned it earlier. This time with an aim in mind, hope the reading will be more effective:)
BTW, I think it would be better to update the progress with "AirOSD APM" in the top article so that new readers can catch up without reading all the following replies. What do you think?
Best regards,
Tom
andy
Favor from:
Hi Tom,
I have just noticed that I can edit my Posts so I will do as you say.
regards
Andy
lexus08 - master of uavs
Favor from:
Hi. I research implimentation of some sensors for uav. e.g. obstacle detectino cameras. Due to the growth in air traffic and a significant increase of the unmanned aerial vehicles number, it is appeared a problem of dangerous encounters UAVs and its collisions in the midair. The article provides a definition of the requirements for the Collision Avoidance System on the basis of UAVs types, its performance and the maneuver speed. The system allows to the detect of obstacles in the path of the aerial vehicle and to choice the maneuver for collision avoidance.
Tom - PlayUAV
Favor from:
AUAV-X2's sensor board. Just for reference:-)
andy
Favor from:
That is quite small! What are the sensors on it? I cant really find any documentation about it
regards
Andy
Tom - PlayUAV
Favor from:
The board contains MPU6K, alternative compass sensor LSM303D and L3GD20H.
Home site:
http://www.auav.co/product-p/auavx2.htm
You can find the schematic files(Altium Designer) at the bottom of the page.
Regards,
Tom
andy
Favor from:
Latest progress on porting Ardupilot to the AirOSD board.
Here is a video of the sensors working via the OSD:
https://www.youtube.com/watch?v=a5Qq_5Q6v9k
Also now have a SPI FRAM installed . Hope that it wont be too long now before I can try a test flight!
regards
Andy
Tom - PlayUAV
Favor from:
Awesome！ Great to have a board that can run AP with OSD. Can it run AP_Copter firmware?
andy
Favor from:
Hi Tom,
Thanks for the enthusiasm :)
I am targeting ArduPlane at the moment, but I will certainly hope to get Copter running eventually. Only problem with that is that I have never flown a Copter so it may be a steep learning curve !
regards
Andy
andy
Favor from:
Very nearly ready for the maiden flight.
Here is a video of the OSD running my fork of ArduPlane. (I hope eventually to use the PlayUAV display. This is just the old OSD code put on to get up and running quickly)
https://www.youtube.com/watch?v=A6lSktmKMyI
If anyone wants to get involved in the project then do PM me !
regards
Andy
andy
Favor from:
Maiden flight :)
https://www.youtube.com/watch?v=pU-V8o-kjuI
Much to do yet but it is good to have got that out of the way
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Congratulation!
The sensors board are under sample making. It will be available in a few days. I put a pull request adding the layout of the sensor board on github for developer reference and reviewing.
Regards,
Tom
andy
Favor from:
Hi Tom,
Really looking forward to seeing the sensor board :)
regards
Andy
Tom - PlayUAV
Favor from:
Hi Andy,
Currently, the INS, Baro, Compass and EEPROM worked fine. Mr.Mawill continue the testing. Hope everything goes well:-)
Regards,
Tom
andy
Favor from:
Hi Tom,
Latest commit on quantracker_master (b18904a) fixes problems with APM planner / GCS . Should now be able to connect and run without issues. The problem was actually in the DataFlash_Empty class which caused strange behaviour. This appears to have been fixed upstream by removing it :)
I have been working on Logging and think I have now got a workable system which will log up to 28k,bytes per second, though it is not yet complete. Until that is completed and with the connection to GCS working, it is possible meanwhile to use the MAVLINK telemetry data for logging in the GCS.
I plan to work on the video telemetry now as top priority, since until that is done I cannot fly at any range!
Also it should be possible to provide SBUS servo output from the Sensor board as well, so even though there are only 4 PWM servo outputs, that should allow for up to 16 servo output channels. This will also cater for SBUS input from a receiver. It needs to be written yet though!
Anyway, I am now getting more and more confident with the system and looking forward to getting the sensor boards to test!
regards
Andy