| |
My precious decided to die one night.
When I tried to start it one morning it was totally dead, nothing could revive it.
But since it was saturday and I had stuff to do I left it alone.
Then several hours later it started to 'click' as described by others.
I updated the firmware and after two tries it worked, until I switched the brick off
and tried to start it.
Stone dead again, the clicking did reoccur after X number of hours, same thing.
Two tries and the firmware was ok. Turn off and the brick was dead :(
I've informed Lego support and hopefully they'll know what to do.
// hdw
|
|
| |
In lugnet.robotics.nxt, Anders B Jansson wrote:
> Then several hours later it started to 'click' as described
> by others. I updated the firmware and after two tries it
> worked, until I switched the brick off and tried to start it.
> Stone dead again...
OK, that's just... weird. Are you using the straight-off-the-CD software, or
have you upgraded with the "no clicking" patch?
--
Brian Davis
|
|
| |
Brian Davis wrote:
> In lugnet.robotics.nxt, Anders B Jansson wrote:
>
>
> > Then several hours later it started to 'click' as described
> > by others. I updated the firmware and after two tries it
> > worked, until I switched the brick off and tried to start it.
> > Stone dead again...
>
>
> OK, that's just... weird. Are you using the straight-off-the-CD software, or
> have you upgraded with the "no clicking" patch?
Upgraded, and changed to fresh batteries twice,
I sure hope it isn't but is feels very much like a hardware failure
to me :(
On the other hand I can report that I managed to get a low budget GPS
to talk to my NXT.
The bad news is that it works perfect, outdoors, but not at all indoors :)
On the good side is that I got it to talk to a Sony Ericson Z530I mobile
with built in camera (and GPRS modem,IRDA and Java) over Bluetooth.
And it appears to work with a low budget Billionton System BT USB adapter.
What's also good is that Shop@Home has released extra cables and RCX
adapters, so soon I'll have extra light, rotation sensors, camera and
Internet connection but a non-working brick :(
// hdw
|
|
| |
Anyone know if user applications (Java?) running on a camera phone have
access to a recent frame buffer from the on-board camera? The objective
of course is to perform image recognition on either the camera or the
cellphone for the NXT to make intelligent decisions. Of course, use BT
to communicate between cellphone and NXT.
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On Behalf
Of Anders B Jansson
Sent: Monday, September 11, 2006 8:18 PM
To: lugnet.robotics.nxt@lugnet.com
Subject: Re: Gnah I'm afraid I've discovered a new bug :(
Brian Davis wrote:
> In lugnet.robotics.nxt, Anders B Jansson wrote:
>
>
> > Then several hours later it started to 'click' as described
> > by others. I updated the firmware and after two tries it
> > worked, until I switched the brick off and tried to start it.
> > Stone dead again...
>
>
> OK, that's just... weird. Are you using the straight-off-the-CD • software, or
> have you upgraded with the "no clicking" patch?
Upgraded, and changed to fresh batteries twice,
I sure hope it isn't but is feels very much like a hardware failure
to me :(
On the other hand I can report that I managed to get a low budget GPS
to talk to my NXT.
The bad news is that it works perfect, outdoors, but not at all indoors
:)
On the good side is that I got it to talk to a Sony Ericson Z530I mobile
with built in camera (and GPRS modem,IRDA and Java) over Bluetooth.
And it appears to work with a low budget Billionton System BT USB
adapter.
What's also good is that Shop@Home has released extra cables and RCX
adapters, so soon I'll have extra light, rotation sensors, camera and
Internet connection but a non-working brick :(
// hdw
|
|
| |
In article <001501c6d613$4aece680$060ba8c0@dickdesktop>, Dick Swan
<dickswan@sbcglobal.net> writes
>
> Anyone know if user applications (Java?) running on a camera phone have
> access to a recent frame buffer from the on-board camera?
There are quite a number of different software platforms, versions and
variants for 'feature phones' and 'smart' phones. For Java a lot of
APIs are optional, to varying degrees and have different versions.
These may even change with firmware version.
Most application environment have APIs to take pictures, (usually as
JPEG or PNG). Also to take short videos.
For a phone with Java you want to find out if it supports MIDP, (Mobile
Information Device profile), and what version. And if it is MIDP 2.0 or
later whether it supports the Media API or Mobile Media API, (MMAPI) or
on some older phones a manufacturer specific API for the camera.
The Java capabilities of the Sony Ericsson Z530I, that Anders mentioned,
are described here:
http://developer.sonyericsson.com/site/global/products/phonegallery/z530/p_z530.jsp
Whilst it does list the phone as supporting MMAPI I would suggest a
device with a larger screen would be more comfortable to program.
The Sony Ericsson developer home page is here:
http://developer.sonyericsson.com/site/global/home/p_home.jsp
- Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
|
|
| |
Topic was formerly named "Gnah I'm afraid I've discovered a new bug".
I've put a more relevant subject on it. This is in response to a reply
from Tony Naggs.
This is a good answer but not to the question I wanted answered. The
currently available cameras (CMUCAM, AVRCAM) for hobby robots are
"smart" cameras.
The robot tells the camera what color(s) to look for and the camera
analyses the video image (say 10 frames per second or higher) to report
back to the robot the bounding rectangles of color blobs that matched
the defined colors. The value of this approach is that it minimizes CPU
overhead and I/O bandwidth on the NXT -- it's simply exchanging 10 to 20
bytes every 100 msec vs a constant video stream.
So my question is multi-part.
It would be nice to use an existing camera phone for this application
instead of buying a CMUCAM/AVRCAM ($100 - $200 each). So my question was
really related to this specific application.
1. Can a user's JAVE program running in the camera phone gain
access to a video frame buffer and do the blob recognition? The
application needs access to a "raw" video image and not a JPEG or
other compressed file.
2. Is there enough CPU horsepower in the camera phone for this
application? An AVRCAM is a 20Mhz 8-bit AVR with 384 bytes
of RAM so I figured a camera phone should have enough cycles.
3. Can the JAVA gain fast enough access to process 10 frames per
second?
4. Does the JAVA gain access to the video frame in RAM in real
time?
5. Can you find an easy want to message (BT?) between the camera
phone and the NXT?
|
|
| |
In article <003701c6d6bc$fe18c630$060ba8c0@dickdesktop>, Dick Swan
<dickswan@sbcglobal.net> writes
>
> Topic was formerly named "Gnah I'm afraid I've discovered a new bug".
> I've put a more relevant subject on it. This is in response to a reply
> from Tony Naggs.
>
> This is a good answer
Okay.
> but not to the question I wanted answered.
I was lacking context, and I think you are looking for a simple answer
that is not yet available.
> The
> currently available cameras (CMUCAM, AVRCAM) for hobby robots are
> "smart" cameras.
>
> The robot tells the camera what color(s) to look for and the camera
> analyses the video image (say 10 frames per second or higher) to report
> back to the robot the bounding rectangles of color blobs that matched
> the defined colors.
Interesting, I have not met any of this before.
> The value of this approach is that it minimizes CPU
> overhead and I/O bandwidth on the NXT -- it's simply exchanging 10 to 20
> bytes every 100 msec vs a constant video stream.
>
> So my question is multi-part.
I shall try to work my way through it.
> It would be nice to use an existing camera phone for this application
> instead of buying a CMUCAM/AVRCAM ($100 - $200 each). So my question was
> really related to this specific application.
>
> 1. Can a user's JAVE program running in the camera phone gain
> access to a video frame buffer and do the blob recognition? The
> application needs access to a "raw" video image and not a JPEG or
> other compressed file.
From a very quick web survey I think that most camera phones with Java
will support picture capture. (Given that the phone is less than 2
years old and comes from a well known brand; Nokia, Motorola, Sony
Ericsson, ...)
> 2. Is there enough CPU horsepower in the camera phone for this
> application? An AVRCAM is a 20Mhz 8-bit AVR with 384 bytes
> of RAM so I figured a camera phone should have enough cycles.
Camera phones often have an ARMv4 core, possibly running up to +/-200
MHz. (Or even +/-400 MHz for the MHz hungry Windows platforms.)
There should at least be plenty of power. :-)
> 3. Can the JAVA gain fast enough access to process 10 frames per
> second?
This needs an experiment, and comparison of different devices.
(I am doubtful that many camera phones will have this performance.)
> 4. Does the JAVA gain access to the video frame in RAM in real
> time?
I have not yet used Java on a phone, (soon I hope!), the apparent
capability is to active the camera with the view on screen. Then when
the program wishes it asks for a 'snapshot'. I am not clear whether
these can be taken sufficiently often for your purpose.
The snapshot will be in a standard format, PNG or JPEG seem most
popular. Though often quite small, e.g. 160 x 120 pixels.
Supported formats are different on each device, and may reflect the
underlying camera hardware as much as the manufacturer's preferences.
The applications targeted by these functions seem to be simple camera
apps. These an interesting, brief introductory article here:
http://developers.sun.com/techtopics/mobility/midp/articles/picture/
> 5. Can you find an easy want to message (BT?) between the camera
> phone and the NXT?
If the phone allows applications to use the camera most likely then can
use the Bluetooth too. It looks to be fairly easy to write a library
that opens a Bluetooth connection to a NXT as a serial port, and to then
exchange the message in the NXT Hardware Developer Kit. (It is on my
'to do' list.)
A native application on something like a recent Nokia 'series 60' phone
will probably do better. However these phones are much more expensive
than a basic camera phone, unless your carrier/service operator has big
subsidies.
Cheers,
Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
|
|
| |
In lugnet.robotics.nxt, Anders B Jansson wrote:
>
> On the other hand I can report that I managed to get a low budget GPS
> to talk to my NXT.
> The bad news is that it works perfect, outdoors, but not at all indoors :)
Yah well, that's GPS for you. Even high-budget GPS's don't work very well
indoors, if at all.
|
|
| |
Replying to myself:
I've been told by support to contact sales.
Which is fair, not their fault that I contacted the wrong source.
When it comes to Sony-Ericsson Z530i I'll create a new thread
so we can discuss that.
// hdw
Anders B Jansson wrote:
> Brian Davis wrote:
>
> > In lugnet.robotics.nxt, Anders B Jansson wrote:
> >
> >
> > > Then several hours later it started to 'click' as described
> > > by others. I updated the firmware and after two tries it
> > > worked, until I switched the brick off and tried to start it.
> > > Stone dead again...
> >
> >
> >
> > OK, that's just... weird. Are you using the straight-off-the-CD
> > software, or
> > have you upgraded with the "no clicking" patch?
>
> Upgraded, and changed to fresh batteries twice,
>
> I sure hope it isn't but is feels very much like a hardware failure
> to me :(
>
> On the other hand I can report that I managed to get a low budget GPS
> to talk to my NXT.
> The bad news is that it works perfect, outdoors, but not at all indoors :)
>
> On the good side is that I got it to talk to a Sony Ericson Z530I mobile
> with built in camera (and GPRS modem,IRDA and Java) over Bluetooth.
>
> And it appears to work with a low budget Billionton System BT USB adapter.
>
> What's also good is that Shop@Home has released extra cables and RCX
> adapters, so soon I'll have extra light, rotation sensors, camera and
> Internet connection but a non-working brick :(
>
> // hdw
|
|
| |
Anders B Jansson wrote:
> Replying to myself:
> I've been told by support to contact sales.
> Which is fair, not their fault that I contacted the wrong source.
> // hdw
My faith in the company is undisturbed.
Quick call to the sales dept and a new NXT is in the mail.
They kindly asked me to return the broken one, using their free
of charge mailing service.
Note that they didn't say:
"Return the unit, let us mull for a week and we might send you a new one".
They gave me a reference number for my return and cleared sending a new on the spot.
I'm so tired on companies that want a faxed copy of my ID, shoe size,
sexual preference and a stool sample before they accept to talk to me.
And need proof by three oathsworn men of good standing before pondering
a replacement.
With Lego it's:
- Gah! My toy is broken!
- Cool, we'll send you a new one, what's your adress?
// hdw
|
|
|
