There it is. If there is a Kickstarter campaign, that's going to be the product. Flying with the phone is not as easy as the sticks, but it's cheap. Bluetooth initialization is still a buster. Flight time on a 450mAh, 7.4V battery is 9 minutes.
Interestingly, robugtix.com sells a controller made of a bare circuit board & Xbee.
To get that level of customization, they have to charge a bit more than the price of a standard toy controller.
So making a 2 stick controller on a touch screen requires detecting 2 simultaneous touch points. The challenge with a stick controller is keeping a touch point corresponding to a stick applied to that stick, no matter where the touch point moves. If the touch point corresponding to the cyclic was applied to the throttle when it moved to the left side of the screen, it would be disastrous.
Basically, the Goog has tried at least 3 methods for handling multitouch in the Android API. There were ACTION_DOWN, ACTION_POINTER_2_DOWN, ACTION_POINTER_3_DOWN ... macros. Then they tried some really painful ACTION_POINTER_INDEX_SHIFT, ACTION_POINTER_ID_MASK macros which Eclipse says are now depreciated. There's no evidence of what the current, accepted way of doing it is.
The problem is the only way of knowing the current state of the touch screen is to trap a serial stream of MotionEvent events, then construct a table of all the touch spots on your own. There's no way to poll the touch screen or get the current state of the screen with a bunch of gets.
So you get a serial stream of MotionEvent events. The MotionEvent contains an x,y coordinate for every touch point, but there is only 1 action variable describing whether a single touch point in that list was pressed or released. For every press or release of a touch point, a new MotionEvent has to be received with the x,y coordinates for all the points & an action applying to 1 point.
Discovered selections of the soundtrack, but not all of it, were recorded in stereo. 1 stereo segment was the intro. In the 1995 CD, they combined stereo segments with mono segments in the same track to create the illusion that the entire track was stereo.
Unfortunately, there's no way to get the sound effects from the original intro. There are other goo tube videos with crappy sound effects & lousy clips where kids tried to enhance the intro.
Not as easy as a Blade MCX, but not as hard as a T-Rex 450. Quite a bit of power & control effectiveness. You can almost see a sport evolving out of it, with some pilots becoming very skilled. With virtually no wing loading, it wouldn't be very fun outside.
This arrangement of boards had just enough space to fit the cover on. There's no easy place for a Lipo battery. Flying it with sticks revealed the latest monocopter design to be extremely buoyant. Horizontal oscillation abounds, with the extremely low head speed, but seems to be controllable with active damping. The head speed is so low, there's plenty of horizontal authority.
Flying with the compass in the controller was not as easy as thought. Your mind expects the azimuth to be relative to your eyes, not relative to the controller.
After much battling with 2 PICs, 2 boards, & the SDCC toolchain, the 8 bit PICs with SDCC clearly don't have the horsepower to do any significant math. They can't do the tilt compensation for a compass. It may be a compiler limitation or a stack limitation. Fixed point, 4x4 matrix calculations on the PIC quickly resulted in random results.
The BANKSEL optimization in SDCC absolutely doesn't work, once you get over 256 bytes of RAM. Using the __naked keyword anywhere but the simplest program doesn't work.
The return address stack is only 31 levels, which might be exhausted in a complicated math function. So the idea was to use an el cheapo PIC to make a standalone stick controller with heading detection that would allow the azimuth on a monocopter to always point nose out.
Having a standalone stick controller is a drastically different experience than a touch screen or a stick controller tethered to a computer & a test article would be valuable in comparing the experiences.
Of course, the reason for the PIC was manely because it didn't seem a big enough problem to justify any more horsepower & it seemed mass producible. In reality, it absolutely is not cost effective to mass produce a stick controller in lieu of a phone interface & it doesn't have the publicity of a phone interface.
It can minimize the aircraft weight by using chip radios, but at the very least, the aircraft weight can be minimized with a bluetooth chip...Continue Reading
The home made USB PIC programmer has been around for around 6 years. After all those PICs & all that time waiting for its extremely slow data rate of 600 bits/sec, it finally had a debugging session with an oscilloscope that exposed the problem. A single bit error & now it's up to 166kbits/sec. It's still very slow, but bearable.
166khz is almost as fast as an agnostic bit banging protocol over USB can go. Past strategies used a bootloader to speed it up, but it needed a lot of extra resistors & tended to erase the PIC on its own.
The official Pickit programmer was once $30. Now, it's $45. Any future paid project would definitely involve buying the official programmers instead of making them from scratch.
a high speed, FPGA driven camera for flying Marcy 1
The monocopter remanes an interesting way to fly with the least amount of material. The ground based camera isn't very practical outside of a demo, since it can only hover in a single place. The FPGA version still requires highly controlled lighting. Hovering in a lit room is still more useful than hovering in a dark room.
A manually flown monocopter with a basic 3 channel stick controller may be extremely old fashioned, but the aerodynamics have gotten to the point where it could be a very exciting toy. Don't think any tablet interface is going to provide the same experience as old fashioned joysticks, although tablets provide a different experience.
If the user wants it to fly itself, it could be a rare enough occurrence to get by with a basic webcam that only works in the dark.
a balancing robot
It would be focused on autonomous mapping, using IR sensors or sonar. Another idea is using an articulated camera system to automatically make a 3D world. Making a 3D world like street view or a map is just more easily done with a human carrying around the sensor than with a robot. So maybe the focus could be on a map making sensor itself.
A balancing robot would make more sense if there was a day job coming that involved the ATmega328. Trade shows were not a viable way to fund startups, in the old days. We used to leave Las Vegas trade shows with 200 very promising leads, but they were more interested in...Continue Reading
There's a guy who makes you feel small. He's done a lot more in the same time you've been alive than you ever did. His formal education only went up to a BS in CS, yet he did everything from teaching a class at Stanford to starting a company, writing a book, & managing engineers.
Some items of note were he never mentioned working on something that wasn't in a formal environment, collaborating with other people who saw what he was doing. Where the rest of us might have hacked on a problem that no-one else was, alone in our bedrooms in college, he mentioned working with a bunch of other research students in the same room, on a fairly established problem.
Then, in professional life, he mentioned working on a small project outside of his day job, but it was with someone else & it was still related to his day job. He never did anything that wasn't a collaboration.
His book was a collaboration. Instead of lazily writing a wiki like most of us would, his 1st move was to approach O'Reilly to see if they would publish it formally. It's definitely a different way of thinking to make sure everything you do is done in a formal environment or part of a job, but it's probably reality if you want to make money.
He never mentioned any hardships with anything he did. The opportunities & money just effortlessly came. He mentioned working on obscure technologies as making resumes stand out, because it showed when...Continue Reading
There are finally enough parts in the apartment to make a very small but decent balancing robot. If kickstarter existed 10 years ago, there would be a lot of balancing robot schemes instead of 3D printer schemes.
It's long been a desire to build one, but it never had a purpose. At most, it could do some kind of indoor mapping. 1 of the more functional balancing robots used an object tracking algorithm to navigate a course.
It was a bit faster than the object tracking rovers I built because it used a raspberry pi for the machine vision & had a fully articulated camera. Trying to do that with a fixed camera, an STM32 capturing 6fps & offloading the object recognition over a wifi network was really slow.
Interestingly, he derived exactly the same algorithm for recognizing the objects that I used a year earlier. The key in both cases was to surround the object with a rectangle & use the rectangle to correct the perspective. Then, both of us calculated the difference between the object & a database of objects.
He later did some fudging to the blob detection. He appeared to shrink, then grow the blobs to eliminate noise.
At this point, detecting signs is pretty germane. Indoor mapping would be the next big thing. Telepresence using a video feed has never been practical because radio range has never been good enough.
1 fascination with balancing robots is that they can make money if a suitable application can be found. A conventional 4 wheeled robot is never going to make money. There is a market for a 4 wheeled chassis as an educational kit, but not a finished robot. Remote controlled cars are selling for $17 & change, these days, while Sparkfun is able to command $99 for a robot kit intended for education.
The early days of air travel, the vehicles & the crashes are an interesting read. It was as dangerous as it looked. There are no detailed descriptions of the accidents but engine failures seemed to abound. There were lots of water landings when engines failed. Water landings were usually fatal.
Gizmodo only covered Imperial Airways, which was real primitive. Your ride as an Imperial Airways passenger, on the very 1st flights in 1924 would have been this:
The De Havilland DH34. Early adopting was really early adopting in those days. The pilot sat outside. 1 engine was all you would ever need. The entire airline fleet amounted to 6 planes. If you were unlucky enough to be flying on Dec 24, 1924, you wouldn't have made it presumably because the 1 engine died shortly after takeoff, but there were no flight data recorders in those days.
In 1926, your ride was upgraded to the new & improved
Handley Page W.8. Those were real radiators with real antifreeze, exhaust manifolds, & oil pans hanging off the struts. At least it was easy to see if an oil line was broken, which they often were. It was quite large for a biplane. The pilot sat outside, behind the nose, all the better to reinforce if they were heading towards the ground.
In the old days, there was a novelty to someone picking up electronics on his own. It showed the ability to learn without being told what to do & the ability to be motivated without the threat of failing a class. While there were always places like Lockheed & 3D Robotics which would never touch someone without a formal engineering degree, it was not uncommon to get in elsewhere with a biology degree & a lot of design experience.
Nowadays, with the maker movement & the rise of the goo tube hacker, that doesn't seem to work anymore. It may be that they're now getting inundated with self taught engineers to the point that they need another factor to determine who wins. If the only factor was who could do the job for the least money, the lack of the degree should still allow a cost savings.
The modern self taught engineers may not be as skilled as the ones from 15 years ago, giving the whole idea a bad image. Most projects by self taught engineers certainly aren't as substantial as the old days. They tend to be copies of a wifi cantenna they got from goo tube, a real simple arduino robot, or a copy of a simple Ben Heck project. Because the crutch is there when it didn't exist 15 years ago, they automatically assume any self started project is a copy of a goo tube video.
It actually has a way to directly connect a UART to the modulation. The problem is it can't do GFSK in that mode. It also needs a trigger to enter transmit mode. It would be quite involved. The preamble generation & detection would have to be done on the host. Some pins would have to be soldered.
Since the trigger would use the same old slow UART, it would need to buffer as much as the FIFO mode & make any latency advantage a wash. It would allow packets larger than 255 bytes, but that would be more susceptible to errors.
It's not hard wired to do 256 kbits/sec. The data rate can be set to 230400 bits/sec to better synchronize the transmit FIFO with the UART. Si recommends using a register calculator, but they don't provide any obvious register calculator in the wireless development suite. The existing register tables can be interpolated to give values that work for 230400.
The next big win was letting the beacon rate dynamically adapt to the size of the packets. That got the download speed up to 107520 bits/sec with no uploading & a download speed of 65280 bits/sec during a maximum upload speed of 59840 bits/sec. It couldn't be symmetric because it has a minimum beacon rate.
Having a master sending beacons to schedule the packets has remaned a lot faster than cooperatively trying to allocate time slices. The speed limitation may now be entirely the USB adapter, with a custom USB solution getting above 128 kbits/sec. It's still not fast enough for video, but it's almost bearable for static page loads.
1 byte sequence numbers proved not enough to handle the error rate, so the headers were increased to 3 byte sequence numbers. They would just increase, leaving no question about whether a lower numbered packet was in the past or future. It would take 91 hours for them to wrap around.
That lowered the download speed to 96 kbits/sec. Then there was a case where it would lose the sync bytes & require a hack. After many more corner cases, the USB serial ports finally evolved into the biggest source of lockups. The FTDI board & not the PL2303 was the 1 which 1st died. The write call would freeze until it was unplugged.
If USB serial ports were the standard in the days of massive dialup call centers, they would have become a lot more reliable. That wasn't what happened & the 16550 was the chip which ended up hardened by the call centers of those days.
So the next step would be custom USB interfaces for the radios. It would buy slightly more speed. At this point, having experienced none of the expected range increase, barely usable bandwidth, & pretty lousy reliability, it makes more sense to get an ultra cheap access point from Walmart, extending the range with a waveguide.
96 kbits was still double what GSM or dialup could do. It's too bad you can't buy your own private LTE headend. 3D print anything you want except your own ISP.
It was finally decided to go for the next big win, manely directly connecting the serial port to the modulation of the 3drradio instead of buffering complete packets in the 3drradio.
The Si1000 can't really connect the serial port to the modulation, but it can get real close by carefully synchronizing the FIFOs. It also automatically stops transmitting if the transmit FIFO runs dry. No 100mW radio chip is going to let you leave the transmitter on without transmitting data. The trick is running the air data rate 1 stop lower than the serial port data rate to keep the FIFO full.
Nothing is ever easy, in the wireless business. The ENPAC, CRC flags have to be set. Never could get it transmit directly from the FIFO without setting it to calculate a CRC & packetize it. The FIFO thresholds have to be perfect. The interrupts have to be managed. There have to be a lot of timeout handlers.
The USB adapters are not equal. The FTDI has to be the base & the PL2303 has to be the roamer. 1 of them isn't buffering properly.
So that was the serial port during a transmit & receive when the 3drradio had to buffer a complete packet before transmission, then buffer it again before reception. The 7ms delay was when the packet was in the air. That was without TDM. All the time during the serial port transfers was unused spectrum.
That was with the serial port directly connected to the modulation. It left only 1.5ms between transmit &...Continue Reading
Did another round of testing with the IP over 3drrradio. The 3drradio is 1 of those radios, like the XBee, which shuts down if it detects a returning signal during its own transmission. So an attempt to use XBees for 1 direction with 3drradios for the other direction resulted in all the senders shutting down. Their tuning filters were not sharp enough to isolate 2.4Ghz from 900Mhz.
A bit more tweeking of the parameters got the download speed to 60 kbits/sec & the upload speed to 15 kbits/sec when everything is absolutely perfect. It's still too slow for the intended application.
The original idea of 4 cc1101 radios at 115200 bits/sec was the only thing with acceptable bandwidth, but the range was too short. But that experiment just directly tied PPP to the UART with no resends. Maybe the latest algorithm would work.
Simply tying the serial ports together at 230400 baud gave 173 kbits/sec in both directions, with the same resend algorithm. At 115200, it did 87 kbits/sec. The advantage is each direction has its own wire. The limitation is the latency of the serial port dongles.
The 3drradios & Xbees are limited by the need to buffer a complete packet before sending or receiving on the UART. If they could directly connect the UART to the modulation, they could pack in a lot more data.