Dear friends,
after hard work on firmware doing by Arducopter and Virtualrobotix Dev Team , we are happy to present the result of this incredible test ... this is only first test VRBrain vs DJI Wookong .
The firmware is ARducopter32 rev 3.0.3 , this revision of firmware use AP_HAL library to interface the Arducopter application . The firmware is mantain by Arducopter devteam , the last improvment doing by Leonard that solve some glitch in loiter , and gps override mode.
The result of work doing by Randy and the other member of the team is incredible , we fly the quad in gps mode and it fly as robot ... as Dji Wookong .
This is a video doing during VR Lab test of new VR Lifter frame.
But if you like fly in stabilize mode you can enjoy you a lot. :) I prefer a lot fly my quad in stabilize and acro mode it's nice.
The power of VRBrain with its STM32F4 microcontroller have 164 mhz of clock with internal dsp have a more power of DJI Wookong cpu that use SAM3X micro processor at only 96 mhz and don't have dsp processor for hardware math processing.
Now the new revision of VRBrain 4.5 can support also an external IMU so we can solve the vibration problem with mechanical patch.
Whe have a great new wiki page for support the user :
https://vrbrain.wordpress.com/
A new tools for update the firmware is available and will be release in the next days , so you can choose your code download local and program the board without problem.
We are very happy of VRBrain performances :)
original blog post : http://www.virtualrobotix.com/profiles/blogs/vrbrain-vs-dji-wookong-m-last-firmware-rev-3-0-3-available
p.s.
Thanks to Marco Robustini for his great video :)
Best
Roberto Navoni
Comments
Hey,
I finally got my hands on a VrBrain ..
it came with the new 3D Robotics gps and mag ...
the gps connection is fine ... but i am bit confused about connecting the mag ..
it comes with a molex 4 pin connector ?? how does it connect to the board ??
thanks in advance
GB
I would be interested in making the PX4 outputs work to drive LEDs and submitting a "patch", I did that work for APM 1 and 2. But I don't even know where to start. What "pin" are they attached to? I have asked this question on the dev email list but didn't get a reply. Figuring it out on my own, the hard way, is beyond my experience and skills. It was bad enough on the APM2 where each physical pin had 4 different number definitions (Atmel pin# Atmel Port#, Arduino Pins, and 3DR pins), but at least in that case I found a few outdated/incorrect documents to string together to form an educated guess.
All I need is the Pin# to use.
@Lorentz
i understand your point of view , i know that linux is not a RTOS , i know that VxWorks is O.S. used by curiosity and i know the cpu used by Curiosity RAD750: http://en.wikipedia.org/wiki/RAD750 .
I like a lot your work on px4 and nuttx but i think that there are some limits in our community about the complexity of o.s. and file systemand on vrbrain i prefer at the moment more simple approach.
In the past i evaluate to use ChibiOS on VRbrain i know Giovanni i spoke a lot with Giovanni about the opportunity to use its Os in our application , but the main problem that i had was that inside our community there wasn't a lot of guys that had skill to manage with me this kind of work.
So could be that in the future will be some guys that join to this kind of work but at the moment could be simple found develper that work on application , but not so simple found guys that can work on kernel and driver.
So Leonard i think that you are on right road , but is not simple road and you need a lot of resource for debug your system and found bugs in Hardware , Os kernel , in driver and application.
At the moment i only choose to work only on hardware bugs , driver and application :) This is yet a huge work start as hobby and became a works ... :) fiuuuuu :)
To obtain a affordable system is important that all the code is under your control , if you use a O.S. developed by other guys or it is yet affordable as VxWorks for example or you need to have a guys inside your team that know that O.S. and know where put his hands to solve the problem.
If you don't have that resource inside your team is better to don't use that O.S. In our application if we lose some milliseconds bceause the fat file system search next node ... we crash !!!
So i prefer to don't have that problem !!!
Best
Roberto
p.s.
i continue to follow you works on px4 and try to learn a lot on affordable RTOS ... but is not so simple ... have a lot of time free for learn a lot of new and interesting things ... i have 3 little kids ,too
I agree, PX4 is considered by users as "a powerful alternative or evolution of APM", so theoretically it should at least do all that APM does today, so I hope the dev team lines up all the hardware/software features that APM does with the V3 code.
VR Brain covers 100% all these features, only the lack of the bootloader is not perfectly aligned with APM.
Thanks for the "servos pinout", unfortunately they are not easy for those who do not have the solder easy... :-)
Hi Marco,
With the current hardware rev you can hook up four servo pins to the 15pos expansion connector on FMU. This is already available in the APM firmware, so you can control a gimbal. The servo positions are indicated in yellow here. Obviously the cabling is interesting this way, and this small limitation will be addressed sooner than you expect. As for the buzzer, you really need to talk to the APM dev team. The main PX4 stack is very actively using it for all sorts of events (commands, arming, low battery), and so its merely a question of hooking it up in software - the APM team would certainly be delighted to get a patch on this.
Hi Lorenz, thank you for answering, what do you think of the other points that I have expressed?
Yesterday I made further tests with the PX4 and is doing really well, but some things are still not clear myself, especially about the possibility of driving at least 3 outputs for the gimbal servos + shutter (in case of quadrirotor setup), one need also only have a "direct transfer" of the input CH6 and CH8, since many now use brushless gimbal and there is no need for PX4 stabilize the cam support with the built-in code.
Another important thing would be the ability to use the buzzer as with APM / VR Brain.
@Roberto: So essentially what you're saying is that because you didn't manage to make a board fly with plain Linux implies that operating systems are in general the wrong approach? Did it ever cross your mind that it might have been a very bad idea to base on a general-purpose operating system for realtime operation?
I think you're right that if debugging the system is too difficult for you then you shouldn't use an OS - that is however your personal conclusion, and you shouldn't try to generalize it, because others might not have the same issues your'e experiencing.
Last, the most important point: You can't throw all operating systems in one bag. It was very obviously a bad idea to try to run a normal Linux on a low-end MCU without hardware floating point support for flight control and expect low latency. The Linux scheduler has not been built for this purpose. Its even a bad idea to rely on the scheduler to give you exact timings, and you might be surprised to hear that even though we run an RTOS, sensors still run on the interrupt level on timers to make sure that we don't run into the kind of issues you were experiencing. That you apply the same conclusions on any RTOS (note: Linux is NOT a Real Time Operating System, and the RT extensions just get it closer, but not on the level of an RTOS designed for low latency) just shows that you haven't really understood the important differences.
NuttX is a POSIX RTOS, very much like the commercial VxWorks (you will find the API to be mostly the same). You might be delighted to see that VxWorks is running on the Curiosity, 787, SpaceX and VxWorks provides the primary computing e... That of course doesn't say anything about particular performance metrics - it just shows that in the professional world the debate has long been ended and the prevalent platform is something that is extremely close to the NuttX / PX4 platform.
This whole microSD story is yet another example of pure speculation, and just an obvious and cheap attempt to try to make up a problem. Thankfully the vast majority of developers is modest and does not try to raise their own work by trying to accuse others of things that are unproven and irrelevant.
@Robert: honestly I have not tried to remove the microSD from PX4FMU while the motors are armed, in theory should not crash, or at least that's what I hope... :P
I know about the two 500 mhA output but i think the code currently is not implemented for driving LEDs or buzzer in that pin.
Hi Robert,
we are discuss with Tridge for integrate our work in the trunk so the development will be more simple and less different respect to other platform.
About the enclosure we are improve it in the next revision of board , with external imu we would have a better sensor as option with temp drift compensation.
About the magnetometer is the same of px4 and apm no difference so don't have different drift. On VRBrain is possible to connect an external magnetometer on i2c bus 1 or i2c bus 2 . If you use bus 1 need to deactivate or request board without magnetometer on board . If you want to use i2c bus 2 less standard 7 and 8 pwm output ... but if you use ppmsum input you can use the other 6 pwm input as output.
So we don't have limit on our hardware for custom configuration .
Best
Roberto
-
1
-
2
-
3
of 3 Next