Resizing of VirtualBox + Linux LVM drives.

If You’ve created a VirtualBox Linux VM and ran out of disk space, there is still a quick and painless method of extending it without having to touch the files on the virtual drive. This will work however as long as You have LVM (Logical Volume Manager) drives, which are a default on most major Linux distributions.

1. Extending the VirtualBox VDI Image

First, find the path to Your VirtualBox image. Mine on Ubuntu was under: ~/.VirtualBox/Linux64/

Then run the vboxmanage command to resize the VirtualBox VDI image to the desired size. The size given after --resize is the size in MB, while the last parameter is the VDI filename.

Once that’s done, the new size should appear in Your VirtualBox interface.
Now let’s move on to the actual machine and make use of the newly extended drive.

2. Quick review of available drives and Volume Groups

To proceed, we need to read the Volume Group (VG) Name for our current root drive.

As we can see, the root partition is stored on /dev/sda2 (PV Name) in a Volume Group (VG Name) called vg_linux64. The partition is ext4 type. One more thing – the /dev/mapper paths are created as follows: <VolumeGroupName>-<LogicalVolumeName>. It means that according to the entry in /etc/fstab the root partition belongs to the vg_linux64 Volume Group, which is confirmed by the output of pvdisplay. The logical volume for the root partition is called lv_root. We will need this information later on.

2. Creating a new partition on the remote machine

Since we’ve expanded the size of the drive in VirtualBox, we now need to fill the empty physical space by creating a new partition on the drive.

I’ve created a new primary partition as I only had 2 of them on the drive. Since I don’t plan to add any others, 3 still give me 1 left to create later on if I really had to.
I’ve chosed to fully fill up the space of the disk drive, which meant using the defaults in fdisk.

Since the partition was created as a Linux one (Id = 83) we now need to change it to Linux LVM, because this partition will be a part of the Volume Group, which itself is a part of LVM. As we can see above, the Linux LVM id is 8e so we modify it accordingly.

The partition table is now correct. We need to write it to the disk and reboot the machine so that the kernel correctly sees the newly added partition.

3. Extending the Volume Group with the new partition (vg)

The VolumeGroup can span a few drives we have on our machine. This way though physically they’re separated, from a logical point of view, they’re just a continuous space as if they were a single volume. We need to extend the Volume Group on which our root partition resides to make use of the newly created drive.
To do that I use the vgextend command followed by the device name of the partition /dev/sda2, which I’ve created using fdisk.

4. Extending the Logical Volume

A single Volume Group can consist of multiple Logical Volumes. It’s like a cake. The lowest layer are the drives, which are held together in a Volume Group. The Volume Group may then be divided into various Logical Volumes, which act as separate drives, but may be elastically resized, removed, and changed.
This time I use a respectively named tool for logical volumes: lvextend. In the next parameters I provide the volume on which my root partition resides /dev/mapper/vg_linux64-lv_root and then the drive name /dev/sda3.

5. Resizing the existing filesystem

So far we’ve extended the VolumeGroup and LogicalGroup so both of them make use of the additional drive /dev/sda3 we’ve added. However, this change is not reflected by the filesystem as it wasn’t informed that there is more space it can use.

Luckily Linux allows us to extend an already mounted drive using resizefs. We parametrize this command with the /dev/mapper/vg_linux64-lv_root device name and voila !

And that’s it. Our drive’s size has risen from 50 GB to 56 GB as intended, by the addition of a new virtual drive in VirtualBox. Hope this tutorial helped You. If it did, please leave a comment below. Thanks !

WLToys v959 modding guide for non-original transmitter

If you own the WLToys v959 Quadcopter with the stock transmitter, you’ve probably enjoyed using the camera and LED light switches. I however decided to buy the BNF version and paired it with Turnigy 9x.

The upside of it is the range – I never lost contact with the quad and believe me, I’ve flown it really high ! The downside ? I can’t turn on video recording mid-air and/or the LEDs to have at least a bit of orientation when flying.

Well, guess what – there is a fix for that ! If you’re familiar with the soldering iron – let’s go !

Adding a led lights ON/OFF switch

What You’ll need:

  • A micro on/off switch
  • a few centimeters of thin wire

Start with removing the canopy, unplugging all of the cables and unscrewing the board. There are just 4 tiny philips screws in the corners of the board.

20140821_191011

My board is marked as JR-WL-V929R-1, REV:03. I’m pretty sure that other versions of the V929 board aren’t at all that different. Take a look at the back of the board, where I’ve marked the solder points for our switch.

20140821_191102

One of them is the battery ‘-‘ (ground) and the other – one of the points that has to be drawn to the ground to light up the LEDs.

Let’s test if it actually works. First connect one of the LED cables from the canopy to the “LED” marked socket on the board, then plug in the battery so that the board comes to life. Finally touch the two ends of the wire to both of the points. The LEDs should light up ! Unplug the battery and LED from the board.

It’s now time to solder our on/off switch. Decide where You would like to have it placed and measure roughly the length of the wire needed to install it. Then solder the wire to the switch – one wire to the central pin, one to the side. The side You choose will be the “ON” position. On the other You can tear off the pin using pliers so that it won’t come in the way. Solder the wires coming from the switch to the board. You should end up with something like that:

20140821_191826

Now it’s time to test it out. Connect the LED and then the battery to the board. Flick the switch and it should turn the LED on or off, depending on the starting position. There You go !

20140821_191953

There is still one last touch. To secure the switch in place use some hot glue and place it where You’ll be able to reach it after putting back the canopy. Remember that hot glue is non-conductive so You can secure the solder points as well. Just keep in mind that since we’ve been soldering quite close to the screw hole in the board, the extra glue might get in the way of the rubber cushions on the frame on which the board is placed. In my case it was an issue so I decided not to apply any.

If You have the cable lenghts right You can leave them hanging freely, but if You feel like it, secure them in one place using a bit of glue as well. You end up with something like this:

20140821_195944

If You don’t feel like adding an LED switch at all, that’s fine as well. You can have the lights switched on all the time (the battery drain from 4 tiny LEDs is insignificant really). If You decide to, just add a wire connecting the two soldering points and You’ll be done – that’s Your call.

Now let’s just put everything back together. Reconnecting the board is quite simple. First find the small arrow printed on top of the flight controller board – it’s near the antenna (first picture). The arrow shows the front of the quadcopter, so it should point in the direction of the two red propellers. The motors should be plugged to the “Ni” and “Shun” sockets. Since the engines’ cables are limited in length You can’t get it wrong. The LEDs go into the “LED” sockets. If You bought yourself the light bar set for V949 (which fits the v959 as well) then connect them to the “Light” sockets.

That’s it ! Success !

Adding a camera “start recording” tact switch

The camera may be switched on manually (like on Hubsan x4). It’s awfully easy to do so, since all You have to do is connect the yellow wire to the ground (black wire) for about a quarter of a second. All You need are 2 short pieces of thin wire and a tact switch. Let’s do it !

First unscrew the 4 tiny screws holding the case together. Then remove the elastic piece of tape on the back of the PCB. You should now see the hot glue on top of the soldering spots, where all the wires from the camera meet. The glue will melt under the tip of the soldering iron, so don’t mind it too much. Solder two wires to where the black and yellow cables are placed.

20140821_192713

20140821_192653

Now solder the tact switch to the end of Your two newly added wires. Done ? Secure the soldering points with hot glue, but add just a little bit to be able to close the plastic case.

20140821_194033

If You chose a thin piece of wire, You should be able to push all of the cables through the original opening through which they went. Put the case back together and place the switch where You want. Apply some hot glue to hold it in place. Voila !

20140821_200008

How to catch and process Linux core dumps in Your own application

Since kernel 2.6.19 Linux supports piping core dumps to a certain application instead of just writing them to a file. What happens when a core is to be dropped depends on the setting in /proc/sys/kernel/core_pattern. If a path is preceded with a | (pipe) and then a path to an application, then in case of a crash it gets run and output (stdout) from the kernel is redirected to it. Otherwise the core is dumped to a file directly and the entry in core_pattern treated as a path (either absolute – starts with ‘/’ or relative).

Applications such as apport (Ubuntu) or abrt-ccpp (RedHat) choose the first option of getting the data through a pipe from the kernel.
Let’s see some examples:
user@host:~$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %P

This entry tells the kernel that the /usr/share/apport/apport application wants to get the output through STDIN from the kernel, with some parameters (argv): process PID, signal which caused coredump, core file size soft resource limit, process PID (initial PID namespace). The meaning of all of the options is described here: http://man7.org/linux/man-pages/man5/core.5.html

A different example would be:
user@host:~$ cat /proc/sys/kernel/core_pattern
/tmp/core.%p.%e

This time the coredump would be written directly to a file in /tmp/ called core.&lt;pid&gt;.&lt;executable_filename&gt;.

Writing Your own application for intercepting coredumps is useful for:
– reading data about a process such as memory maps: /proc/pid/maps before the crash occurs and the kernel removes the /proc entries.
– Having Your own notification of crashes occuring in a certain application (that’s what apport in Ubuntu is for)

A simple piece of code for just getting the core dump data from the kernel, writing it to a certain location and finally logging it to a file may look like that:

C

The code is compiled without any special libraries:
gcc coredumper.c -o coredumper

Perl

Testing our app

The first thing we have to do is to convince Linux to use our application instead of the default one:
user@host:~/source/coredumper$ gcc coredumper.c -o coredumper
user@host:~/source/coredumper$ sudo su -
[sudo] password for user:
root@host:~# echo "|/home/user/source/coredumper/coredumper %p %e %s" > /proc/sys/kernel/core_pattern
root@toshivax:~# cat /proc/sys/kernel/core_pattern
|/home/user/source/coredumper/coredumper %p %e %s

This way we’ve registered our application in the kernel. Whenever there is a crash, our program will be called to collect the dump file. Let’s test it !
Let’s go into the terminal and try the following:
vax@toshivax:~/source/coredumper$ kill -SIGSEGV $$

Ok, so we’ve killed our own bash console with signal 11 (Segmentation Fault). If we’re lucky, our application worked and collected the dump file. Let’s see:
user@host:~$ cd /tmp/
user@host:/tmp$ ls
cdump.bash.16813 coredumper.log
user@host:/tmp$ tail coredumper.log
CoreDumper application started...
Caught 'bash', pid '21107' process crash with signal: '11'
Writing core file...
Dump file collected successfully.
user@host:/tmp$ gdb --core cdump.bash.21107
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 21107]
Core was generated by `bash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fef0f4f0277 in ?? ()
(gdb) bt
#0 0x00007fef0f4f0277 in ?? ()
#1 0x000000000043789b in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb)

Ok, so the application dumped the core file correctly and we can read it.

Note:
Sometimes core dumps are not written at all by the kernel. The most probable reason is the core file size limitation set by ulimit.

Try doing:
ulimit -c unlimited
to see if the core dump will now be generated. This by the way sets the core file size limit to ‘unlimited’. Unless You want to keep it this way, it’s wise to have any limit, since a coredump may eat a lot of Your disk space.

Where to go from here ?

We’ve got a basic application, which doesn’t do much better than the regular kernel mechanism for collecting core dumps. Nevertheless we can easily extend it to read and analyze the stacktrace automatically using various gdb options or using a C library such as libunwind. We can also add various forms of reporting the coredumps after extracting necessary information like apport in Ubuntu does.

GX Buggy repair guide.

I was looking over the Internet for a guide on how to fix, replace some of the parts of the GX Buggy, but wasn’t very successful, so I decided to share what I’ve learned and give You a full guide on how to dismount / fix this little RC Car.

Should I fix it at all ?

You might be wondering why I’m asking this question in the very beginning. It’s simple – replacing any of the parts (motor/battery) costs roughly 1/3 of a new RC car. I fix them for fun, there is no economic reasoning behind it.

Removing the outer cover

You first have to start with the 4 little screws of the top cover of the vehicle:
gx_buggy_canopy

Take off the cover. The electronic board shows up. It’s held by one screw in the corner – remove it as well. This way You’ll be able to take out the board, the battery, and the front motor, which is responsible for turning the front wheels. You should get to this point:

gx_buggy_canopy_off

The 150 mAh battery

The original battery in the GX Buggy is only 60mAh, which gives you just a few minutes of fun. It also loses its original capacity quite quickly and before you know it you need to replace it. The good news is it’s quite simple, and what’s more – it’s possible to place a 150 mAh battery in the same compartment. As the picture shows, I already have the 150 mAh battery installed:

gx_buggy_battery

To replace it, just desolder the old battery (You can see the solder points on the second picture). Be careful not to short circuit the + and – wires on the battery. Also check polarity before soldering on the new battery. Better safe than sorry.
Since this is relevant, I’m giving You the rough size of my 150 mAh battery:

Battery type: li-po 1S
Voltage: 3.7v
Length: 16.7 mm
Width: 6.8 mm

If You ask whether a li-po instead of the original (supposedly li-ion) would work the answer is: definetely Yes ! The original charger handles the battery very well, but of course the charging time is longer.

As a side note I have to add that using the 60 mAh battery might have been a very conscious choice of the producer to avoid overheating of the toy by running too long. I’ve already replaced both my motors, but this might also be the case of their poor quality. That’s your call to judge it.

gx_buggy_board_back
It’s slightly bigger than the original one, but with a bit of force and messing around with the cables it will actually fit inside.

Steering system

gx_buggy_steering

As shown previously, the steering system is based on a small electric motor, which turns the central crown wheel until it’s blocked. This solution is simple and effective, but since the motor is blocked when the wheels are turned in any direction, it draws quite a lot of current as well as it gets hot. Mine already gave up and I had to replace it so be prepared for that. Since these motors are non standard, I’ve measured the size of it so you can try to find it in some rc store. I’ve also provided measurements of the sprocket. Hopefully it won’t need replacing and even if, it’s just pushed onto the shaft, so just pull to remove it.

Front rc motor:
Voltage: 3.7v
Motor length: 12 mm
Length with shaft: 15.7 mm
Motor diameter: 6 mm
Shaft diameter: 0.7 mm
Sprocket length: 3.9 mm
Sprocket diameter: 3.4 mm
Sprocket teeth: 6

If you’ve replaced the engine it’s simple to check if you got the polarity right. Switch on the car, pair it with your controller and the grab the sprocket (first put it on the shaft of course) on the engine with your right hand. Turn right on the controller, the sprocket should try to spin clockwise. On a left turn, it will spin counterclockwise. Don’t hesitate to hold the sprocket so tightly that the engine won’t turn – it won’t cause any damage, because that’s basically how the turning in these cheap cars work.

Next you can proceed to take the whole front side of the car. Do really think if it’s needed. Honestly speaking if there is nothing wrong with the car’s turning don’t take apart the front part at all. It’s very hard to put together and chances that anything could be fixed are quite low. Nevertheless, I’ve presented a picture of the mechanism pulled apart just for reference:

gx_buggy_front_wheels

There is a spring on the top plastic tip – it makes the wheels return to the center position. The arms of it go around the mechanism for trimming the turn (not sure how it was supposed to work) and finally rest on the third tip. The rectangular black part, which lies on the crown wheel, has teeth underneath. When the motor spins in either direction it turns the crown wheel, which in turn moves the tip on the rectangular part. The car’s wheels get turned through the plastic thin arms that you can see attached to them. Mounting them back requires a bit skill, but is feasible. First put the spring as in the picture, rest its arms on the third tip, then mount the wheel’s arms over it and finally place the top cover.
Often the spring won’t stay in place or one of the arms pops off. Holding it in place isn’t just that simple. But on the other hand, there’s just no easy way here. I warned you before !

Gearbox and rear motor

To take the gearbox apart and get access to the motor, first remove the two side screws on the bottom. You can leave the center one on, because it holds the rear spoiler.

gx_buggy_rear_wheels

Next, remove the bottom cover and You’ll see the rear wheel shaft with a gear and rubber washers on both sides and the motor as well.

gx_buggy_rear_wheels_motor

The rear motor can now be gently pulled out. Since it’s soldered to the electronics board, if it’s faulty, desolder both of the cables first. You can then pull both of the cables gently from the rear chassis. I’ve measured the engine’s size for reference if you’re looking for a spare one:

Rear rc motor:
Voltage: 3.7v
Motor length: 16.5 mm
Length with shaft: 21.8 mm
Motor diameter: 7 mm
Shaft diameter: 0.7 mm
Sprocket length: 3.8 mm
Sprocket diameter: 3.9 mm
Sprocket teeth: 8

When pushing the motor back into the gearbox, mind the gears and the sprocket. If it doesn’t go in, turn the sprocket so that the teeth of both gears are lined.

The gearbox itself consists of 3 different gears. If you need to dismount it for any reason remove the two screws on the side:

gx_buggy_gearbox_cover

The gearbox taken apart looks as follows:

gx_buggy_gearbox

And that’s it. The gx buggy is now in pieces 😉

Putting it back together

Whatever you’ve modified in the buggy, putting it back should be simple if you follow the steps performed in a backward order. One thing I’ve come across is that if You’ve changed the battery to a bigger one, it leaves less space for the electronics board and the top cover is hard to put back. If you align the small hole in the corner of the board with the plastic tip and then put the screw holding the board back it should be all held in place.
When putting back the top cover look out for the antenna, because it tends to stay on top of the “pair” button and it will constantly push on it, when you put everything together. Move the antenna a bit to the side or put it through the little hole in the top cover. When applying back the screws check the “pair” button if it still “clicks” after each screw. Also take a look if the ‘on/off’ button is properly aligned.

How to look for gx buggy parts on the Internet ?

If you’re still wondering why I’ve provided the sizes of both the batteries and the motors is because there is little chance that you’ll come across ‘gx buggy spare parts’. My experience shows that it’s not available under these search queries.
Instead search for:
– ‘lipo battery 3.7v 150 mAh’. The 3.7v lipos are also called ‘1S’. This might help.
– ‘motor 3.7v ‘ – just look at the pictures and use my tables as reference. If they’re the right size it’ll do. I bought some motors originally for rc helicopters, with a longer shaft, but you can easily cut it to get the right size, so only mind the length and the diameter of the engine.